Закрытая лицензия gpl

Почему вам не следует использовать GNU GPL для лицензирования своих программ?

Почему вам не следует использовать GNU GPL для лицензирования своих программ?

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

Прежде чем приступить к критическому анализу, давайте еще раз озвучим те причины, что сподвигли Ричарда Столмена создать GNU. Это засилие закрытого программного обеспечения (ЗПО). Что означает закрытость? Закрытость в данном случае означает, (а) что вы, как пользователь, купивший программу, не имеете права делиться ею с кем бы то ни было, (б) изучать, как устроена эта программа, (в) изменять ее для своих нужд. Каким образам это достигается? Во-первых, это лицензионное соглашение, во-вторых, отсутствие исходного кода программы.

На заре компьютерной эры все программы были открытыми, хакеры (тогда пользователями были только хакеры) свободно делились друг с другом программами и их исходниками. И был рай на земле :). Но вот, у компьютеров появились пользователи! Компьютеры, а значит, и программы, стало выгодно продавать. Естественно, компании стали закрывать свои программы, и рай закончился. Проект GNU — есть ни что иное, как попытка вновь обрести его. 🙂

Чем опасно закрывание программ? Лучше всего, на этот вопрос отвечает сам Столмен, например здесь . Я приведу лишь несколько примеров. Запрет делиться с кем-либо своей копией программы создает нездоровую обстановку в обществе. Столмен приводит такой пример: один хакер приходит к другому и говорит,
— Слышь, друг, у меня тут ваш драйвер для принтера глючит, дай мне его сырцы, я себе подправлю.
А тот ему и отвечает,
— Извини, друг, не могу, меня за это уволят.
Другими словами, этот запрет подрывает основы сотрудничества. Последние два запрета, на изучение и изменение программ приводят к снижению образовательного уровня программистов. Каждый раз, когда они пытаются разобраться в новой технологии, их «бьют по рукам» лицензионным соглашением.

Кто-то может сказать, что, мол, лицензия нам не указ, куда надо залезем, и что надо изучим. Да, так сейчас и происходит, но давайте вдумаемся, какое правовое сознание культивируется при этом в обществе? Правильно, ни какого, и это еще одна причина, побудившая Столмена создать GNU.

Каким образом можно решить эти проблемы? Программы должны быть свободными! Что это означает? Для ответа на этот вопрос давайте заглянем в GNU GPL (это лицензия, под которой выпускается свободное ПО). Если коротко и очень упрощенно, то GPL — это лицензия на программное обеспечение (ПО), которая предоставляет вам пять основных прав:

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

GPL ЛИШАЕТ вас права лишать кого бы то ни было перечисленных выше прав. Забавный каламбур, не правда ли? Означает это буквально следующее: при передаче кому-либо копии программы, Вы обязаны передать ему все те права и обязанности, которые накладывает на вас эта лицензия. Другими словами, вы не можете перелицензировать программу. Это необходимо для того, чтобы защитить программу, и, соответственно, сообщество свободного программного обеспечения от недобросовестных предпринимателей, которые в противном случае могли бы использовать код программы в своем закрытом продукте. Этот пункт вынуждает их либо не использовать программу вовсе, либо выпустить свой продукт под GPL, обогатив, тем самым, сообщество. Подробнее об этом механизме можно почитать здесь .

Теперь давайте перечислим основные недостатки GNU GPL, и, соответственно, порождаемого ею рынка свободного ПО. В самом деле, любая лицензия порождает рынок.

• Отсутствие четкой схемы финансирования со стороны пользователя, что приводит к отсутствию, либо плохому качеству программ, необходимых пользователям.
• «Закрытость» программ с открытым кодом. Забавно звучит, не правда ли?

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

А вот как вам утверждение, что открытые программы на самом деле являются закрытыми? Что имеется в виду? Когда создавалась GNU GPL, не было еще так называемой «проблемы больших проектов». Заключается она в том, что для очень большого и сложного проекта гораздо более ценной оказывается информация о концепциях, идеях, заложенных в его основу, чем исходный код. Фактически, в большем преимуществе оказывается та группа программистов, что владеет идеями, а не исходным кодом. Более подробно об этом можно почитать в статье одного нашего бывшего соотечественника.

Другими словами, информация о ключевых концепциях проекта становится тем капиталом, который позволяет удержать власть над проектом, даже при условии распространения вместе с исходниками. Подрывается сам принцип GNU — свободные программы. Здесь это следует читать как свободные идеи, в самом деле, ведь изначальная суть в этом. Идеи должны быть свободными!

