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

Ричард Столмен

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

Если у программ одна и та же лицензия, проблем не возникает, если лицензия составлена разумно, как почти все лицензии свободных программ.[2]

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

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

В целом безвольные неограничительные лицензии (измененная лицензия BSD, X11, Expat, Apache, Python и т.д.) совместимы друг с другом. Дело в том, что в них нет требований к другим текстам, которые добавляются к программе. Они даже допускают обращение всей программы (возможно, с изменениями) в несвободный программный продукт; таким образом, мы называем их “безвольными лицензиями”, потому что они не говорят “нет”, когда один пользователь пытается отказать в свободе другим.

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

Подобным же образом, безвольные лицензии обычно совместимы со всякой лицензией с авторским левом. В объединенной программе части, которые были под безвольными лицензиями, по-прежнему находятся под ними, но вся программа в целом несет лицензию с авторским левом. В одной безвольной лицензии, Apache 2.0, есть патентные пункты, несовместимые с GPL версии 2; поскольку я думаю, что такие пункты полезны, я сделал версию 3 GPL совместимой с ними.

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

Я по большей части устранил эту проблему, убедив декана, Гела Вериэна, организовать публикацию Калифорнийским университетом в Беркли “модифицированной лицензии BSD” (без пункта о рекламе) и перевыпуска программ BSD под этой лицензией. Сегодня первоначальная лицензия BSD (к счастью) практически не применяется, но мы до сих пор должны принимать меры, чтобы не говорить о (“единственной”) лицензии BSD.

В общем и целом, две разные лицензии с авторским левом неизбежно несовместимы, если совместимость не оговорена в них явным образом. Это не связано с ошибкой в деталях; это следствие принципов авторского лева. Суть авторского лева заключается в том, что “измененные и расширенные версии должны быть под той же самой лицензией”. Если в лицензии А (на программу П) сказано, что расширенные программы должны быть под лицензией А, а в лицензии Б (на программу Р) сказано, что расширенные программы должны быть под лицензией Б, то это неустранимое разногласие; лицензия совмещенной программы, которая содержит части из П и части из Р, должна быть лицензией А и она должна быть лицензией Б.

Вот почему GPL версии 2 несовместима с GPL версии 3; избежать этого было невозможно. Точно так же условия CC BY-SA 4.0 были бы принципиально несовместимы с условиями CC BY-SA 3.0, и авторам не удалось бы этого избежать.

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

Подход ФСПО состоит в том, чтобы просить людей выпускать программы под “GNU GPL версии N или любой более поздней”. Это совместимо с версией N, а также N+1 (потому что версия N+1 предлагается как вариант). Когда вы объединяете программы под “GPL версии 3 или более поздней” с программами под “GPL версии 2 или более поздней”, лицензия объединенной программы является их пересечением, то есть “GPL версии 3 или более поздней”.

Мы надеемся, что нам никогда не потребуется GNU GPL версии 4, но ничто не совершенно, так что мы не можем рассчитывать, что предусмотрели все. Выпуская свои программы под GNU GPL версии 3 или более поздней, вы разрешаете обновление до GNU GPL версии 4, если она нам потребуется.

Другой подход состоит в том, чтобы в каждой версии лицензии явным образом допускать обновление до более поздних версий. Этот подход применяет Mozilla Foundation, как и PHP. Creative Commons применяет его для CC BY-SA: версия 4.0 (текущая) любому пользователю явным образом разрешено обновляться до более поздних версий CC BY-SA для модифицированных работ.

Только лицензии GNU предоставляют авторам выбирать, разрешить ли обновление до будущих версий лицензии. Когда в 1989 году я писал первую версию GNU GPL, я рассматривал возможность обновлять лицензию, как это делается в лицензиях Creative Commons, но я подумал, что правильнее оставить это на выбор каждому автору. Таким образом, автор мог выпускать программу либо “только под GPL версии 1”, либо под “GPL версии 1 или более поздней”.

Прошло время, и я стал сомневаться в мудрости этого решения. Такие программы, как Linux, которые допускают только одну версию GNU GPL и отвергают обновления, на практике приводят к несовместимости.[4] Если мы когда-нибудь напишем GPL версии 4, возможно, нам следует включить пункт об обновлении, который автоматически разрешает перелицензирование на версии с повышением номера — 5 и выше.

Некоторые лицензии с авторским левом допускают сочетания программ под разным авторским левом с помощью явного пункта о перелицензировании, дающего разрешение помещать программы под другую лицензию с авторским левом. Например, в CeCILL дается явное разрешение перелицензировать программы под GNU GPL версии 2 и более поздних. Если программа А распространяется по CeCILL, а вы хотите совместить ее с программой Б, которая распространяется по GPL версии 3 или более поздней, то в CeCILL сказано, что это допустимо и что объединенные программы должны распространяться по GPL версии 3 или более поздней.

Явное разрешение перелицензировать — это не то же самое, что совместимость (хотя перелицензирование может сделать лицензию совместимой с лицензией другой программы), и оно не взаимно. Например, в CeCILL дается явное разрешение перелицензировать программы на GNU GPL, но GNU GPL не допускает перелицензирование на CeCILL. Таким образом, нельзя объединить эти две программы А и Б и распространять результат под CeCILL; это было бы нарушением GPL в отношении программы Б. Эту объединенную программу разрешено выпускать только под GPL соответствующих версий.

