Совместимость свободных и open‑source‑лицензий: подробный гайд

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

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

Что нужно знать вначале

Если вы используете 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-проектов, часто достаточно подавляющего большинства.

Некоторые строгие копилефт-лицензии позволяют перелицензировать программу под другие копилефт‑лицензии. Например, 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 с дополнительными разрешениями.

Лицензия в один конец

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

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

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

Совместимость свободных лицензий и двойное лицензирование

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

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

В случаях с двойным или мультилицензированием 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.

Что в итоге

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

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

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