Лицензия на открытость

В 2021 году компания Elastic сменила лицензию поисковой системы Elasticsearch и веб-интерфейса Kibana с открытой Apache 2.0 на несвободную SSPL 1.0. Поводом стало то, что крупные технологические компании и провайдеры облачных сервисов пользовались продуктами Elastic, не покупая коммерческой лицензии. Исходный код остался доступным, однако не считается «открытым» в соответствии с принципами OSI (Open Source Initiative), потому что сторонние разработчики не могут использовать его бесплатно.

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

Пермиссивные и копилефтные лицензии

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

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

Фонд свободного программного обеспечения (Free Software Foundation) разделяет копилефтные лицензии на две категории: с сильным и слабым копилефтом. Сильный копилефт не подразумевает условий, при которых производный софт можно распространять под любой другой лицензией, кроме той, что используется в исходном коде. Слабый копилефт, напротив, предусматривает такие условия. Например, лицензия EPL (Eclipse Public License), разработанная на базе Common Public License, общественной лицензии IBM, позволяет использовать исходный код в проприетарных программах. Главное условие — его нужно вынести в отдельный файл программы.

Совместимость лицензий

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

С пермиссивными лицензиями все просто: большинство из них совместимы между собой, с другими свободными и даже с проприетарными лицензиями. Фрагменты исходного кода останутся под собственными лицензиями, а новый проект может существовать под любой другой. Копилефтные лицензии, напротив, не только несовместимы с пермиссивными и проприетарными, но могут быть несовместимы даже друг с другом. Так, например, GPLv2 несовместима с GPLv3. Хотя FSF позволяет использовать в рамках одного проекта продукты с этими лицензиями, но только при одном условии: разработчик должен указать, что «программа выпускается под GNU GPL версии N или более поздней».

Ряд копилефтных лицензий все-таки совместимы друг с другом. К их числу относятся, к примеру, GPLv3 и EUPL 1.2. В крайних случаях можно перелицензировать продукт целиком. Иначе говоря, попросить всех правообладателей согласиться с заменой лицензии. Такую процедуру провела компания Mozilla Foundation для браузера Mozilla Firefox.

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

Как проверить лицензия на соответствие принципам открытого ПО

Лицензию на опенсорс можно написать самостоятельно, например отредактировав MIT или Apache. Однако следует позаботиться о том, чтобы ею могли воспользоваться люди, которые не разбираются в юридических тонкостях. Такого принципа придерживается Open Source Initiative (OSI) — организация, которая с 1998 года продвигает открытое ПО и претендует на звание главного верификатора открытых лицензий.

К сегодняшнему дню OSI одобрила более 100 лицензий. Среди разработчиков опенсорс-продуктов существует негласная договоренность: если лицензия не получила одобрения OSI, значит, она не соответствует «духу опенсорса» и использовать ее нежелательно.

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

Проверкой лицензий также занимается Фонд свободного программного обеспечения (Free Software Foundation), основанный Ричардом Столлманом. Фонд разработал и написал текст лицензии GPL и выносит определение о совместимости с ней других лицензий. Со списком проверенных лицензий можно ознакомиться здесь. Важно отметить, что многие лицензии, которые считаются опенсорными, FSF не признает по собственным критериям и относит к категории несвободных. В России пока не существует организаций, которые занимаются проверкой опенсорсных лицензий.

Однако в будущем ситуация может измениться благодаря распространению опенсорсных операционных систем и другого ПО. Например, в России уже есть собственная открытая лицензия версии 1.1. Ее текст выложен в репозитории государственного проекта «Витрины данных НСУД».

Подводные камни лицензирования

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

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

На GitHub проект может быть открытым, но не иметь никакой лицензии. В таком случае он подчиняется условиям использования GitHub. Это означает, что, даже если GitHub позволяет просматривать код, его нельзя использовать, распространять и модифицировать в собственном продукте, если автор явно не даст на это разрешение.

Проект может иметь несколько лицензий, в том числе проприетарные для платного использования. В таком случае необходимо выбрать лицензию, которая будет совместима с продуктом. Из-за ошибки в выборе лицензии компания Hancom в 2017 году получила иск от Artifex Software, которой принадлежал набор программ Ghostscript, позволяющий интерпретировать язык PostScript и документы PDF и распространяющийся по двум лицензиям: коммерческой и открытой. Hancom пользовалась открытой лицензией и должна была открыть код офисного пакета, но не сделала этого. Компании урегулировали спор до суда, так и не огласив подробности.

