Юридические вопросы по раскрытию программного кода в общий доступ

Позиция компании Яндекс может не совпадать с позицией автора.

В настоящее время все также можно встретить дискуссии о том, является ли бизнес-модель открытого программного обеспечения успешной. В любом случае, нам известны достаточно успешные с коммерческой стороны примеры таких продуктов – те же Red Hat Enterprise Linux, Qt. Но стоит иметь в виду, что создание, модификации, релизы и поддержка подобного рода программных продуктов требует в том числе и юридического сопровождения.

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

В этой части можно выделить следующие основные направления юридического аудита:

1. Проверка условий использования сторонних компонентов (при их наличии)
2. Идентификация авторов ПО
3. Неразглашение сведений, составляющих коммерческую тайну
4. Условия принятия внешних контрибьютов
5. Иные вопросы

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

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

Если включаемый в состав программного продукта сторонний объект, программный компонент имеет лицензию, необходимо убедиться, что условия такой лицензии будут полностью соблюдены автором/правообладателем такого создаваемого продукта. Например, если компания создает проприетарный программный продукт, который будет дистрибутироваться в виде мобильного приложения, и при этом не желает предоставлять исходный код такого приложения, то компании важно убедиться в том, что в состав такого приложения не входят сторонние компоненты, лицензии которых требуют раскрытия исходного кода такого продукта при его дистрибуции (следует помнить, что даже лицензия GNU GPL v2 не всегда императивно требует раскрытия исходного кода).

Не лишним будет вести учет лицензий всех сторонних компонентов и объектов, включаемых в состав создаваемого ПО. Это позволит на этапе подготовки собственных лицензионный условий (или выбора лицензии из числа имеющихся, таких как MIT, BSD и т.д.) иметь в виду все требования и условия, налагаемые сторонними лицензиями. Это важно, поскольку условия лицензии всего продукта не должны противоречить ни одному условию какой-либо лицензии стороннего компонента, включенного в состав такого продукта. Многие лицензии имеют официальные справочные материалы по своим текстам – следует ознакомиться с ними, чтобы разобраться в нюансах использования.

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

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

На практике имена авторов можно отображать (а иногда и нужно – если этого требуют условия лицензии) в составе файлов опубликованного исходного кода. Если говорить про сервисы типа Github, то в рамках них достаточно популярен подход с размещением в репозитории файла AUTHORS с перечнем авторов.

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

Условия принятия внешних контрибьютов. Лучше уже на начальных стадиях подготовки продукта к релизу определить, как будут создаваться его новые, последующие версии: при выпуске в будущем новых версий такого продукта можно ли будет включать в их состав контрибьюты, полученные от третьих лиц (сторонних разработчиков) или продукт будет обновляться только силами самих авторов (или работников компании, которая является правообладателем такого продукта). Если первое, то важно определить, на каких условиях сами авторы/правообладатель продукта смогут использовать такие контрибьюты от внешних лиц. Некоторые лицензии (например, лицензия Apache License 2.0) уже содержат в себе положения, регулирующие такие отношения сторон, другие же (например, MIT, BSD) не содержат. И чтобы устранить возможные юридические риски в будущем, связанные с использованием объектов авторских прав третьих лиц (ведь контрибьют при определенных условиях может быть признан таким объектом), следует либо выбрать для своего продукта лицензию, содержащую в себе положения об этом, либо сопроводить раскрываемый продукт соответствующим соглашением (обычно имеется в виду CLA – Contribution License Agreement) или руководством о предоставлении контрибьютах и условиях их использования самими авторами или правообладателями продукта.

Иные вопросы. Если производитель программного обеспечения с открытым исходным кодом дистрибутирует свою продукцию на территории стран, где ПО признается объектом патентных прав, то при наличии достаточных финансовых и организационных возможностей стоит проводить анализ своего ПО на предмет возможности подачи патентных заявок для получения в будущем патентов на свое программное обеспечение. Тем более, что некоторые юрисдикции (например, право ЕС) запрещают подавать патентные заявки на программный код, который был уже раскрыт в общий доступ до даты подачи патентной заявки.
До релиза продукта в общий доступ стоит также проверить его название и логотип (при его наличии) на предмет юридических рисков по части авторских прав, прав на товарный знак и фирменное наименование, коммерческое обозначение, право гражданина на собственное имя и изображение. Например, если правообладатель ПО планирует назвать свой продукт наподобие StarWars Disk Checker, то при отсутствии согласия со стороны правообладателя StarWars будет существенной вероятность признания таких действий по названию и распространению продукта нарушением авторских прав и прав на товарный знак правообладателя StarWars. Если в качестве логотипа используется изображение или словесные элементы, идентичные или схожие до степени смешения с товарным знаком третьего лица (например, если логотип продукта схож с логотипом MasterCard) это может быть признано нарушением прав на товарный знак.

