Совместимость свободных и open‑source‑лицензий: подробный гайд
2026-02-21 20:14 Diff
https://skillbox.ru/media/code/sovmestimost-svobodnykh-i-open-sourcelitsenziy-podrobnyy-gayd/

#статьи

  • 13 май 2022
  • 0

Юрист рассказал, как подружить между собой разные открытые лицензии и перелицензировать программу.

Иллюстрация: Polina Vari для Skillbox Media

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

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

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

Если вы используете open-source-решение в своём проекте, может возникнуть проблема совместимости, — когда разные фрагменты кода находятся под разными свободными лицензиями. Кроме того, если вы не выполните требование лицензии заимствованного кода, то нарушите права разработчика, и у него будут основания предъявить вам претензии.

Напомню, что свободные лицензии делят на взаимные и разрешительные.

Взаимные, или копилефтные, лицензии, к которым относятся соглашения из семейства GNU, часто бывают несовместимы друг с другом и с другими свободными лицензиями. Дело в том, что новые продукты, а также продукты, в которые включён код или часть кода под GNU, должны распространяться строго под GNU определённой версии.

Разрешительные лицензии совместимы между собой, с другими свободными лицензиями и даже с проприетарными лицензиями. К наиболее известным разрешительным лицензиям относятся BSD и MIT.

Разрешительные лицензии, как правило, можно совмещать с взаимными. При этом части кода остаются под своими лицензиями, а программа целиком лицензируется под взаимной. Исключение из этого правила — 4‑clause BSD license, которая требует всегда упоминать её в рекламе продуктов, в состав которых входит код под 4‑clause BSD.

Ричард Столлман делит свободные лицензии на три группы: без копилефта, со слабым копилефтом и со строгим копилефтом.

Лицензии без копилефта (lax permissive licenses) совместимы друг с другом, позволяют использовать лицензируемый код с проприетарным или поместить его в проприетарный продукт и сделать закрытым. К ним относятся 3-clause BSD, X11, Expat, Apache, Python и другие.

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

Лицензии со слабым копилефтом (промежуточные) разрешают добавлять проприетарный код, но требуют от разработчика соблюдения определённых условий. К ним относятся Eclipse Public License и Mozilla Public License.

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

Лицензии со строгим копилефтом (взаимные лицензии) запрещают использовать лицензируемый код в проприетарных продуктах. Программа и её модификации распространяются только на условиях изначальной лицензии. К ним относятся GNU GPL версий 2 и 3.

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

Преодолеть несовместимость взаимных лицензий можно несколькими способами.

Указать на совместимость «явным образом». Так, например, исходный код под GNU GPL v3 можно включать в одну программу с исходниками под GNU AGPL. В результате получается произведение, которое распространяется под GNU Affero GPL.

Включить условие о совместимости с более поздними версиями лицензии. В случаях, когда речь идёт о разных версиях одной взаимной лицензии, Фонд свободного ПО предлагает разработчикам включать в лицензии GNU GPL фразу «программа выпускается под GNU GPL версии N или более поздней». Это позволяет совмещать программы, вышедшие под разными версиями GNU GPL. Разработчики сами принимают решение — включать это условие в текст лицензии или нет.

Включить условие об обновлении лицензии. Другой способ добиться совместимости разных версий — добавить условие, что лицензия может быть обновлена до более поздней версии. Так делают в PHP, Mozilla Foundation и Creative Commons. Условие об обновлении версий закреплено в тексте этих лицензий, а не оставлено на усмотрение разработчиков.

Ричард Столлман считает такой подход более разумным, поскольку усмотрение авторов часто приводит к несовместимости версий. По его мнению, если выйдет GPL v4, в неё нужно будет включить пункт, который допускает переход на более поздние версии лицензии.

Перелицензировать программу. Перелицензирование применяется при разработке ПО с открытым исходным кодом, когда лицензии на отдельные модули программ несовместимы, но их как-то нужно использовать вместе. Часто перелицензирование становится единственным способом решения.

Чтобы перелицензирование имело юридическую силу, требуется согласие всех заинтересованных правообладателей на изменение лицензии. Поскольку в отношении свободных программ трудно достигнуть стопроцентного охвата всех авторов из-за большого количества участников free- и open-source-проектов, часто достаточно подавляющего большинства.

Например, в Mozilla Foundation считали достаточным 95% охвата. Браузер Mozilla Firefox стал одним из первых проектов с открытым исходным кодом, в котором успешно применили перелицензирование.

Исходный код браузера Netscape Communicator 4.0 первоначально выпустили под лицензией Netscape Public License / Mozilla Public Licence, но FSF и OSI раскритиковали его за несовместимость.