При этом лицензии не имеют ограничений в зависимости от страны разработки продукта.

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

Вендоры ПО с открытым кодом нередко сталкиваются с проблемами лицензирования, пытаясь коммерциализировать собственные продукты. Например, в августе 2023 года компания HashiCorp объявила о замене лицензии в продуктах Terraform, Packer, Vault, Boundary и других с открытой MPL на BSL 1.1 (Business Source License). BSL позволяет использовать открытый код в некоммерческих целях, а для коммерческих требует разрешения правообладателя. Однако некоторые компании, использовавшие исходный код продуктов HashiCorp, сделали форк исходного кода и объявили о развитии форков под открытыми лицензиями.

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

Как выбрать лицензию для проекта

Если разработчики хотят сделать продукт доступным для использования без ограничений, следует выбрать одну из пермиссивных лицензий: MIT, BSD или Apache. Продукт с такой лицензией будет популярнее, чем с GPL, поскольку его можно будет использовать в любых опенсорсных и проприетарных решениях.

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

Сегодня выводить продукты в опенсорс крупным компаниям помогают внутренние команды, так называемые Open Source Program Office. Они объединяют сотрудников с различными компетенциями и координируют процессы, поэтому разработчикам не нужно искать юристов, безопасников и других специалистов. Кроме того, существуют ресурсы, такие как choosealicense, которые помогают подобрать лицензию.

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

При разработке текста собственной лицензии также следует учитывать нормы ст. 1286.1. ГК РФ. Так, например, если в тексте вашей лицензии не указан срок действия, то будет считаться, что лицензия на ПО представлена на весь срок действия исключительного права. А в отношении других видов произведений (например, если вы делаете отдельную лицензию на документацию) право использования этой документации будет считаться предоставленным на пять лет. Если же в тексте вашей лицензии не будет указана территория, на которой допускается использование соответствующего произведения, то такое использование будет считаться предоставленным на территории всего мира (п. 3 ст. 1286.1 ГК РФ).

Нет в России и отдельного закона о регулировании использования опенсорса. Однако с ним связана статья 1286.1 в Гражданском кодексе. Согласно ей, неправомерное использование произведения на основе открытой лицензии влечет для нарушителя компенсацию убытков или взыскание компенсации. К такому лицу также может быть предъявлено требование о публикации решения суда с указанием действительного правообладателя.

Правовая практика и опенсорс

Наибольшее количество судов, связанных с использованием опенсорса, происходит в США. В октябре 2021 года фонд Software Freedom Conservancy (SFC) обвинил производителя электроники Vizio в нарушении использования своих продуктов, поскольку компания не открыла исходный код продукта в соответствии с лицензией GPL. Спор примечателен тем, что SFC не был владельцем исходных продуктов с лицензией GPL, но подал в суд от лица покупателя продукции Vizio.

В России судов, связанных с использованием опенсорса, практически нет.

Нет в России и отдельного закона о регулировании использования опенсорса. Однако с ним связана статья 1286.1 в Гражданском кодексе. Согласно ей, неправомерное использование открытого кода, например, за пределами условий лицензии или в результате нарушения личных неимущественных прав влечет внедоговорную ответственность.

Популярные опенсорсные лицензии не содержат географических ограничений, поэтому при выборе зарубежных продуктов лицензия не играет важной роли.

Свобода, ограниченная свободой

С самого начала опенсорс подразумевал свободу использования ПО. Однако единого мнения о том, как должна выглядеть эта свобода, так и не появилось. Ричард Столлман и FSF считают, что производное ПО обязательно должно быть свободным, а авторы лицензий BSD, MIT и других — что нельзя ограничивать свободу производного ПО и оно может быть любым, в том числе и проприетарным.

Если не учитывать особенности лицензии, использование опенсорса может привести к претензиям со стороны правообладателей. В России таких прецедентов практически нет. Однако софт с открытым кодом становится популярнее, а законодательство совершенствуется, поэтому это, скорее всего, дело времени.

Реклама: ООО «Веб-Сервер», ИНН 9704151517, 2SDnjeg12wJ