Лицензии для открытых и бесплатных проектов. Все что нужно знать о лицензировании, чтобы не нарушить закон

Эта информация пылится в архиве — вдруг устарела.

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

Поделитесь этой статьей с друзьями и коллегами

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

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

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

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

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

Свободные лицензии

GPLv3 (GNU General Public License Version 3)

Самая известная из свободных лицензий. Так как она называется свободной, многие ошибочно считают, что код, выпущенный под GPL, можно использовать как угодно, а программы могут/должны быть только бесплатными. И то, и другое неправда. GNU GPL – копилефтная лицензия и требует, чтобы исходные коды производных работ были открытыми под ней же.

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

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

GPLv3 (GNU General Public License Version 3):

GPLv2 (GNU General Public License Version 2)

О различиях между этой и более поздней версией GPL можно почитать, например, в этой статье.

GPLv3 заметно строже и может создать некоторые проблемы автору. Например, одно из требований состоит в том, что должна быть предоставлена инструкция по установке измененного приложения на устройство. Для приложений под iOS или WindowsPhone, где нет штатной возможности установить пакет не из магазина, выполнить такое требование проблематично.

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

GPLv2 (GNU General Public License Version 2):

LGPLv3 (GNU Lesser General Public License Version 3)

LGPL – это надстройка над GPL, и требует наличия текстов обеих лицензий в проекте. Отличие LGPL от обычной GPL заключается в том, что библиотеке под этой лицензией разрешается использовать для создания программ под другими лицензиями путем компоновки.

Согласно GNU FAQ динамическая компоновка не требует открывать исходные коды, а при статической необходимо предоставлять вашу программу в объектной форме (исходные коды не обязательны), для того чтобы пользователь мог сам изменить библиотеку и перелинковать бинарник. GNU рекомендует применять эту лицензию только в том случае, если применение вместо нее обычной GPL приведет к тому, что библиотеку перестанут использовать, заменив на аналогичную.

LGPLv3 (GNU Lesser General Public License Version 3):

Как применять лицензии GNU со своими программами.

GNU AGPLv3 (GNU Affero, GNU Affero General Public License Version 3)

Цитируя Различные лицензии и комментарии:

Ее условия фактически состоят из условий GPLv3 с дополнительным параграфом в разделе 13, который позволяет пользователям, взаимодействующим с лицензируемой программой по сети, получать исходный текст этой программы. Мы рекомендуем разработчикам подумать о применении GNU AGPL для любых программ, которые обычно выполняются в сети.

Есть определенные нюансы совместимости с другими версиями GPL:

Обратите внимание, что GNU AGPL не совместима с GPLv2. Она также формально не совместима с GPLv3 в узком смысле: вы не можете взять исходные тексты, выпущенные на условиях GNU AGPL, и передавать или изменять их как вам угодно, на условиях GPLv3 и наоборот.

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

GNU AGPLv3 (GNU Affero, GNU Affero General Public License Version 3):

Как применять лицензии GNU со своими программами.

MPL v2.0 (Mozilla Public License Version 2.0)

Для проекта open source стоит еще рассмотреть MPL 2.0. Своеобразная лицензия, что-то среднее между LGPL и BSD. От LGPL отличается отсутствием заморочек со статическим связыванием. Это может оказаться важным для программ на ЯП, в которых динамическое связывание не предусмотрено.

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

Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить – ограничений нет.

В случае если проект под GNU GPL, необходимо сделать используемый в нем код под MPL 2.0 доступным сразу под обеими лицензиями.

Для использования этой лицензии в вашем проекте нужно добавить текст из Exhibit A лицензии

This Source Code Form is subject to the terms of the Mozilla

Public License, v. 2.0. If a copy of the MPL was not distributed

with this file, You can obtain one at //mozilla.org/MPL/2.0/.

в качестве шапки в каждый файл исходного кода. Лицензия не требует указывать copyright в каждом файле, но и не запрещает этого. Также не забудьте добавить в проект файл LICENSE с текстом лицензии.

MPL v2.0 (Mozilla Public License Version 2.0).

EPL-1.0 (Eclipse Public License Version 1.0)

Это копилефтная лицензия, но она не совместима с GNU GPL.

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

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

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

EPL-1.0 (Eclipse Public License Version 1.0).

Ms-PL (Microsoft Public License)

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

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

Для применения к своему проекту: скопируйте текст лицензии в ваш проект (например, в файл LICENSE) и распространяйте его вместе с ним.

Ms-PL (Microsoft Public License).

MIT

