Прежде всего, хочу заметить, что сам являюсь горячим сторонником идей, лежащих в основе движения Open Source. Однако в последнее время и у нас, в России и за рубежом, появляется все больше критических статей, вскрывающих различные недостатки этого движения. Данная статья является попыткой обобщения конструктивной критики движения Open Source, несколько приправленная собственными размышлениями автора на эту тему.
Прежде чем приступить к критическому анализу, давайте еще раз озвучим те причины, что сподвигли Ричарда Столмена создать GNU. Это засилие закрытого программного обеспечения (ЗПО). Что означает закрытость? Закрытость в данном случае означает, (а) что вы, как пользователь, купивший программу, не имеете права делиться ею с кем бы то ни было, (б) изучать, как устроена эта программа, (в) изменять ее для своих нужд. Каким образам это достигается? Во-первых, это лицензионное соглашение, во-вторых, отсутствие исходного кода программы.
На заре компьютерной эры все программы были открытыми, хакеры (тогда пользователями были только хакеры) свободно делились друг с другом программами и их исходниками. И был рай на земле:). Но вот, у компьютеров появились пользователи! Компьютеры, а значит, и программы, стало выгодно продавать. Естественно, компании стали закрывать свои программы, и рай закончился. Проект GNU - есть ни что иное, как попытка вновь обрести его. :)
Чем опасно закрывание программ? Лучше всего, на этот вопрос отвечает сам Столмен, например . Я приведу лишь несколько примеров. Запрет делиться с кем-либо своей копией программы создает нездоровую обстановку в обществе. Столмен приводит такой пример: один хакер приходит к другому и говорит,
- Слышь, друг, у меня тут ваш драйвер для принтера глючит, дай мне его сырцы, я себе подправлю.
А тот ему и отвечает,
- Извини, друг, не могу, меня за это уволят.
Другими словами, этот запрет подрывает основы сотрудничества. Последние два запрета, на изучение и изменение программ приводят к снижению образовательного уровня программистов. Каждый раз, когда они пытаются разобраться в новой технологии, их "бьют по рукам" лицензионным соглашением.
Кто-то может сказать, что, мол, лицензия нам не указ, куда надо залезем, и что надо изучим. Да, так сейчас и происходит, но давайте вдумаемся, какое правовое сознание культивируется при этом в обществе? Правильно, ни какого, и это еще одна причина, побудившая Столмена создать GNU.
Каким образом можно решить эти проблемы? Программы должны быть свободными! Что это означает? Для ответа на этот вопрос давайте заглянем в GNU GPL (это лицензия, под которой выпускается свободное ПО). Если коротко и очень упрощенно, то GPL - это лицензия на программное обеспечение (ПО), которая предоставляет вам пять основных прав:
- Вы, как автор программы, оставляете за собой право авторства программой
- Вы можете использовать программу (здесь, и далее, идет речь о программе, лицензированной под GPL)
- Вы можете модифицировать программу
- Вы можете свободно распространять программу
- Вы можете получать прибыль продавая программу, или осуществляя любую другую коммерческую деятельность, связанную с программой, но не подпадающую под пункт об использовании. При этом Вы обязаны распространять ее вместе с исходниками
GPL ЛИШАЕТ вас права лишать кого бы то ни было перечисленных выше прав. Забавный каламбур, не правда ли? Означает это буквально следующее: при передаче кому-либо копии программы, Вы обязаны передать ему все те права и обязанности, которые накладывает на вас эта лицензия. Другими словами, вы не можете перелицензировать программу. Это необходимо для того, чтобы защитить программу, и, соответственно, сообщество свободного программного обеспечения от недобросовестных предпринимателей, которые в противном случае могли бы использовать код программы в своем закрытом продукте. Этот пункт вынуждает их либо не использовать программу вовсе, либо выпустить свой продукт под GPL, обогатив, тем самым, сообщество. Подробнее об этом механизме можно почитать .
Теперь давайте перечислим основные недостатки GNU GPL, и, соответственно, порождаемого ею рынка свободного ПО. В самом деле, любая лицензия порождает рынок.
- Отсутствие четкой схемы финансирования со стороны пользователя, что приводит к отсутствию, либо плохому качеству программ, необходимых пользователям.
- "Закрытость" программ с открытым кодом. Забавно звучит, не правда ли?
Что касается первого пункта, то здесь все более менее ясно, прибыль получают фирмы, занимающиеся продажей дистрибутивов свободного ПО и всякого рода сопровождением и обучением. Дойдут ли деньги до конкретного программиста или нет - это уж как получится, скорее всего нет.
А вот как вам утверждение, что открытые программы на самом деле являются закрытыми? Что имеется в виду? Когда создавалась GNU GPL, не было еще так называемой "проблемы больших проектов". Заключается она в том, что для очень большого и сложного проекта гораздо более ценной оказывается информация о концепциях, идеях, заложенных в его основу, чем исходный код. Фактически, в большем преимуществе оказывается та группа программистов, что владеет идеями, а не исходным кодом. Более подробно об этом можно почитать в статье одного нашего бывшего соотечественника.
Другими словами, информация о ключевых концепциях проекта становится тем капиталом, который позволяет удержать власть над проектом, даже при условии распространения вместе с исходниками. Подрывается сам принцип GNU - свободные программы. Здесь это следует читать как свободные идеи, в самом деле, ведь изначальная суть в этом. Идеи должны быть свободными!
В упомянутой выше статье подчеркивается, что этот способ "закрывания" программ сейчас широко используется в мире "свободного" ПО, в том числе и в таких ключевых проектах, как разработка ядра Linux.
Отчего же так происходит? Может, злые враги проникли в наш стан? Нет, это делают люди, самоотверженно работающие на благо сообщества свободного ПО (СПО). Но почему? Чтобы ответить на этот вопрос, нам придется сделать небольшой экскурс в психологию личности.
В общем смысле, вслед за Фромом, можно выделить два основных архетипа человека: творец и потребитель. Творцу просто в радость создать что-то и отдать это людям - пусть пользуются. Такие люди создали GNU. Потребитель испытывает постоянную потребность поглощать; деньги, славу, власть и т.д. Желающих узнать, почему так происходит, и как эти архетипы формируются в конкретных людях отсылаю к Фрейду и все тому-же Фрому. Реально, в каждом человеке реализованы оба этих архетипа, но в разной степени. Кто-то больше творец, кто-то потребитель. Но даже в самом чистом творце есть маленькая жилка потребителя.
Давайте теперь посмотрим через эту призму на людей, возглавляющих ключевые проекты ядра Linux. Безусловно, они творцы, на них стоит равняться, но что же происходит с той маленькой "жилкой" потребителя, собственника? Она реализует себя в _обладании_ ключевыми идеями проекта, а значит, и обладании проектом. В самом деле, если эти идеи открыть, то каждый достаточно талантливый программист сможет встать на его место. Именно эта "жилка" заставляет "творца" удерживать ключевые идеи проекта.
Как же с этим боротся? Во-первых, нужно внести изменение в лицензию, обязывающие распространять не только исходный код, но и документацию ключевых идей и концепций, на которых основан проект. Во-вторых, чтобы удовлетворить все-таки, потребительскую "жилку", а от нее нам ни куда не деться, это наша природа, необходимо обеспечить механизм достойного вознаграждения труда программистов, создающих открытое ПО. В самом деле, деньги - хороший эквивалент славе и власти.
Ага, опять прозвучало слово "деньги"! Если помните, первый из обсуждаемых нами недостатков GNU GPL заключается в отсутствии четкой схемы финансирования со стороны потребителя, мы вновь на него вышли.
Можно ли решить эти проблемы, оставаясь в рамках Свободного ПО? Да, можно, и, более того, нужно! Проблема давно назрела, ее НАДО решать. Решение, которое я предлагаю, называется Copymiddle, в отличие от Copyright и Copyleft. Автором такого названия является Антон Первенцев , за что ему отдельное спасибо.
Остановимся здесь, и вновь посмотрим на GPL. Кто этот загадочный "Вы", которого наделяет правами и обязанностями GPL? Методом "пристального вглядывания" приходим к выводу, что это, на самом деле, три различных сущности: ПРОГРАММИСТ, ПРЕДПРИНИМАТЕЛЬ, ПОЛЬЗОВАТЕЛЬ. ППП, прямо святая троица получается. :)
Давайте переформулируем нашу вольную трактовку GPL, заменяя магическое "Вы" на его истинное содержание.
- ПРОГРАММИСТ может модифицировать программу
- ПРЕДПРИНИМАТЕЛЬ может получать прибыль продавая программу, или осуществляя любую другую коммерческую деятельность, связанную с программой, но не подпадающую под пункт об использовании. При этом Он обязан распространять ее вместе с исходниками
Другими словами, ПРОГРАММИСТ имеет право программировать, ПОЛЬЗОВАТЕЛЬ имеет право пользоваться, ПРЕДПРИНИМАТЕЛЬ имеет право зарабатывать деньги. Заводы рабочим, землю крестьянам! Социализм в чистом виде. В нашей стране идеи социализма, на сегодняшний день, сильно дискредитированы, однако социализм - это то, к чему человечество рано или поздно придет, конечно, если по пути ножки не поломает:). Попробуем теперь понять, как изменить GPL так, чтобы сохранив СВОБОДУ, которую она нам дает, внести в нее фактор экономического развития.
Решение напрашивается само собой. Оставим ПОЛЬЗОВАТЕЛЯ в покое, возьмем немножко прав у ПРЕДПРИНИМАТЕЛЯ и отдадим их ПРОГРАММИСТУ. Например, обяжем ПРЕДПРИНИМАТЕЛЯ отчислять 10% от своей прибыли, полученной от коммерческой деятельности, связанной с распространением, сопровождением и т.д. программисту.
Добавим сюда обязанность распространять вместе с программой и ее кодом еще и идеи, заложенные в ее основу, и получим новый тип лицензии на "Свободное ПО". Я бы назвал ее GPL+- :). Плюс - соответствует экономическому фактору развития, который эта лицензия привносит в GPL и истинной свободой идей. Минус - это та цена, которую мы за это платим, - взаимное правовое неравенство игроков в новом правовом мире, порожденном лицензией GPL+-. Однако очевидно, что это минимальная цена, которую мы можем заплатить.
Вот что у нас получилось в итоге. Это вольное изложение GPL+-, или Copymiddle.
- ПРОГРАММИСТ, как автор программы, оставляет за собой право авторства программой
- ПОЛЬЗОВАТЕЛЬ может использовать программу
- ПРОГРАММИСТ может модифицировать программу и получать свой авторский гонорар за коммерческое использование программы
- ПРОГРАММИСТ ПОЛЬЗОВАТЕЛЬ и ПРЕДПРИНИМАТЕЛЬ могут свободно распространять программу
- ПРЕДПРИНИМАТЕЛЬ может получать прибыль продавая программу, или осуществляя любую другую коммерческую деятельность, связанную с программой, но не подпадающую под пункт об использовании. При этом Он обязан распространять ее вместе с исходниками и идеями, существенно необходимыми для понимания внутренней структуры программы. Также, ПРЕДПРИНИМАТЕЛЬ обязан отчислять 10% (для определенности) от своих доходов, полученных от коммерческого использования программмы ее автору.
На самом деле, думаю, нам нужно несколько GPL+- подобных лицензий. Собственно, GPL+-, для лицензирования свободного ПО. GPDL+- то же самое, но для документации и художественных текстов, ее отличие в том, что вы не можете вносить изменения без разрешения автора (это к примеру, здесь возможны варианты). И последнее, нужна еще более прокомерческая лицензия GPCL+- (GP Commerce L+-) для лицензирования таких программ, как, например, компьютерные игры. Ее отличие от GPL+- в том, что под коммерческую деятельность ПРЕДПРИНИМАТЕЛЯ будет подпадать и использование программы, конечно, если при этом извлекается прибыль. Речь идет об использовании игр в компьютерных клубах, там на этом зарабатывают деньги, так пусть и отчисляют автору его процент. :) Естественно, компьютерные игры - не единственное поле применения такой лицензии.
В заключение отмечу, что не выясненными остались многие вопросы, касающиеся реализации нового типа лицензирования свободного ПО. Эти вопросы будут подробно обсуждаться в статье "Что такое GPL+-?" следите за рекламой:)
3 октября 2002 г. Новосибирск.
Владимир И. Торшин
Владимир И. Торшин - Почему вам не следует использовать GNU GPL для лицензирования своих программ?
Рано или поздно каждый разработчик сталкивается с вопросом лицензирования своих разработок. Более или менее понятно, когда разрабатывается коммерческий продукт с закрытым кодом. Но когда разработчик желает распространять программу, плагин или библиотеку классов бесплатно и с открытыми кодами, то могут возникнуть трудности, потому что в природе существует масса лицензий подобного рода. Эта статья призвана собрать, упорядочить данные по лицензиям и вычленить самое главное.
UPD
: опубликован перевод небольшого куска официального GPL FAQ habrahabr.ru/blogs/Dura_Lex/45878
UPD2
: скорректирован и переформулирован список совместимых лицензий
Если касаться мира «свободных» лицензий, то основным столпом и стержнем можно посчитать GNU General Public License (GPL). И в этой статье я хотел бы разделить лицензии, которые попадают под GNU GPL и описать все другие, которые не попадают под условия этой лицензии. Первая часть статьи будет описывать саму GNU GPL, ее краткую историю, другие лицензии, которые похожи на нее. В конце я приведу небольшой словарик терминов и сокращений.
GNU General Public License
Вначале хотелось бы пояснить что такое «GNU». GNU расшифровывается как «GNU"s not UNIX» - это рекурсивный акроним придуманный Ричардом Столлманом, известным идеологом открытого и свободного программного обеспечения. Такое название было придумано для операционной системы, которую в 80-х годах разрабатывал Столлман. История GNU заслуживает отдельной статьи поэтому я перейду сразу к делу.GNU General Public License или открытое лицензионное соглашение GNU - это лицензия, первый вариант которой датируется 1 февраля 1989 года (википедия сообщает о 1988 г, но я считаю дату которая стоит на оригинале). На сегодняшний день существует четыре варианта лицензии, которые нумеруются в порядке появления.
GNU GPL v1.0
Основными позициями GNU GPL v1.0 стали следующие требования:- предоставление исходных кодов, доступных для изучения, к бинарным кодам публикуемым с данной лицензией;
- наследование лицензии в случае модификации исходного кода, то есть модифицированный или объединенный с другим код в результате так же должен быть выпущен под лицензией GNU GPL, следовательно, быть доступным для модификации любым желающим.
GNU GPL v2.0
Вторая версия лицензии датируется 1991 годом и основным мотивом провозглашает (согласно wiki) принцип «Liberty or Death» (Свобода или Смерть). Этот принцип заключен в седьмом и восьмом пункте соглашения:7. Лицензиат не освобождается от исполнения обязательств в соответствии с настоящей Лицензией в случае, если в результате решения суда или заявления о нарушении исключительных прав или в связи с наступлением иных обстоятельств, не связанных непосредственно с нарушением исключительных прав, на Лицензиата на основании решения суда, договора или ином основании возложены обязательства, которые противоречат условиям настоящей Лицензии. В этом случае Лицензиат не вправе распространять экземпляры Программы, если он не может одновременно исполнить условия настоящей Лицензии и возложенные на него указанным выше способом обязательства. Например, если по условиям лицензионного соглашения сублицензиатам не может быть предоставлено право бесплатного распространения экземпляров Программы, которые они приобрели напрямую или через третьих лиц у Лицензиата, то в этом случае Лицензиат обязан отказаться от распространения экземпляров Программы.
Если любое положение настоящего пункта при наступлении конкретных обстоятельств будет признано недействительным или неприменимым, настоящий пункт применяется за исключением такого положения. Настоящий пункт применяется в целом при прекращении вышеуказанных обстоятельств или их отсутствии.
Целью данного пункта не является принуждение Лицензиата к нарушению патента или заявления на иные права собственности или к оспариванию действительности такого заявления. Единственной целью данного пункта является защита неприкосновенности системы распространения свободного программного обеспечения, которая обеспечивается за счет общественного лицензирования. Многие люди внесли свой щедрый вклад в создание большого количества программного обеспечения, которое распространяется через данную систему в надежде на ее длительное и последовательное применение. Лицензиат не вправе вынуждать автора распространять программное обеспечение через данную систему. Право выбора системы распространения программного обеспечения принадлежит исключительно его автору.
Настоящий пункт 7 имеет целью четко определить те цели, которые преследуют все остальные положения настоящей Лицензии.
8. В том случае если распространение и/или использование Программы в отдельных государствах ограничено соглашениями в области патентных или авторских прав, первоначальный правообладатель, распространяющий Программу на условиях настоящей Лицензии, вправе ограничить территорию распространения Программы, указав только те государства, на территории которых допускается распространение Программы без ограничений, обусловленных такими соглашениями. В этом случае такое указание в отношении территорий определенных государств признается одним из условий настоящей Лицензии.
Как можно заметить, основным мотивом служит следующий принцип: программа не должна распространяться, если конечный пользователь не может в полной мере использовать свое право на модификацию и распространение под той же самой лицензией.
GNU Lesser GPL v2.1
Данная версия лицензии датируется 1999 годом и содержит одно огромное отличие от обычной лицензии GNU GPL: предназначенная для библиотек, лицензия позволяет использовать их в проприетарном программном обеспечении. Например, библиотеки GNU C распространяются под лицензией GNU Lesser GPL v2.1, для того, чтобы сторонние разработчики могли использовать их в своем ПО, свободном или коммерческом.GNU GPL v3.0
Последняя на сегодняшний день версия GPL, которая вышла в 2007 году. Изменения, внесенные в лицензию, были призваны оградить пользователей лицензии от судебных исков связанных с патентами, теперь создатели программы не могу подать в суд на пользователя. GPL 3.0 запрещает применять лицензию к программному обеспечению, которое запрещено «обходить» некоторыми законами и директивами (Digital Millennium Copyright Act и the European Union Copyright Directive). То есть, нельзя выпустить под лицензией любое ПО, попадающее под действие этих директив. Таким образом, GPL 3.0 заботится о том, чтобы любое ПО, выпущенное под ее лицензией, можно было свободно модифицировать, обходить или изменять.Кроме того, GPL 3.0 борется с таким явлением как «тивоизация», когда устройство, на котором установлено программное обеспечение под лицензией GPL, не позволяет вам в силу различных причин модифицировать его. GPL v3.0 запрещает тивоизацию для товаров народного потребления (оставляя возможность тивоизации для медицинских и других важных устройств).
Вместе с GPL 3.0 вышла так же обновленная версия GNU Lesser GPL 3.0, которая продолжает отличаться тем, что позволяет использовать свободные библиотеки в закрытом ПО.
Совместимость
Многие лицензии практически повторяют принципы, заложенные в GPL и отличаются, в принципе, только тем, что приняты коммерческими или другими организациями. Ниже я постараюсь свести такие лицензии под определенные версии GPL. Совместимость означает то, что отдельные части ПО с лицензией совместимого типа можно выпускать в комплексе с GPL-частями и под одной GPL лицензией.Совместимые только с GPL 3.0 лицензии
GNU Affero General Public License (AGPL) v3 - содержит пункт о том, что пользователи, которые взаимодействуют с программой по сети, так же должны иметь возможность получать исходные коды;Apache License, Version 2.0;
Educational Community License 2.0;
Freetype Project License;
Microsoft Public License (Ms-PL);
XFree86 1.1 License;
Совместимые с GNU GPL лицензии (как с v2 так и с v3 версией)
Artistic License 2.0;Berkeley Database License (aka the Sleepycat Software Product License);
Boost Software License;
Modified BSD license;
CeCILL version 2;
Cryptix General License;
Eiffel Forum License, version 2 - предыдущие версии не были совместимы;
Expat License;
FreeBSD license;
Лицензия the iMatix Standard Function Library;
Independent JPEG Group License;
Лицензия imlib2;
Intel Open Source License;
ISC License;
NCSA/University of Illinois Open Source License;
Лицензия Netscape Javascript;
OpenLDAP License, Version 2.7;
Лицензия Perl 5 и ниже;
Public Domain;
Лицензии Python 2.0.1, 2.1.1, и более новые версии;
Лицензия Ruby;
Standard ML of New Jersey Copyright License;
Unicode, Inc. License Agreement for Data Files and Software;
W3C Software Notice and License;
X11 License - иногда ошибочно называют MIT license.
Совместимые с Lesser GPL лицензии
eCos license version 2.0.Словарь
GNU - рекурсивный акроним GNU"s Not Unix;GNU GPL - открытое лицензионное соглашение GNU;
Проприетарное ПО - программное обеспечение, которое имеет ограничения в использовании и закрыто для модификации, другими словами «несвободное ПО»;
) was finally published on June 29, 2007. While there"s been a lot of discussion about the license since the first draft appeared, not many people have talked about the benefits that it provides developers. We"ve published this guide to fill that gap. We"ll start with a brief refresher on free software, copyleft, and the goals of the GPL. We"ll then review the major changes in the license to see how they advance those goals and benefit developers.
The Foundations of the GPL
Nobody should be restricted by the software they use. There are four freedoms that every user should have:
- the freedom to use the software for any purpose,
- the freedom to change the software to suit your needs,
- the freedom to share the software with your friends and neighbors, and
- the freedom to share the changes you make.
When a program offers users all of these freedoms, we call it free software .
Developers who write software can release it under the terms of the GNU GPL. When they do, it will be free software and stay free software, no matter who changes or distributes the program. We call this copyleft: the software is copyrighted, but instead of using those rights to restrict users like proprietary software does, we use them to ensure that every user has freedom.
We update the GPL to protect its copyleft from being undermined by legal or technological developments. The most recent version protects users from three recent threats:
Version 3 also has a number of improvements to make the license easier for everyone to use and understand. But even with all these changes, GPLv3 isn"t a radical new license; instead it"s an evolution of the previous version. Though a lot of text has changed, much of it simply clarifies what GPLv2 said. With that in mind, let"s review the major changes in GPLv3, and talk about how they improve the license for users and developers.
Neutralizing Laws That Prohibit Free Software — But Not Forbidding DRM
You"re probably familiar with the Digital Restrictions Management (DRM) on DVDs and other media. You"re probably also familiar with the laws that make it illegal to write your own tools to bypass those restrictions, like the Digital Millennium Copyright Act and the European Union Copyright Directive. Nobody should be able to stop you from writing any code that you want, and GPLv3 protects this right for you.
It"s always possible to use GPLed code to write software that implements DRM. However, if someone does that with code protected by GPLv3, section 3 says that the system will not count as an effective technological "protection" measure. This means that if you break the DRM, you"ll be free to distribute your own software that does that, and you won"t be threatened by the DMCA or similar laws.
As usual, the GNU GPL does not restrict what people do in software; it just stops them from restricting others.
Protecting Your Right to Tinker
Tivoization is a dangerous attempt to curtail users" freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.
This requirement is limited in scope. Distributors are still allowed to use cryptographic keys for any purpose, and they"ll only be required to disclose a key if you need it to modify GPLed software on the device they gave you. The GNU Project itself uses GnuPG to prove the integrity of all the software on its FTP site, and measures like that are beneficial to users. GPLv3 does not stop people from using cryptography; we wouldn"t want it to. It only stops people from taking away the rights that the license provides you—whether through patent law, technology, or any other means.
Stronger Protection Against Patent Threats
In the 17 years since GPLv2 was published, the software patent landscape has changed considerably, and free software licenses have developed new strategies to address them. GPLv3 reflects these changes too. Whenever someone conveys software covered by GPLv3 that they"ve written or modified, they must provide every recipient with any patent licenses necessary to exercise the rights that the GPL gives them. In addition to that, if any licensee tries to use a patent suit to stop another user from exercising those rights, their license will be terminated.
What this means for users and developers is that they"ll be able to work with GPLv3-covered software without worrying that a desperate contributor will try to sue them for patent infringement later. With these changes, GPLv3 affords its users more defenses against patent aggression than any other free software license.
Clarifying License Compatibility
If you found some code and wanted to incorporate it into a GPLed project, GPLv2 said that the license on the other code was not allowed to have any restrictions that were not already in GPLv2. As long as that was the case, we said the license was GPL-compatible.
However, some licenses had requirements that weren"t really restrictive, because they were so easy to comply with. For example, some licenses say that they don"t give you permission to use certain trademarks. That"s not really an additional restriction: if that clause wasn"t there, you still wouldn"t have permission to use the trademark. We always said those licenses were compatible with GPLv2, too.
Now, GPLv3 explicitly gives everyone permission to use code that has requirements like this. These new terms should help clear up misunderstandings about which licenses are GPL-compatible, why that is, and what you can do with GPL-compatible code.
New Compatible Licenses
In addition to clarifying the rules about licenses that are already GPL-compatible, GPLv3 is also newly compatible with a few other licenses. The Apache License 2.0 is a prime example. Lots of great free software is available under this license, with strong communities surrounding it. We hope that this change in GPLv3 will foster more cooperation and sharing within the free software community. The chart below helps illustrate some common compatibility relationships between different free software licenses:
Arrows pointing from one license to another indicate that the first license is compatible with the second. This is true even if you follow multiple arrows to get from one license to the other; so, for example, the ISC license is compatible with GPLv3. GPLv2 is compatible with GPLv3 if the program allows you to choose "any later version" of the GPL, which is the case for most software released under this license. This diagram is not comprehensive (see our licenses page for a more complete list of licenses compatible with GPLv2 and GPLv3), but plainly illustrates that GPLv3 is compatible with just about everything GPLv2 is, and then some.
The GNU Affero GPL version 3 has also been brought into the fold. The original Affero GPL was designed to ensure that all users of a web application would be able to receive its source. The GNU Affero GPL version 3 broadens this goal: it is applicable to all network-interactive software, so it will also work well for programs like game servers. The additional provision is also more flexible, so that if someone uses AGPLed source in an application without a network interface, they"ll only have to provide source in the same sort of way the GPL has always required. By making these two licenses compatible, developers of network-interactive software will be able to strengthen their copyleft while still building on top of the mature body of GPLed code available to them.
More Ways for Developers to Provide Source
One of the fundamental requirements of the GPL is that when you distribute object code to users, you must also provide them with a way to get the source. GPLv2 gave you a few ways to do this, and GPLv3 keeps those intact with some clarification. It also offers you new ways to provide source when you convey object code over a network. For instance, when you host object code on a web or FTP server, you can simply provide instructions that tell visitors how to get the source from a third-party server. Thanks to this new option, fulfilling this requirement should be easier for many small distributors who only make a few changes to large bodies of source.
The new license also makes it much easier to convey object code via BitTorrent. First, people who are merely downloading or seeding the torrent are exempt from the license"s requirements for conveying the software. Then, whoever starts the torrent can provide source by simply telling other torrent users where it is available on a public network server.
These new options help keep the GPL in line with community standards for offering source, without making it harder for users to get.
Less Source to Distribute: New System Libraries Exception
Both versions of the GPL require you to provide all the source necessary to build the software, including supporting libraries, compilation scripts, and so on. They also draw the line at System Libraries: you"re not required to provide the source for certain core components of the operating system, such as the C library.
GPLv3 has adjusted the definition of System Library to include software that may not come directly with the operating system, but that all users of the software can reasonably be expected to have. For example, it now also includes the standard libraries of common programming languages such as Python and Ruby.
The new definition also makes it clear that you can combine GPLed software with GPL-incompatible System Libraries, such as OpenSolaris" C library, and distribute them both together. These changes will make life easier for free software distributors who want to provide these combinations to their users.
A Global License
GPLv2 talks about "distribution" a lot—when you share the program with someone else, you"re distributing it. The license never says what distribution is, because the term was borrowed from United States copyright law. We expected that judges would look there for the definition. However, we later found out that copyright laws in other countries use the same word, but give it different meanings. Because of this, a judge in such a country might analyze GPLv2 differently than a judge in the United States.
GPLv3 uses a new term, "convey," and provides a definition for that term. "Convey" has the same meaning we intended for "distribute," but now that this is explained directly in the license, it should be easy for people everywhere to understand what we meant. There are other minor changes throughout the license that will also help ensure it is applied consistently worldwide.
When the Rules Are Broken: A Smooth Path to Compliance
Under GPLv2, if you violated the license in any way, your rights were automatically and permanently lost. The only way to get them back was to petition the copyright holder. While a strong defense against violations is valuable, this policy could cause a lot of headache when someone accidentally ran afoul of the rules. Asking all the copyright holders for a formal restoration of the license could be burdensome and costly: a typical GNU/Linux distribution draws upon the work of thousands.
GPLv3 offers a reprieve for good behavior: if you violate the license, you"ll get your rights back once you stop the violation, unless a copyright holder contacts you within 60 days. After you receive such a notice, you can have your rights fully restored if you"re a first-time violator and correct the violation within 30 days. Otherwise, you can work out the issue on a case-by-case basis with the copyright holders who contacted you, and your rights will be restored afterward.
Compliance with the GPL has always been the top priority of the FSF Compliance Lab and other groups enforcing the license worldwide. These changes ensure that compliance remains the top priority for enforcers, and gives violators incentive to comply.
The Latest and Greatest
Some of these changes probably seem less important to you than others. That"s okay. Every project is different, and needs different things from its license. But odds are that a number of these improvements will help you and your work.
And taken as a whole, all these upgrades represent something more: we made a better copyleft. It does more to protect users" freedom, but it also enables more cooperation in the free software community. But updating the license is only part of the job: in order for people to get the benefits it offers, developers need to use GPLv3 for their projects, too. By releasing your own software under the new license, everyone who deals with it—users, other developers, distributors, even lawyers—will benefit. We hope you"ll use GPLv3 for your next release.
If you"d like to learn more about upgrading your project to GPLv3, the FSF Compliance Lab would be happy to assist you. On our web site , you can find basic instructions for using the license , and an FAQ addressing common concerns that people have about it. If your situation is more complicated than that, please contact us and we"ll do what we can to help you with your transition. Together, we can help protect freedom for all users.
Несмотря на то, что GitHub - крупнейший в мире сервис для совместной работы над открытым кодом, значительная часть размещённых там проектов формально не имеют никакого отношения к Open Source. Причём вовсе не потому, что их авторы предпочитают проприетарные решения. На сервере опубликована масса ПО, не имеющего никакой лицензии.
По всей видимости, существует достаточно много разработчиков, считающих вопрос лицензирования если не совсем несущественным, то наверняка второстепенным. Например, в опубликованной на сайте Fossbytes.com статье, посвящённой этой проблеме, скрывающийся под псевдонимом gdad-s-river автор сообщает, что он выбирает лицензию случайным образом. Но вовсе не по причине правового нигилизма - он уверен, что его проект не особенно интересен другим людям и его код не будет использован для создания других инструментов.
Но его пример не может быть показательным. Если разработчик планирует создать продукт, который в перспективе может быть использован другими для построения собственных оригинальных версий, вопрос выбора лицензии для него чрезвычайно важен. Вариантов тут может быть много:
- Apache License 2.0;
- BSD 3 (New BSD);
- BSD 2 (FreeBSD);
- GNU General Public License (GPL) v3.0;
- GNU Lesser General Public License (LGPL);
- MIT License;
- Mozilla Public License 2.0;
- Common Development and Distribution License;
- Eclipse Public License;
- Creative Commons License.
Наверняка профессиональному юристу такой список покажется небольшим, и он без труда разберётся в особенностях той или иной лицензии. Однако техническому специалисту непросто понять смысл, скрывающийся за явно перегруженными с его точки зрения формулировками. Более того, даже не все разработчики понимают, зачем нужно лицензирование, и искренне считают, что свободное ПО предполагает отсутствие каких бы то ни было ограничений.
В действительности, у всех открытых лицензий есть только одна прагматичная цель. В них сформулированы правила, которыми должны руководствоваться другие разработчики, если они заходят как-то использовать чужой код. Это может быть как создание производного продукта, так и вклад в развитие оригинального.
Открытые лицензии можно разделить на несколько больших категорий. У каждой их них есть свои особенности с точки зрения практического применения. Вероятнее всего, начинающим свои проекты разработчикам целесообразней ориентироваться именно на типы лицензий, выбирая наиболее подходящий для себя.
GNU General Public License
Этот тип лицензий позволяет копировать исходный код без каких-либо ограничений. Копии можно размещать на рабочих станциях и серверах, причём делать это неограниченное число раз.
Также GNU GPL не накладывает никаких ограничений на распространение программ ни по количеству, но по форме. Код можно переносить на специальных накопителях, можно дать ссылку для загрузки, можно даже распечатать его на бумаге и раздавать всем желающим.
Этот тип лицензий позволяет любому физическому или юридическому лицу брать деньги за услугу по распространению ПО. Правда, потенциальный покупатель должен быть предупреждён, что продавец не имеет каких-либо эксклюзивных прав, поэтому то же самое решение можно получить совершенно бесплатно. Это качество также даёт возможность объяснить, за что именно берётся плата.
Наконец, GNU GPL позволяет вносить в код любые изменения, удалять или добавлять любые функции. Правда только при условии, что полученный таким образом продукт также должен распространятся на условиях той же лицензии.
Разработчикам следует знать, что использование GNU GPL предполагает соответствие неким стандартам оформления кода. Внутри него в комментариях должны быть изложены лицензионные требования.
GNU Lesser General Public License
Ранее название этого типа лицензий - GNU Library General Public License. LGPL чаще всего применяется для библиотек ПО, поскольку позволяет использовать их не только в свободных, но и проприетарных приложениях.
В проприетарном ПО распространяемый на условиях LGPL код применяется в форме разделяемой библиотеки. Эта мера обеспечивает разграничение между закрытыми и открытыми компонентами в программе, сама же лицензия не требует открытия кода всего решения.
LGPL, в отличие от GPL, носит компромиссный характер. Она не гарантирует пользователю полную свободу всех производных продуктов, но позволяет использовать открытый код в проприетарных решениях, причём открытые модули должны оставаться открытыми.
BSD License
Некоторые программисты считают BSD истинно свободной лицензией, и в некотором смысле они правы. Действительно, BSD накладывает очень мало ограничений на использование кода по сравнению с другими лицензиями.
Выбирающий BSD разработчик по сути разрешает использование своего кода как в открытых, так и в проприетарных приложениях. Это свойство широко применяется на практике, в том числе в больших проектах. В частности, некоторые компоненты FreeBSD вошли в состав операционной системы Mac OS X.
Основная особенность BSD 3, которая часто называется BSD New, в том, что она ограничивает использование имён разработчиков в производных продуктах. На практике означает, что она по умолчанию запрещает применять имя автора для продвижения других программ - для этого требуется его специальное разрешение.
MIT License
Это самая короткая лицензия. Возможно, именно по этой причине она становится всё более популярной. По сути она разрешает всё.
В соответствии с лицензией MIT копию ПО и всю сопутствующую документацию можно изменять, улучшать, дополнять, применять в других проектах, продавать и распространять бесплатно при соблюдении всего одного условия - текст лицензии должен быть включён во все копии. Требование, очевидно, совершенно необременительное и выполнить его не составляет никакого труда.
Creative Commons
Эта группа лицензий предназначена не для ПО, а для «сопутствующих продуктов»: фотографий, рисунков, текстов, дизайнерских проектов и т. д. Прежде всего потому, что Creative Commons не требует включения в произведение текста лицензии, достаточно только указать соответствующее буквенное обозначение.
Для лицензий группы Creative Commons нет каких-то строгих обязательных для всех правил. Некоторые из них вообще могут взаимно исключать друг друга, и в этом нет ничего страшного, если принять во внимание область их применения.
В частности, Creative Commons может разрешать неограниченное копирование и распространение, но запрещать при этом любые изменения. Программистам это может показаться странным, а вот художник вероятнее всего сочтёт такое условие вполне разумным.
Apache License
У Apache License есть одна интересная для многих разработчиков особенность - она не ставит обязательным условием неизменность лицензии. Таким образом, правила распространения модифицированной версии какой-либо программы могут отличаться от исходных.
Разумеется, право на изменение лицензии не означает возможности её отзыва. Никто не имеет права менять условия, которые уже были однажды определены.