Подобным образом CC BY-SA 4.0 явно разрешает перелицензирование измененных версий на GNU GPL версии 3, но GPL версии 3 не допускает перелицензирования на CC BY-SA. Для программ это никогда не должно быть проблемой; по заявлению Creative Commons, его лицензии не предназначены для программ, для них предназначена GNU GPL. Но есть работы других видов, такие как чертежи аппаратуры и художественные вставки в играх,— в этих произведениях иногда появляются предпосылки объединять материал, выпущенный под CC BY-SA, с материалом, выпущенным под GNU GPL. Это можно сделать благодаря явному разрешению перелицензировать в CC BY-SA.

К сожалению, CC BY-SA 4.0 не разрешает перелицензировать на будущие версии GPL. Вам, когда вы перелицензируете материал под CC BY-SA 4.0 на GPL, надо указать себя в качестве посредника, определяющего версию лицензии, чтобы указать, разрешены ли будущие версии GPL для этого материала. Если когда-нибудь будет GPL версии 4 и Creative Commons решит позволить перелицензировать с CC BY-SA на GPL версии 4, вы как посредник сможете задним числом санкционировать GPL версии 4 для этого перелицензированного материала. (Вместо этого можно также попросить авторов этого материала непосредственно выдать разрешение.)

Обычная Стандартная общественная лицензия GNU и Стандартная общественная лицензия GNU Афферо (GNU AGPL) представляют две различных лицензии с авторским левом, так что они, естественно, несовместимы. Мы явным образом установили особого рода совместимость между ними: исходный текст под GNU GPL версии 3 можно включать в одну программу с другим исходным текстом, выпущенным под GNU GPL Афферо. Это разрешено, потому что в обеих лицензиях это оговаривается явным образом, и в результате получается произведение, на которое распространяется GNU GPL Афферо. Однако просто перелицензировать программы с GNU GPL (с “более поздними версиями“ или без них) на GNU AGPL и наоборот нельзя; ни одна из лицензий этого не допускает. Обратите также внимание, что GNU AGPL версии 3 не является “более поздней версией” обычной GNU GPL версии 2, потому что GNU AGPL и GNU GPL представляют два различных ряда лицензий.

Меньшая стандартная общественная лицензия GNU версии 3 в действительности представляет Стандартную общественную лицензию GNU версии 3 с некоторыми дополнительными разрешениями. В разделе 7 GPL версии 3 говорится, что дополнительные разрешения всегда можно удалить, тем самым вы получаете те же программы под обычной GNU GPL версии 3. Если программа допускает применение под GNU LGPL версии 2 или более поздней, ее можно перелицензировать на GPL версии 3 или более поздней; для каждой будущей GPL версии N (N > 3) мы будем делать LGPL версии N, состоящей из GPL версии N с дополнительными разрешениями.

Что касается GNU LGPL версии 2.1, то в ней явным образом разрешено перелицензирование на GNU GPL версии 2 или более поздней.

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

Наконец, что можно сказать о двойном лицензировании?[5] Двойная лицензия представляет дизъюнкцию: это значит, что программа предоставляет на выбор две или более различных лицензий. Например, старые версии Perl предоставляли две лицензии: дизъюнкцию Стандартной общественной лицензии GNU и Артистической лицензии. Это означало, что каждый пользователь мог выбрать и перераспространять Perl под той или другой лицензией, или под дизъюнкцией обеих, как и сам выпуск Perl. Дизъюнкция совместима с набором других лицензий, если хотя бы одна из лицензий в дизъюнкции совместима с этим набором.

Когда вы выбираете лицензию для своих программ, выбирайте, пожалуйста, GNU GPL версии 3 или более поздней или какую-то совместимую с этим лицензию. Таким образом вы сделаете свои программы сочетаемыми почти со всем корпусом свободных программ. Выбор GPL или AGPL версии 3 или более поздней защитит также свободу всех пользователей всех версий вашей программы наилучшим образом.

Комбинация программ

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

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

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

Мы говорим, что лицензия А охватывает лицензию Б, когда из удовлетворения условиям лицензии А следует, что удовлетворяются условия лицензии Б.

Например, и GNU GPL версии N, и GNU GPL Афферо версии N охватывают Меньшую GPL версии N, а все три охватывают Меньшую GPL версии 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.

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

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

Примечания

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

2. Главная из применяемых в настоящее время лицензий, которая несовместима сама с собой — лицензия TeXа: если две программы лицензированы так, как TeX, нет разрешенного способа распространять их объединенную версию.

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

   Не случайно TeX выпустили в 1982 году: с тех пор наше сообщество научилось писать разумные лицензии.

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

4. В дополнение, GPL версии 2 все же позволяет делать двоичные файлы несвободными с помощью аппаратуры, которая работает только со специально подписанными файлами программ; кроме того, GPL версии 2 не допускает распространение двоичных файлов торрентами. В версии 3 мы исправили это и кое-что другое, но мы не можем изменить версию 2.

5. Некоторые употребляют выражение “двойное лицензирование” для обозначения продажи исключений, но это неправльное название. См. Продажа исключений. Обратите внимание, что если в программу, лицензия на которую продается в качестве исключения, входят любые тексты, не входящие в свободный выпуск, то это не продажа исключений — это несвободные программы.