Существует миф, что лицензия MIT существует. Дело в том, что MIT (Massachusetts Institute of Technology) использовал много разных лицензий. Тот текст, который сейчас называют лицензией MIT, в оригинале являлся лицензией Expat, а еще ранее составлял большую часть лицензии X11. Эта лицензия разрешительная, без копилефта.

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

Из-за этого вместо нее GNU рекомендуют использовать другую разрешительную лицензию – Apache 2.0, а MIT предлагают использовать лишь для небольших проектов. Тем не менее из разрешительных лицензий эта, пожалуй, самая известная.

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

MIT

Apache 2.0

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

Для применения лицензии Apache 2.0 к вашему проекту нужно добавить в него файл LICENSE, содержащий текст лицензии. Кроме того, в APPENDIX лицензии нам предлагают добавлять в качестве шапки в каждый файл исходного кода следующий текст:

Licensed under the Apache License, Version 2.0 (the «License»);

you may not use this file except in compliance with the License.

You may obtain a copy of the License at

//www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an «AS IS» BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.

Но при этом сама лицензия выдвигает следующие требования:

made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below)

copyright notice – это как раз строка, указывающая правообладателя. А «made available under the License, as indicated» означает, что еще должна быть явно указана лицензия. То есть допустимо что-то вида:

Licensed under the Apache License, Version 2.0

Причем совсем не обязательно в исходном коде – Apache 2.0 позволяет для этого использовать файл NOTICE («or attached to the work»).

И еще о файле NOTICE: если в вашей работе вы используете чужой проект под лицензией Apache 2.0, содержащий свой файл NOTICE, то в этом случае вы обязаны копировать в производную работу содержимое файла NOTICE, в одно из трех мест: либо в аналогичный файл NOTICE, либо в исходные коды или документацию, распространяемую вместе с производной работой, либо в вывод производной работы (например в about-диалог); все согласно пункту 4 (d) лицензии. Заметьте, что, вопреки расхожему мнению обязательного наличия файла NOTICE лицензия не требует.

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

Apache 2.0

BSD

Это разрешительная лицензия, схожая по смыслу с лицензией MIT. Оригинальная лицензия BSD состояла из 4-х пунктов, но впоследствии 3-й пункт, требовавший включать уведомление об авторстве во все рекламные материалы, был исключен. Кроме того, существует и двухпунктовая лицензия BSD, в ней удален третий пункт, и эта версия практически совпадает по функциональности с лицензией MIT. GNU советуют вместо лицензии BSD использовать MIT, чтобы исключить путаницу с тем, какая именно версия лицензии BSD используется.

Для ее применения к своему проекту создайте текстовый файл LICENSE и поместите текст лицензии туда. Не забудьте добавить строку с копирайтом. Также дополнительно можно указать полный текст лицензии в шапке каждого файла исходного кода.

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

BSD

Общественное достояние (Public Domain)

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

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

CC0 (Creative Commons CC0)

Creative Commons CC0 – лицензия, которая пытается перевести проект в общественное достояние в максимальной форме, разрешенной законом. А если закон не позволяет это совершить, автоматически применяет положения разрешительной лицензии. GNU рекомендует применять CC0 в том случае, если вы хотите перевести вашу работу в общественное достояние.

Про применение CC0 к проекту можно прочитать в этой статье.

CC0 (Creative Commons CC0).

Copyright в исходниках

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

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

Но все же такой заголовок лучше иметь. Основные причины следующие.

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

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

Copyright – так как в некоторых странах одного символа копирайта недостаточно для юридической значимости уведомления.
© – символ копирайта, в большинстве стран он необходим и достаточен для придания юридической значимости уведомлению. Простой буквы c в скобках (c) для этого может быть недостаточно.
2007, 2009, 2010-2012 – «годы жизни» кода, первое число – год, когда продукт был впервые опубликован, далее – годы, когда код обновлялся. Если годы, когда код в файле правился, идут не подряд, то их нужно указывать через запятую.
John Doe – имя владельца авторских прав. Не автора, это могут быть разные лица! Может быть именем человека, названием компании или именами нескольких человек. Правда, в последнем случае лучше сделать отдельную строчку на каждого человека.
Если возможно, то дать ссылку на лицензионный договор или указание, где его искать.
Указать контактные данные.
Обратите внимание, что имя автора в уведомление не входит. Автора/авторов можно указать отдельно, например, на следующей строке, в свободной форме (например, Author: Jane Doe).

Пример:

Полезные ссылки

Описание лицензий и особенностей их применения (в том числе в России) – LicenseIT.
Большой список свободных лицензий на сайте GNU.
Список с open-source лицензиями на английском языке.

По материалам: Лицензия для вашего open-source проекта.