В упомянутой выше статье подчеркивается, что этот способ «закрывания» программ сейчас широко используется в мире «свободного» ПО, в том числе и в таких ключевых проектах, как разработка ядра Linux.

Отчего же так происходит? Может, злые враги проникли в наш стан? Нет, это делают люди, самоотверженно работающие на благо сообщества свободного ПО (СПО). Но почему? Чтобы ответить на этот вопрос, нам придется сделать небольшой экскурс в психологию личности.

В общем смысле, вслед за Фромом, можно выделить два основных архетипа человека: творец и потребитель. Творцу просто в радость создать что-то и отдать это людям — пусть пользуются. Такие люди создали GNU. Потребитель испытывает постоянную потребность поглощать; деньги, славу, власть и т.д. Желающих узнать, почему так происходит, и как эти архетипы формируются в конкретных людях отсылаю к Фрейду и все тому-же Фрому. Реально, в каждом человеке реализованы оба этих архетипа, но в разной степени. Кто-то больше творец, кто-то потребитель. Но даже в самом чистом творце есть маленькая жилка потребителя.

Давайте теперь посмотрим через эту призму на людей, возглавляющих ключевые проекты ядра Linux. Безусловно, они творцы, на них стоит равняться, но что же происходит с той маленькой «жилкой» потребителя, собственника? Она реализует себя в _обладании_ ключевыми идеями проекта, а значит, и обладании проектом. В самом деле, если эти идеи открыть, то каждый достаточно талантливый программист сможет встать на его место. Именно эта «жилка» заставляет «творца» удерживать ключевые идеи проекта.

Как же с этим боротся? Во-первых, нужно внести изменение в лицензию, обязывающие распространять не только исходный код, но и документацию ключевых идей и концепций, на которых основан проект. Во-вторых, чтобы удовлетворить все-таки, потребительскую «жилку», а от нее нам ни куда не деться, это наша природа, необходимо обеспечить механизм достойного вознаграждения труда программистов, создающих открытое ПО. В самом деле, деньги — хороший эквивалент славе и власти.

Ага, опять прозвучало слово «деньги»! Если помните, первый из обсуждаемых нами недостатков GNU GPL заключается в отсутствии четкой схемы финансирования со стороны потребителя, мы вновь на него вышли.

Можно ли решить эти проблемы, оставаясь в рамках Свободного ПО? Да, можно, и, более того, нужно! Проблема давно назрела, ее НАДО решать. Решение, которое я предлагаю, называется Copymiddle, в отличие от Copyright и Copyleft. Автором такого названия является Антон Первенцев , за что ему отдельное спасибо.

Остановимся здесь, и вновь посмотрим на GPL. Кто этот загадочный «Вы», которого наделяет правами и обязанностями GPL? Методом «пристального вглядывания» приходим к выводу, что это, на самом деле, три различных сущности: ПРОГРАММИСТ, ПРЕДПРИНИМАТЕЛЬ, ПОЛЬЗОВАТЕЛЬ. ППП, прямо святая троица получается. 🙂

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

1. ПРОГРАММИСТ, как автор программы, оставляет за собой право авторства программой
2. ПОЛЬЗОВАТЕЛЬ может использовать программу
3. ПРОГРАММИСТ может модифицировать программу
4. ПРОГРАММИСТ ПОЛЬЗОВАТЕЛЬ и ПРЕДПРИНИМАТЕЛЬ могут свободно распространять программу
5. ПРЕДПРИНИМАТЕЛЬ может получать прибыль продавая программу, или осуществляя любую другую коммерческую деятельность, связанную с программой, но не подпадающую под пункт об использовании. При этом Он обязан распространять ее вместе с исходниками

Другими словами, ПРОГРАММИСТ имеет право программировать, ПОЛЬЗОВАТЕЛЬ имеет право пользоваться, ПРЕДПРИНИМАТЕЛЬ имеет право зарабатывать деньги. Заводы рабочим, землю крестьянам! Социализм в чистом виде. В нашей стране идеи социализма, на сегодняшний день, сильно дискредитированы, однако социализм — это то, к чему человечество рано или поздно придет, конечно, если по пути ножки не поломает :). Попробуем теперь понять, как изменить GPL так, чтобы сохранив СВОБОДУ, которую она нам дает, внести в нее фактор экономического развития.