Затем в 2001 году Time Warner, используя свои права в соответствии с Публичной лицензией Netscape и по просьбе Mozilla Foundation, перелицензировала весь код под публичной лицензией Netscape (включая код других авторов), на MPL v1.1 / GPL v2.0 / LGPL v2.1.

Некоторые строгие копилефт-лицензии позволяют перелицензировать программу под другие копилефт‑лицензии. Например, CeCILL включает условие о совместимости с GNU GPL v2.0 и более поздними версиями. В GNU LGPL 2.1 явным образом разрешается перелицензирование на основе GNU GPL v2.0 и более поздних.

GNU LGPL v3, по сути, представляет собой GNU GPL v3 с некоторыми дополнительными разрешениями. В разделе 7 LGPL v3 говорится, что дополнительные разрешения всегда можно удалить. В результате программа перелицензируется под обычную GNU GPL v3.

Если программа допускает применение под GNU LGPL v2 или более поздней версии, её можно перелицензировать на основе GPL v3 или более поздней. Столлман отмечает, что для каждой будущей GPL версии N (N > 3) FSF будет делать LGPL версии N с дополнительными разрешениями.

Перелицензирование — хороший способ преодолеть несовместимость, но он не работает в обе стороны. То есть если лицензия А допускает перелицензирование на лицензию Б, то лицензия Б может не допускать перелицензирование на А.

Например, лицензия CC BY-SA 4.0 допускает перелицензирование изменённых версий на условиях GNU GPL v3, но GPL v3 не допускает переход на CC BY-SA. Лицензии Creative Commons в целом не предназначаются для софта. Но в некоторых случаях, когда речь идёт о чертежах аппаратуры и художественных вставках в компьютерных играх, нужно объединить материал, выпущенный под CC BY-SA, с материалом под GNU GPL. Это возможно благодаря условию о перелицензировании CC BY-SA.

Если перелицензирование прямо не предусмотрено в тексте соглашения, оно не допускается. Заметьте: условие о совместимости и условие о перелицензировании — не одно и то же.

Например, лицензии GNU GPL v3 и GNU AGPL содержат условие о совместимости, но перелицензировать программу с GPL на AGPL и наоборот нельзя — ни одна из лицензий этого не допускает. Кроме того, GNU AGPL v3 нельзя считать «более поздней версией» обычной GNU GPL v2, потому что GNU AGPL и GNU GPL — это две разные лицензии.

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

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

Эту схему также можно рассматривать как способ преодоления несовместимости свободных лицензий: если хотя бы одна из свободных лицензий одной программы совместима со свободной лицензией другой программы, вы можете использовать обе эти программы в своём продукте.

Например, исходный код Mozilla Application Suite использовал тройное лицензирование под MPL 1.1, GNU GPL v2.0 и LGPL v2.1. После того как появилась GPL-совместимая версия MPL v2.0, тройное лицензирование стало ненужным.

Ещё более яркие примеры — Perl с двойной лицензией под GNU GPL и Artistic License и Ruby, у которого в соглашении прописано условие о двойном лицензировании с GNU GPL.

В случаях с двойным или мультилицензированием FSF рекомендует выбирать GNU GPL v3.0 (или более позднюю) или другую, совместимую с ней лицензию. Таким образом вы получите совместимость почти со всеми свободными программами. GPL, AGPL v3 и более поздние версии лучше всех защищают свободу пользователей, по мнению приверженцев строгого копилефта.

На сайте FSF можно найти таблицу совместимости лицензий GNU и перечни свободных лицензий, совместимых и несовместимых с лицензиями GNU GPL.

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

Чтобы на него ответить, составьте перечень всех лицензий комбинированной программы и определите, какие из них имеют определяющее значение для проекта.

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

Например:

  • GNU GPL версии N, и GNU Affero GPL версии N охватывают LGPL версии N, а все три охватывают LGPL версии 2.1.
  • Любая лицензия GNU версии N охватывает лицензию Apache 2.0 при N >= 3.
  • GNU GPL версии N охватывает все версии Общественной лицензии Mozilla, которые с ней совместимы.
  • Лицензия Apache 2.0 охватывает лицензии BSD, Expat, X11, ISC и СС0.
  • Трёхпунктная BSD охватывает двухпунктную BSD.
  • Лицензии BSD охватывают лицензии Expat, X11 и ISC, а также CC0.

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

Если свободные лицензии не содержат взаимно исключающих условий, то они, скорее всего, совместимы. Часто на совместимость указывает текст лицензии. Разработчик может и сам оговорить совместимость разных видов лицензий или новых версий лицензии с её старыми версиями.

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


Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу