Автор: Илья Стечкин

Мы обратили внимание на то, что едва ли не самой популярной публикацией в нашем блоге стал материал, посвященный патентным войнам (4800 просмотров), а вот подробный рассказ о том, как писать плагины для Fuel, к нашему удивлению, вызвал существенно меньший интерес (1000 просмотров первая часть и чуть больше 2000 — вторая).

На всякий случай информируем вас о том, что с этого месяца Fuel официально стал средством развертывания всея OpenStack.

Но раз юридические вопросы существования открытого кода занимают вас больше, чем сам код, то мы пошли на встречу пожеланиям трудящихся и решили рассказать вам о том, как уживаются авторское и патентное право с open source.

Действительно, как удается избегать прямой конкуренции и делать одно общее дело не только отдельным контрибуторам, но и целым корпорациям, вовлеченным в процесс разработки open source? Ответ следует искать в тех “правилах игры”, которыми руководствуются все без исключения участники сообщества. Эти “правила” описываются не только внутренними политиками того или иного проекта, но и лицензией, под которой выходит итоговый продукт. По понятным причинам в данной статье мы подробно остановимся на вопросах, имеющих прямое отношение к OpenStack. Например, OpenStack (в том числе и Mirantis OpenStack) выходит под лицензией Apache 2.0. Что это значит? Почему выбрали именно эту лицензию? Как с этим жить?

Интеллектуальная собственность: что это такое?

Интеллектуальной собственностью называют результат творческого труда: будь то художественная книга, репортаж или программа.

Говоря про интеллектуальную собственность, необходимо рассматривать три модели правового регулирования: авторское право, патентное право и ноу-хау. Почему недостаточно одного только авторского права? Потому что оно регулирует только возможности владения, распространения и внесения изменений в сам код (и сопутствующие ему документы, такие как техническое задание, мануалы и т.п.) — исходный или объектный.

Но ведь идея, которая реализована средствами конкретного языка программирования, может быть важнее, чем ее воплощение. Как защитить, например, алгоритм, который лежит в основе программы? Для этого существует право патентное.

Есть еще такая штука — “ноу-хау”, но с открытым кодом она уживается плохо, так что подробно останавливаться на этом режиме защиты интеллектуальной собственности не будем. Уточним только, что “ноу-хау” имеет ценность до тех пор, пока о нем не знают “третьи лица”. Более того, юридическая защита “ноу-хау” возможна только в том случае, если владелец интеллектуальной собственности предпринял все возможные меры (в том числе ввел в компании режим коммерческой тайны по отношению к соответствующим объектам интеллектуальной собственности) для предотвращения “утечки”. Но даже в этом случае отечественная правоприменительная практика не гарантирует успеха при попытке решить в суде спор с сотрудником, нарушившим соответствующий режим.

Авторское право

Авторское право возникает само по себе. Вам не нужно предпринимать каких-либо шагов для защиты результата творческой работы. Как только вы что-то написали, авторское право вступило в силу. Даже подписываться не обязательно. Правда, без подписи доказать ваше авторство будет сложнее — могут потребоваться различные экспертизы. На них уйдут деньги и время, а результат не гарантирован. Между тем, авторство — единственное, что безусловно принадлежит именно вам, создателю произведения. По крайней мере в России. В США, например, авторское право может принадлежать корпорации, в которой вы работаете. В России работодатель, при надлежащим образом оформленном контракте, получает только набор так называемых “смежных” прав, таких, как право на копирование, распространение, переработку и т.п. Иными словами, работодатель получает все, что позволяет зарабатывать деньги на результатах вашего творчества (а инженерную деятельность мы, безусловно, считаем творческой). Но “право первородства”, право поставить свое имя под произведением остается у вас. В основе авторского права лежит Бернская конвенция, декларирующая основные принципы его действия. Европейское законодательство (в частности Директива 2009/24/EC Европейского Парламента и Совета от 23 апреля 2009 года о правовой охране компьютерных программ) заботится о том, чтобы технический прогресс продолжался, а потому, например, “лицо, обладающее правом использования компьютерной программы, не может быть ограничено в проведении необходимых изучений, исследований и испытаний функционирования программы, при условии, что такие действия не нарушают авторских прав на программу”. В Российском законодательстве аналогичные нормы вводятся статьей 1280 Гражданского кодекса.

Для культуры open source авторское право является важнейшим понятием. Культура инженерного “общежития” строится на уважении к “праву на имя”: не важно, принадлежит ли оно компании или конкретному человеку — контрибутору кода. Мы еще вернемся к этому вопросу ниже, когда будем говорить о лицензиях.

Патентное право