Решение напрашивается само собой. Оставим ПОЛЬЗОВАТЕЛЯ в покое, возьмем немножко прав у ПРЕДПРИНИМАТЕЛЯ и отдадим их ПРОГРАММИСТУ. Например, обяжем ПРЕДПРИНИМАТЕЛЯ отчислять 10% от своей прибыли, полученной от коммерческой деятельности, связанной с распространением, сопровождением и т.д. программисту.

Добавим сюда обязанность распространять вместе с программой и ее кодом еще и идеи, заложенные в ее основу, и получим новый тип лицензии на «Свободное ПО». Я бы назвал ее GPL+- :). Плюс — соответствует экономическому фактору развития, который эта лицензия привносит в GPL и истинной свободой идей. Минус — это та цена, которую мы за это платим, — взаимное правовое неравенство игроков в новом правовом мире, порожденном лицензией GPL+-. Однако очевидно, что это минимальная цена, которую мы можем заплатить.

Вот что у нас получилось в итоге. Это вольное изложение GPL+-, или Copymiddle.

1. ПРОГРАММИСТ, как автор программы, оставляет за собой право авторства программой
2. ПОЛЬЗОВАТЕЛЬ может использовать программу
3. ПРОГРАММИСТ может модифицировать программу и получать свой авторский гонорар за коммерческое использование программы
4. ПРОГРАММИСТ ПОЛЬЗОВАТЕЛЬ и ПРЕДПРИНИМАТЕЛЬ могут свободно распространять программу
5. ПРЕДПРИНИМАТЕЛЬ может получать прибыль продавая программу, или осуществляя любую другую коммерческую деятельность, связанную с программой, но не подпадающую под пункт об использовании. При этом Он обязан распространять ее вместе с исходниками и идеями, существенно необходимыми для понимания внутренней структуры программы. Также, ПРЕДПРИНИМАТЕЛЬ обязан отчислять 10% (для определенности) от своих доходов, полученных от коммерческого использования программмы ее автору.

На самом деле, думаю, нам нужно несколько GPL+- подобных лицензий. Собственно, GPL+-, для лицензирования свободного ПО. GPDL+- то же самое, но для документации и художественных текстов, ее отличие в том, что вы не можете вносить изменения без разрешения автора (это к примеру, здесь возможны варианты). И последнее, нужна еще более прокомерческая лицензия GPCL+- (GP Commerce L+-) для лицензирования таких программ, как, например, компьютерные игры. Ее отличие от GPL+- в том, что под коммерческую деятельность ПРЕДПРИНИМАТЕЛЯ будет подпадать и использование программы, конечно, если при этом извлекается прибыль. Речь идет об использовании игр в компьютерных клубах, там на этом зарабатывают деньги, так пусть и отчисляют автору его процент. 🙂 Естественно, компьютерные игры — не единственное поле применения такой лицензии.

В заключение отмечу, что не выясненными остались многие вопросы, касающиеся реализации нового типа лицензирования свободного ПО. Эти вопросы будут подробно обсуждаться в статье «Что такое GPL+-?» следите за рекламой 🙂

Владимир И. Торшин — Почему вам не следует использовать GNU GPL для лицензирования своих программ?

Использование библиотек с GPL лицензией в коммерческих продуктах

Госспода, возник вопрос.Я пишу софтину для использования на нашем же веб сервере.

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

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

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

Может ли GPL-приложение линковаться с закрытой библиотекой?

Есть программа под GPL. Можно ли в ней использовать закрытую бинарную библиотеку (dll/so)? Функционала нужно немного, но без нее программа работать не сможет. Знатоки подскажите пожалуйста. В гугле что-то зарылся.

v2 — yes
v3 — no
BSD — pohuy

А программа вся твоя или чужой код там?

врешь и не краснеешь

Если линковка динамическая ,то мне кажется, что можно, не?

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

с LGPL — да, динамическая линковка отметает многие разночтения

Тогда следующий вопрос к знатокам GPL — можно ли расспространять заранее нерабочий код под GPL? К примеру закоммитил ты себе на публичный сервер полурабочий (или недоделаный) проект, использующий библиотеку под GPL. Могут на тебя из-за этого подать в суд?

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

То-есть я могу написать вот такой код:

При этом в описании программы будет сказано, что она просто загружает произвольную библиотеку по выбору. Такой код не нарушает GPL?

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

Да, завтыкал. то ЛГПЛ мона 🙂

только маленькое «но»: ты не можешь распространять такую программу (бмнарь) под GPL, но ни кто не мешает тебе _любой_ _свой_ код (даже вышепреведенный) залицензировать под GPL, а уж кто и как будет делать из него «бинарь» — не твоё дело.