В целом, следует отметить, что юридическая сторона разработки программного кода и опубликования его в общий доступ достаточно обширна. Основной объем юридического аудита приходится, как правило, на стадии, предшествующие релизу программного кода. При включении сторонних компонентов важно сразу разобраться с условиями их использования, чтобы в будущем не возникло проблемы, связанной с болезненным исключением такого компонента из состава готового ПО в виду невозможности соблюдения условий его лицензии.

Несмотря на то, что у проектов с открытым исходным кодом сложилась своеобразная (и во многом достаточно позитивная) репутация, юридические риски не стоит недооценивать: известны примеры судебных дел по программному обеспечению с открытым исходным кодом (например, дела SCO vs. IBM и Jacobsen v. Katzer в США, дела по JDownloader в Германии). Поэтому их действительно стоит своевременно обнаруживать и принимать необходимые меры по их минимизации.

Ссылки и примечания

1. См., например, Питер Левин. Бизнес-модель ПО с открытым исходным кодом ошибочна // https://habr.com/post/292272/, дата обращения: 05.08.2018
2. По данным The Github Blog, в 2015 году менее 20% проектов на Гитхабе были снабжены лицензиями // https://blog.github.com/2015-03-09-open-source-license-usage-on-github-com/, дата обращения: 06.08.2018
3. См., например, про лицензии типа Beer-license // https://dorotenko.pro/beer-license/ или про особенности лицензии JSON License касательно ее условия «shall be used for Good, not Evil» // https://news.ycombinator.com/item?id=5138866, дата обращения: 06.08.2018.
4. См. Ответы на вопросы о версии 2 GNU GPL // https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ru.html#TOCGPLPlugins, дата обращения: 06.08.2018.
5. См., например, Frequent Questions about Apache Licensing // http://www.apache.org/foundation/license-faq.html, дата обращения: 07.08.2018 или MPL 2.0 FAQ // https://www.mozilla.org/en-US/MPL/2.0/FAQ/, дата обращения: 07.08.2018.
6. Гражданский Кодекс РФ (часть четвертая), ст. 1228.
7. Закон РБ Об авторском праве и смежных правах, статья 9.
8. Пример файла AUTHORS из продукта ClickHouse, принадлежащего Яндексу – https://github.com/yandex/ClickHouse/blob/master/AUTHORS.
9. Подробнее про это см., например, Доротенко Д.А., Секрет производства (ноу-хау): правовой статус // http://www.garant.ru/ia/opinion/author/dorotenko/1186956/, дата обращения: 06.08.2018.
10. Примеры CLA: Яндекса – https://yandex.ru/legal/cla/, Canonical – https://www.ubuntu.com/legal/contributors, Facebook – https://code.facebook.com/cla, Oracle – http://www.oracle.com/technetwork/community/oca-486395.html.
11. См. логотип здесь: Официальный сайт Федеральной службы по интеллектуальной собственности http://www1.fips.ru/fips_servl/fips_servlet?DB=RUTM&DocNumber=493305.
12. Jon Gold, SCO vs. IBM legal battle over Linux may – finally – be finished // https://www.networkworld.com/article/3032050/open-source-tools/sco-vs-ibm-legal-battle-over-linux-may-finally-be-finished.html, дата обращения: 06.08.2018.
13. Jacobsen v. Katzer // http://itlaw.wikia.com/wiki/Jacobsen_v._Katzer, дата обращения: 06.08.2018.
14. German Court Says CEO Of Open Source Company Liable For ‘Illegal’ Functions Submitted By Community // https://www.techdirt.com/articles/20131205/01432025460/german-court-says-ceo-open-source-company-liable-illegal-functions-submitted-community.shtml, дата обращения: 06.08.2018.