Как вы уже знаете (из той самой статьи, которая подвигла нас на этот опус), патенты могут быть использованы как инструмент давления производителей проприетарного ПО на сообщества разработчиков открытого кода. Дело в том, что патентами защищаются алгоритмы, интерфейсы и устройства. Применительно к ПО, в соответствии с российским законодательством, могут быть задействованы механизмы защиты изобретений (в этом случае в качестве изобретения может рассматриваться алгоритм или программно-аппаратный комплекс) и промышленных образцов (интерфейс, допустим, может выступать в качестве промышленного образца “внешнего вида” программы).

В отличие от авторского права, патентное право возникает только после того, как пройдена сложная и недешевая процедура регистрации изобретения или промышленного образца. Именно поэтому большие компании инвестируют время и большие деньги в получение патентов. Например, у Apple, по данным US Patent Collection (запрос к БД: AN/apple) более 11 тысяч (!) патентов. Маленькие компании не имеют таких возможностей. А потому им остается полагаться только на защиту лицензий и здравый смысл.

Лицензии

Лицензии бывают исключительными и неисключительными. Все “свободные лицензии” являются неисключительными. Также лицензии могут быть возмездными и безвозмездными. Все “свободные лицензии” — безвозмездные. Еще один вариант классификации лицензий: разрешительные, слабо ограничительные и сильно ограничительные.

Лицензия Apache 2.0, с которой мы начали разговор, относится к первому типу. В рамках данной лицензии пользователю разрешено использовать ПО без каких-либо ограничений, воспроизводить его, создавать собственные программные продукты на основе кода, лицензированного таким образом, распространять как исходный код, так и производное ПО. Разрешено коммерческое использование лицензированного продукта — это в принципе делает возможным бизнес, связанный с OpenStack.

Что еще важно для бизнеса, это разрешение предоставлять собственные дополнительные гарантии в отношении программы при дальнейшем распространении. Именно этот пункт позволяет создавать “добавленную стоимость” нашему дистрибутиву Mirantis OpenStack (убирать баги, которые обнаруживаются в “ванильном” релизе, повышать безопасность, стабильность, масштабируемость), а также создает правовую базу для работы нашей службы поддержки.

При этом пользователю запрещается требовать от лицензиара гарантий и использовать товарные знаки лицензиара (лицензиаром называется компания, предоставляющая продукт по лицензии). Иными словами, если вы взяли продукт и используете его для решения поставленных перед вами задач, то делаете это на свой страх и риск. Это обстоятельство позволяет продавать те самые гарантии, которые нельзя требовать по лицензии.

OpenStack — технология бесплатная, но требующая определенных компетенций для эффективной работы с нею. У предприятий есть выбор: тренировать собственных ИТ-специалистов или же обратиться в компанию, обладающую экспертизой в OpenStack. В первом случае ответственность за корректное функционирование решения, созданного на базе OpenStack, остается внутри компании, во втором — передается подрядчику. Подрядчик, в свою очередь, может обеспечить включение разработок, созданных для заказчика, в экосистему OpenStack. Этот процесс принято называть contribution to upstream. Решение, созданное на базе OpenStack, но не добавленное в апстрим, у нас в компании принято называть “франкенстеком”, подчеркивая его ненадежность и даже опасность. Именно об опасностях таких решений мы говорили в прошлом посте.

Пользователь, в рамках данной лицензии, также принимает на себя некоторые обязательства: сохранять уведомления об авторском праве, товарных знаках, патентах; включать в продукт копию лицензии (в корневую директорию добавляется файл .LICENSE с текстом, шаблон которого приведен на сайте Apache Software Foundation — см. внизу страницы, доступной по ссылке); помечать значительные изменения кода (это делается для того, чтобы защитить репутации контрибуторов) и, конечно, раскрывать код — иначе это не была бы открытая лицензия.

Выводы

Итак, OpenStack комфортно уживается с авторским правом, поскольку лицензия Apache 2.0 дает возможность каждому из участников процесса создания ПО заявить о себе и, при этом, защищает репутацию каждого контрибутора.

Патенты, в принципе, не вредят OpenStack. Более того, если кто-то из компаний-контрибуторов хочет привнести в проект запатентованную технологию, в действие вступает патентная лицензия: положение о предоставлении вкладчиком простой неисключительной лицензии на имеющиеся у него запатентованные алгоритмы и технологии, включаемые им в проект. На пракике это означает, что если вкладчик вносит в программу свои запатентованные алгоритмы, он автоматически предоставляет всем другим участникам проекта и последующим участникам простую неисключительную лицензию на данные запатентованные алгоритмы. Патентная лицензия предоставляется в рамках лицензии Apache 2.0.

Лицензия Apache 2.0, под которой осуществляются разработки, связанные с OpenStack, является свободной и предоставляет множество уникальных возможностей для бизнеса.

Открытый код и интеллектуальная собственность