>ты не можешь распространять такую программу (бмнарь) под GPL

То-есть вот этот написаный мною код уже нарушает GPL? Если да, то получается любой код с использованием dlopen()/dlsym() нарушает GPL.

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

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

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

в этом случае лицензию нарушит тот, кто запустит

я имел в виду «нет, не нарушает»

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

> в этом случае лицензию нарушит тот, кто запустит

Вот вам расширенный пример. Программа сканирует директорию и находит в ней 10 динамических библиотек. Она их последовательно открывает и вызывает оттуда одну функцию. У тут оказывается, что одна из тех 10 библиотек расспространялась под лицензией, несовместимой с GPL. Кого вести под суд, разработчика, который написал этот цикл, или же пользователя, который (самым преступным образом!) положил разные библиотеки в одну директорию?

>в этом случае лицензию нарушит тот, кто запустит

ненене, GPL ограничивает только распространение, а не использование.

1. Подать в суд на разработчика в любом случае никто не в праве (хотя такая программа вполне может быть вредоносной — это уже другая статья)

2. Если разработчик тролль, он может попробовать преследовать пользователя, но доказать что-либо вряд ли удастся

Итак мы выяснили:
a) Разработчик программы может полностью оформить работу со сторонней библиотекой только с помощью dlopen()/dlsym() оставаясь в рамках лицензии GPL.
б) Если вы скачали такую программу под GPL и просто её запустили — на вас могут подать иск в суд за нарушение лицензии GPL.

Интересный ход мыслей. Есть ещё мнения по этому поводу?

>Разработчик программы может полностью оформить работу со сторонней библиотекой только с помощью dlopen()/dlsym() оставаясь в рамках лицензии GPL.

этого не утверждалось. Если разработчик намеревается таким образом работать с какой-либо конкретной несвободной бибилотекой (а не просто брутфорсить все подряд), тогда он 100% нарушает свою лицензию (естественно, никто не может наказть его за это, разве что авторы GPL-кода, который он позаимствовал). В чем разница — в этом случае разработчик сознательно распространяет несвободную либу вместе с продуктом или требует ее наличия для работы программы

По-моему, вы все всё путаете.

В GPL шла речь о derivative work (далее DW). То есть, если ваш код есть DW от какого-то другого кода, лицензированного под GPL, то и ваш код обязан быть под GPL. LGPL делает исключение для случая, когда DW — программа, использующая динамическую библиотеку.

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

А ещё прошу вышеотписавшихся объяснить физический смысл выражения «разработчик нарушил свою лицензию». Это типа «обокрал/обманул сам себя»?

> разработчик сознательно распространяет

Не расспространяет и не требует. Как уже было сказано выше — просто выложил код на публичный сервер. И да — код под GPL, никоим образом его не нарушая.

>В вашем же случае, библиотека не является DW от вашего кода, строго наоборот.

именно так, но GPL-код не может быть DW от проприетарной бибилотеки, это нарушение

Это типа «обокрал/обманул сам себя»?

аналогично, GPLv2-код нельзя линковать с библиотекой под LGPL3 — это не нарушит LGPL3, но нарушит GPL2

именно так, но GPL-код не может быть DW от проприетарной бибилотеки, это нарушение

Где это сказано? Пожалуйста, точную цитату, я там такого не находил.

you should affix an explicit notice giving permission to link your program with them

Короче, надо себе это разрешить.

И да, этот faq не очень-то выдержан в букве GPL (хотя и соответствует духу).

>Короче, надо себе это разрешить.

не надо ерничать. Лицензия GPL в исходном виде здесь неприменима, если ты ее применяешь — ССЗБ

>Лицензия GPL в исходном виде здесь неприменима, если ты ее применяешь — ССЗБ

ещё раз — неприменима при распространении программы в бинарном виде (в комплекте с самой библиотекой?). Выложить для публичного доступа исходник — никаких проблем.

распространение этой библиотеки никоим боком не связано с проблемой

>распространение этой библиотеки никоим боком не связано с проблемой

Образование | Лицензии открытого кода: краткое руководство

Подпишись
на рассылку

Лучшие публикации Теплицы, доставленные на твой email

Подпишись
на Теплицу(Pro)

Не пропусти лучшие новости для экспертов в области IT, активистов, дизайнеров

Подпишись
в Фейсбуке

Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий

Подпишись
ВКонтакте

Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий

Подпишись
в Телеграм

Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий

Подпишись
на YouTube

Не пропусти видео-уроки, скринкасты, записи вебинаров и мероприятий

Наталья Баранова

Всего материалов: 527

Лицензии открытого кода: краткое руководство

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

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

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

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

На схеме показана детализация категорий программ. Изображение с сайта www.gnu.org

Список одобренных лицензий для открытого ПО

Такой список составила организация по продвижению открытого ПО Open Source Initiative. В него вошли несколько популярных подтвержденных лицензий.

1. GNU, General Public License (GPL). В сообществе программистов это одна из ключевых лицензий, которая используется при написании открытого ПО. Ее создал программист, основатель движения открытого ПО и проекта по разработке свободного ПО GNU ( The GNU Project ) Ричард Столлман.

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

Например, под этой лицензией распространяется ядро Linux, MySQL, Asterisk и многие CMS-системы (системы управления содержимым): MovableType, MODx, WordPress, Joomla, Drupal, osCommerce.

2. Apache License 2.0. Гибкая лицензия, которая имеет четкие права. Плюс в том, что они могут применяться к копирайтам и патентам. Некоторые из доступных прав: права безвозмездны, вечны, не эксклюзивны и глобальны. Если вы распространяете код, вы должны указать имя разработчика.

3. BSD (Berkeley Software Distribution). В этой лицензии не такие строгие правила, как в GPL. Разработчики должны выполнить несложные условия: указывать в документации, что в продукте используются разработки создателей оригинального программного обеспечения и не использовать имена (или названия) создателей этого ПО в рекламных целях без письменного согласия.

BSD-лицензий существует несколько видов. Наиболее используемые New BSD/Modified BSD и Simplified BSD/FreeBSD. Лицензия New BSD разрешает распространять ПО с любой целью, не дает гарантий и не несет ответственности за последствия использования. Есть пункт в виде специального разрешения: нельзя использовать имена участников вашего проекта. Между этими лицензиями единственное отличие: в Simplified BSD не ограничено использование имен.

Например, компания Apple использует преимущественно лицензии BSD.

4. GNU Lesser General Public License (LGPL). Появилась в рамках проекта GNU. Дает больше прав, чем GPL. Главное отличие в том, что она позволяет использовать продукты LGPL в проектах, которые распространяются под другими лицензиями.

Один из известных продуктов, выпускаемый под этой лицензией, – офисный пакет OpenOffice.org.

5. MIT license (Massachusetts Institute of Technology). Очень короткая и достаточно свободная лицензия. Она разрешает использовать, копировать и модифицировать программное обеспечение на ваше усмотрение. ПО можно предоставлять бесплатно или даже продавать. Ограничений нет. Но есть ограничение в том, что ваше ПО должно сопровождаться лицензионным соглашением.

Программное обеспечение, которое лицензировано MIT, можно использовать в закрытых продуктах. Лицензия схожа с BSD. Но в MIT можно использовать название продукта и имена создателей в рекламных целях. Под MIT распространяются X Window System (X11) и Ruby on Rails.

6. Mozilla Public License 2.0. Содержит в себе черты BSD и GPL. Исходный код, скопированный или измененный под лицензией MPL, должен быть лицензирован по правилам MPL. Лицензия позволяет объединить его в одной программе с проприетарными (несвободными) файлами.

7. Common Development and Distribution License. Эта лицензия позволяет совмещать открытый и закрытый код, защищенный авторскими правами. Файлы можно совмещать с файлами, которые находятся под другими открытыми или проприетарными (несвободными) лицензиями.

8. Eclipse Public License. Лицензия наиболее подходит для бизнес-ориентированного свободного ПО и базируется на лицензии CPL. У нее более гибкие правила отказа на авторские права.

По мнению разработчика свободного программного обеспечения Сергея Матвеева стоит использовать лицензии семейства GNU GPL. «Мне важно, чтобы мой труд был свободным ПО, чтобы он принес пользу обществу, чтобы никто не смог сделать мое ПО не свободным или использовать его в помощь несвободному, так как это обесценило мой вклад, – объясняет эксперт. – Многие говорят, что не хотят использовать GPL, потому-что хотят свободны, абсолютного отсутствия ограничений. В таком случае подходит только public domain: общественное достояние, где ПО действительно перестает что-то требовать или ограничивать».

С полным списком одобренных лицензий можно ознакомиться на сайте Open Source Initiative.

В чём разница между популярными Open Source лицензиями? Объясняет Github

В сентябре Github добавила на страницы проектов, которые используют стандартные Open Source лицензии, секцию, в которой эта лицензия указывается:

После переработки условий использования сервиса, которые прояснили (наконец-то) правовой статус GitHub относительно проектов, которые он хранит, компания решила пойти дальше в том, чтобы помочь пользователям разобраться, на что они имеют право, а на что — нет. С этой целью на страницу просмотра файла LICENSE из корневой директории проекта были добавлены краткие сведения о лицензии с сайта Choose A License:

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

1. Первая содержит информацию о том, что лицензия вам разрешает делать с проектом (авторское право или закрытые лицензии обычно, напротив, запрещают делать это);
2. Вторая — о том, какие ограничения лицензия накладывает на тех, кто модифицирует или распространяет работу;
3. Последняя – о том, чего лицензия не гарантирует и чего не разрешает.

Пояснения некоторых значений таблиц

Разрешения * распространять, * использовать в коммерческих целях или * изменять работу значат ровно то, что написано — вы можете пользоваться этими правами, но лишь до тех пор, пока соблюдаете условия, указанные в секциях * «Требует» и * «Запрещает».

Пункт * «Разрешает личное использование» (англ. private use) означает, что если вы изменяете работу, вы не обязаны её распространять — на своей машине вы можете делать с кодом всё, что захотите.

Пункт * «Предоставление патентных прав» означает что соавторы работы (контрибьюторы) отказываются от патентных прав (если они есть) на те части кода, которые они добавили; это гарантирует безопасность при использовании работы — иск на вас точно не подадут.

Пункты * «Отказ от ответственности» и * «Никакой гарантии» означают, что ни при каких условиях авторы произведения не могут быть ответственны за последствия его использования, продажи и вообще чего угодно.

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

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

Это самая популярная копилефтная лицензия. От предыдущей она отличается только тем, что не приравнивает использование программы по сети к её распространению.

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

Mozilla Public License 2.0

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

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

The MIT License

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

Apache License 2.0

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

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

А как же остальные лицензии? Как же BSD?

Этого набора более чем достаточно, если вы хотите выбрать лицензию для своего Open Source проекта — не надо писать свою лицензию или использовать что-то более специфическое. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом — актуальная проблема Open Source. Лицензия BSD достаточно популярна, но её сокращённый вариант полностью совпадает по смыслу с лицензией MIT, и GNU советуют использовать именно последнюю. Если же вы столкнулись с проектом, который использует какую-то нестандартную лицензию, и хотите узнать, что она вам разрешает, вы можете подсмотреть в шпаргалке на сайте Choose A License.

Пётр Соковых, транслятор двоичного кода в русский язык

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

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

Вторая версия лицензии датируется 1991 годом и основным мотивом провозглашает (согласно wiki) принцип «Liberty or Death» (Свобода или Смерть). Этот принцип заключен в седьмом и восьмом пункте соглашения:

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

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

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

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

8. В том случае если распространение и/или использование Программы в отдельных государствах ограничено соглашениями в области патентных или авторских прав, первоначальный правообладатель, распространяющий Программу на условиях настоящей Лицензии, вправе ограничить территорию распространения Программы, указав только те государства, на территории которых допускается распространение Программы без ограничений, обусловленных такими соглашениями. В этом случае такое указание в отношении территорий определенных государств признается одним из условий настоящей Лицензии.[1]

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

GNU Lesser GPL v2.1

Данная версия лицензии датируется 1999 годом и содержит одно огромное отличие от обычной лицензии GNU GPL: предназначенная для библиотек, лицензия позволяет использовать их в проприетарном программном обеспечении. Например, библиотеки GNU C распространяются под лицензией GNU Lesser GPL v2.1, для того, чтобы сторонние разработчики могли использовать их в своем ПО, свободном или коммерческом.

Последняя на сегодняшний день версия 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;
Проприетарное ПО — программное обеспечение, которое имеет ограничения в использовании и закрыто для модификации, другими словами «несвободное ПО»;
Тивоизация — термин который введен по названию прибора TiVo, на котором стоял Linux под GPL 2.0, который не было возможности модифицировать.
Copyleft — термин который противопоставляют «copyright», предполагает права на полный доступ к исходным кодам программного обеспечения, которые могут использоваться только для создания настолько же свободного ПО.

Используемые источники

В следующей статье, я постараюсь рассмотреть философию BSD-лицензий, чем отличаются BSD-лицензии от GPL и какие лицензии несовместимы с GPL (которые, следовательно, можно считать не полностью открытыми и свободными). Кроме того, я коснусь лицензий которые описывают документацию и отличные от программного обеспечения вещи.