GPLv3 регулирует не только программное обеспечение


Оглавление (нажмите, чтобы открыть):

Могу ли я использовать программу GNU GPLv3 для коммерческих целей?

Можно ли использовать wkhtmltopdf (лицензию под GNU GPL v3 ) в качестве части моего коммерческого приложения?

Если я использую часть программного обеспечения, полученную под GNU GPL, могу ли я изменить исходный код в новую программу, а затем распространять и продавать эту новую коммерческую программу?

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

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

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

Из комментариев становится ясно, что вы намерены запускать программное обеспечение на сервере и продавать его.

Это не распространяется ( «передача» ) в терминах лицензии GPLv3.

Если, с другой стороны, если wkhtmltopdf был покрыт под GNU Affero Public License, вам пришлось бы сделать исходный код, включая любые сделанные вами изменения.

У меня есть хорошие новости для всех

В официальном FAQ GPL говорится:

Если программа, выпущенная под GPL использует плагины, каковы требования к лицензиям плагин?

Если программа использует fork и exec для вызывать плагины, тогда плагины отдельные программы, поэтому лицензия на основная программа не требует никаких требований для них.

Почему вам не следует использовать 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 для лицензирования своих программ?

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

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

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

Антон Каменский
юрист компании ООО «ИнфоТехноПроект»

Распространение свободного программного обеспечения (СПО) на мировом рынке вызывает необходимость в оценке соответствия лицензионных условий использования подобных программных продуктов действующему российскому законодательству.

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

Распространение СПО осуществляется на основании свободных лицензий. На сегодняшний день существует множество подобных лицензий, характеризующихся предоставляющимся пользователю набором прав и порядком осуществления таких прав. Вместе с тем представляется целесообразным проведение условной классификации свободных лицензий на два типа, отличающихся между собой возможностью придания в дальнейшем продукту закрытого статуса (например, BSD) либо невозможностью осуществления подобных действий (GNU GPL). В настоящей статье проводится анализ соответствия действующему законодательству условий свободной лицензии GNU GPL v3.

Проблемы в передаче прав на условиях GNUGPLv3

Передача прав на использование программного продукта на условиях свободной лицензии GNU GPL v3 характеризуется как общими проблемами договорного и авторского права, так и проблемами специфического характера.

В соответствии с положениями российского законодательства (Гражданский кодекс Российской Федерации, IV часть) передача прав на использование СПО на условиях свободной лицензии GNU GPL v3 должна осуществляться на основании лицензионного договора, согласно которому одна сторона — обладатель исключительного права на результат интеллектуальной деятельности (лицензиар) — предоставляет или обязуется предоставить другой стороне (лицензиату) право использования такого результата в предусмотренных договором пределах с сохранением за лицензиаром права выдачи лицензий другим лицам (простая, неисключительная, лицензия) либо без такового (исключительная лицензия).


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

Принятие условий свободной лицензии

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

Мастер Йода рекомендует:  PHP в HTML

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

Авторское право

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

В свободной лицензии GNU GPL v3 содержится условие об исключении ответственности обладателей авторских прав и иных лиц, распространявших либо модифицировавших СПО в разрешенных пределах, за причиненные убытки, проистекающие из-за использования или невозможности использования программы. Однако в данном случае действие вышеуказанной лицензии будет ограничиваться императивными нормами гражданского законодательства об обязательствах вследствие причинения вреда.

Проблемы в сфере налогообложения при использовании СПО

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

Таким образом, система закрепленных в гражданском законодательстве положений в целом отвечает сложившимся в мировой практике правилам оборота СПО на условиях свободной лицензии GNU GPL v3, однако следует отметить существование концептуальных противоречий, преодоление которых, по мнению автора, должно стать совместной задачей разработчиков вышеуказанной лицензии и представителей IT-сообщества Российской Федерации. В противном случае сохранение существующих коллизий повлечет за собой практические трудности в применении СПО юридическими лицами и гражданами, связанные, главным образом, с возможностью признания недействительности лицензионного договора.

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

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

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

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

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

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

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

GPLv3 (GNU General Public License Version 3)

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

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

GPLv2 (GNU General Public License Version 2)

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

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

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

LGPLv3 (GNU Lesser General Public License Version 3)

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

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

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

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


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

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

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

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 http://mozilla.org/MPL/2.0/.

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

EPL-1.0 (Eclipse Public License Version 1.0)

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

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

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

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

Ms-PL (Microsoft Public License)

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

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

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

MIT

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

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

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

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

Apache 2.0

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

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


Copyright [yyyy] [name of copyright owner]

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

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

Copyright [yyyy] [name of copyright owner]

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 лицензия не требует.

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

BSD

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

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

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

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

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

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

CC0 (Creative Commons CC0)

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

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

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

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

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


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

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

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

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

Мастер Йода рекомендует:  Вести телеграм-канал по вебу

Начинается обсуждение нового проекта GPL 3

В среду стартует новый цикл споров по поводу будущего главной лицензии open-source, General Public License, который продлится 90 дней. Третий предложенный для обсуждения проект версии 3 GPL планируется выложить в 7 утра по дневному тихоокеанскому (18:00 по московскому) времени. По словам Бретта Смита, инженера по лицензионному соответствию организации Free Software Foundation, через 60 дней после третьего дискуссионного проекта должен выйти «последний» проект, после чего еще через 30 дней появится GPL 3.

Первоначально выпуск новой версии лицензии намечался на март, и теперь он отодвигается почти на три месяца. Одной из причин этой задержки стало объявление о патентном соглашении между Microsoft и Novell, по которому Microsoft пообещала не судиться с заказчиками Novell Linux за нарушение патентов. Последний проект не препятствовал выпуску программного обеспечения GPL на таких условиях, но основатель FSF Ричард Столлман считает, что организация должна найти способ запретить его. Главный вопрос заключается в том, будут ли GPL 2 и GPL 3 совместимы, комментирует член официального комитета юристов и других участников обсуждения GPL 3, адвокат DLA Piper Марк Радклифф. В случае совместимости ПО, выпущенное по одной лицензии, можно будет использовать в проектах, регулируемых другой. Иначе возникнет масса проблем и появится вероятность раскола движения на два направления, регулируемых разными версиями лицензии.

Re: Начинается обсуждение нового проекта GPL 3

Один Хэ. Всё равно придёт Торвальдс и запретит. 😉

Re: Начинается обсуждение нового проекта GPL 3

что он может запретить? нет, ну правда?

Re: Начинается обсуждение нового проекта GPL 3

Для начала — ведро. 🙂 А вобще, я пошутил. 🙂

GPLv3 регулирует не только программное обеспечение

GPL предоставляет получателям компьютерных программ следующие права, или «свободы»:

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

История

GPL была написана Ричардом Столлмэном для использования с программами как часть . Она базируется на сходных лицензиях, использовавшихся для ранних версий , GDB (отладчика GNU) и Коллекции компиляторов GNU (GCC), унифицирует и обобщает их.

GPL v1

Лицензии-прототипы содержали части, подобные частям GPL, но были специфичными для каждой программы. Целью Столлмэна являлось создание единой лицензии, которая могла бы использоваться для любого проекта, делая таким образом возможным совместное использование кода различными программами. Такой лицензией и стала первая версия GNU GPL, выпущенная в январе 1989 года.

GPL v2

В 1990 году стало очевидным, что требуется менее ограничивающая лицензия, которая могла бы использоваться для некоторых библиотек ПО; когда версия 2 GPL была выпущена в июне 1991 года, вместе с ней была введена в обращение GNU Library General Public License, также получившая номер 2, для обозначения того, что эти две лицензии являются взаимодополняющими. Номера версий разошлись в 1999 году, когда была выпущена LGPL версии 2.1, которая была переименована в Lesser General Public License для уточнения её местоположения в философии GNU.

GPL v3

В 2005 году Эбен Моглен и Ричард Столлмэн написали черновик третьей версии GPL. В разгоревшейся затем 7 апреля 2005 года в Филадельфии дискуссии Столлмэн сделал несколько заявлений, касающихся патентов на ПО и DRM.

В 2006 году Free Software Foundation начал двенадцатимесячную консультацию о возможных изменениях в GPL. Этот процесс координируется Фондом свободного программного обеспечения, Правовым центром свободы программного обеспечения и Европейским фондом свободного программного обеспечения. Целью консультаций является создание новой версии лицензии с учётом рекомендаций и опыта всех заинтересованных сторон, но с сохранением приверженности принципам свободного ПО.

Первый черновик был опубликован 16 января 2006 года.

Тем не менее, 25 января 2006 года Линус Торвальдс публично заявил, что ядро Linux, используемое в операционной системе GNU/Linux, скорее всего, будет по-прежнему распространяться по лицензии GPL версии 2. (В отличие от многих других GPL-программ, Linux распространяется на условиях только второй версии GPL, а не «версии 2 или более поздней»). [3]

В своём сообщении в почтовую рассылку для Linux-разработчиков Линус Торвальдс, автор Linux, говорит о том, что ОС Solaris может инициировать переход ядра на новую готовящуюся версию лицензии на свободное программное обеспечение — GNU GPLv3.


«Если Sun действительно собирается выпустить OpenSolaris под GPLv3, это может стать хорошей причиной» для перехода Linux на новую лицензию, заявил Торвальдс. [4]

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

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

Компании, распространяющие GPLv3-ПО, не могут предъявлять судебные претензии к пользователям GPLv3-продуктов.

Окончательная версия GPLv3 была опубликована 29 июня 2007. Черновой вариант перевода можно прочитать тут.

19 ноября 2007 была выпущена GNU Affero General Public License v3 — GPLv3 с изменениями на основе Affero General Public License v1, выпущенной в 2002 году Affero Inc. на основе GNU GPLv2. Данная лицензия добавляет возможность получения исходного кода пользователям программы, взаимодействующим с ней только через сеть. [1]

Схема GNU GPL

Текст GNU GPL состоит из нескольких пронумерованных разделов. Ниже приведена схема версии 2.0 лицензии. Эта схема не имеет никакой юридической силы и служит только для краткого ознакомления.

  1. Определения
    • (первый абзац) Определение термина «программа»
    • (второй абзац) Область действия лицензии
  2. Право на копирование и распространение
  3. Изменение программы
    • (первый абзац) Право на изменения при соблюдении следующих условий:
      • a) добавление информации об изменении в модифицированных файлах;
      • b) лицензирование модифицированных версий на условиях GNU GPL;
      • c) условное требование интерактивного вывода информации об авторских правах и отсутствии гарантии.
    • (абзацы 2—4) Уточнение термина «производная работа»
  4. Требование предоставления исходного кода
    • (первый абзац) Возможные варианты распространения исполнимого кода:
      • a) распространение вместе с исходным кодом, или
      • b) распространение с гарантией предоставления исходного кода, или
      • c) (для некоммерческого использования) распространение вместе с такой гарантией, полученной от третьего лица.
    • (второй абзац) Определение термина «исходный код»
    • (третий абзац) Достаточность одинакового доступа для копирования исполнимого и исходного кодов
  5. Прекращение действия лицензии при нарушении её условий
  6. Акты, означающие принятие лицензии
  7. Запрещение дополнительных ограничений при дальнейшем распространении
  8. Внешние ограничения не снимают обязательства выполнять условия лицензии
  9. Возможность географических ограничений
  10. Будущие версии GNU GPL
  11. Запросы на исключения из правил
  12. Отказ от предоставления гарантий
  13. Отказ от ответственности

Сложности

GNU GPL требует распространения с двоичными файлами (в том числе неизменными) исходного кода или письменного обязательства его предоставить (своего или чужого; способы зависят от версии лицензии). Так как это требование непривычно для многих пользователей и разработчиков, и потому не всегда очевидно при прочтении лицензии, то слишком поздно узнав о нём, они могут быть не готовы к его выполнению, и считать его завышенным. [5]

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

Примечания

  1. 12Free Software Foundation Releases GNU Affero General Public License Version 3 (англ.) . Free Software Foundation (2007-11-19). Проверено 28 ноября 2007.
  2. Имена авторов обычно указываются в исходном коде или документации (например, файле AUTHORS).
  3. Сообщение Линуса Торвальдса о лицензии Linux. (2006-01-25) (англ.)
  4. Сообщение Линуса Торвальдса о возможности перехода Linux на GPLv3 в случае, если Sun выпустит под ней OpenSolaris. (2007-06-10) (англ.)
  5. Bruce ByfieldA GPL requirement could have a chilling effect on derivative distros (англ.) . VA Software (27 июня 2006). Проверено 8 марта 2009.

См. также

Ссылки

  • GNU General Public License, версия 3.0 (официальный английский текст).
  • Сравнительный анализ основных copyleft-лицензий
  • Официальный сайт, посвящённый разработке версии 3 GPL: Текущий черновик, Обоснования (Rationale)
  • GPL v3 — The changes from draft 1 to draft 2 (англ.)
  • Тезисы выступления Фёдора Зуева «GNU GPL как юридический вездеход»
  • GNU GPL 3 человеческим языком. ООО «Континент». Проверено 13 июня 2008.

  • Brett SmithA Quick Gu >(англ.) . Free Software Foundation, Inc. (2007-11-08). Проверено 16 ноября 2007.
    • Перевод: Краткое руководство по GPL v3 (рус.) Обзор различий между v.2 и v.3 с диаграммой совместимости лицензий

GPL и российские законы

  • Сергей СередаСВОБОДНЫ ЛИ В РОССИИ «СВОБОДНЫЕ ЛИЦЕНЗИИ»?. Патенты и лицензии (2009-02-24). — анализ FOSS с точки зрения современного гражданско-правового и налогового законодательства РФ.
  • М. Брауде-Золотарев, Г. Гребнев, П. Протасов, А. Ралько, Е. СербинаЛицензионные договоры и Российское законодательство. INFO-FOSS.RU (2008). — о соответствии распространенных, в том числе свободных, лицензионных договоров отечественному законодательству.
  • Сергей СередаОткрытое программное обеспечение: проблемы лицензирования и доказательства легальности. ПОтребитель (2008-08-10). — анализ правового статуса FOSS в контексте современного законодательства РФ и правоприменительной практики.
  • Ася ВласоваКак украсть Linux?. Открытые системы (2008-06-24). — о FOSS-лицензиях и их применении в России.
  • Илья ШпаньковНелицензионный Linux. Компьютерра (2007-04-09). — о доказательстве легальности GNU/Linux при малой её известности.
  • Елена ТяпкинаПравовой статус GPL в России. Компьютерра-Онлайн (2002-04-09). Проверено 28 января 2008.

Переводы на русский

  • Черновик перевода GNU GPL v3
  • Перевод Елены Тяпкиной, «Стандартная общественная лицензия GNU 2.0»
  • Перевод Кузиной, Юфа, Тихонова, «Универсальная общественная лицензия GNU 2.0»
  • Перевод Сергея Середы, «Генеральная общественная лицензия GNU 2.0»
  • Перевод П. В. Протасова, «Открытое лицензионное соглашение GNU 2.0»
Проект GNU
История Манифест GNU · Проект GNU · Фонд свободного программного обеспечения · История свободного программного обеспечения
Лицензии GNU General Public License · GNU Lesser General Public License · Affero General Public License · GNU Free Documentation License · GPL linking exception
Программное обеспечение · Hurd · · Gnuzilla · IceCat · · · GCC · GNU Emacs · glibc · Coreutils · Build system · · Другие пакеты и программы GNU
Люди Роберт Часселл · Лоис Дечэри · Рикардо Галли · Джордж Грив · Федерико Хейнц · Бенджамин Хилл ·
Брэдли Кун · Эбен Моглен · Бретт Смит · Ричард Столлман · Вильям Джон Салливан
Свободное и открытое программное обеспечение
Главное Список открытого и свободного ПО · Что такое свободное ПО? · Common UNIX Printing System · GNU Project · X Window System
История Linux · Mozilla ( Application Suite · Firefox · Thunderbird )
Операционные
системы
· (ядро) · Разработка GCC · LLVM · Менеджеры
окон XWS
EDE · Étoilé · ROX · Window Maker · Организации Фонд свободного ПО (европейский, индийский, латиноамериканский) · Linux Foundation · Mozilla Foundation · Open Source Initiative
Лицензии Apache · BSD · GPL · LGPL · MIT · MPL · Либеральные лицензии · Разнообразие лицензий
Проблемы Безопасность открытого ПО · Блоб · Конфликт SCO-Linux · Патенты и свободное ПО · Собственническое ПО· Технические средства защиты авторских прав · Тивоизация · Trusted Computing
Другое · Сообщество · Движение · Свободное и открытое ПО · Revolution OS
Портал:Свободное программное обеспечение

Wikimedia Foundation . 2010 .

Смотреть что такое «Общественная лицензия GNU» в других словарях:

Универсальная общественная лицензия GNU — Запрос «GPL» перенаправляется сюда. Cм. также другие значения. Логотип GNU GNU General Public License (иногда переводят, как, например, Универсальная общественная лицензия GNU, Универсальная общедоступная лицензия GNU или Открытое лицензионное… … Википедия

GNU Lesser General Public License — Автор Free Software Foundation Версия 3 … Википедия

GNU General Public License — Запрос «GPL» перенаправляется сюда; см. также другие значения. GNU General Public License … Википедия

Лицензия — (License) История лицензирования, лицензионные условия Лицензионный договор, лицензия в патентном авторском праве Содержание Содержание Раздел 1. История лицензирования. Раздел 2. Перечень возможных . Раздел 3. Лицензия в патентном праве. Раздел… … Энциклопедия инвестора


Лицензия BSD с тремя пунктами — Лицензия BSD, Программная лицензия университета Беркли (англ. BSD license) это лицензионное соглашение, впервые применённое для распространения операционных систем свободного программного обеспечения и используются для многих программ (помимо… … Википедия

Лицензия BSD с четырьмя пунктами — Лицензия BSD, Программная лицензия университета Беркли (англ. BSD license) это лицензионное соглашение, впервые применённое для распространения операционных систем свободного программного обеспечения и используются для многих программ (помимо… … Википедия

Лицензия BSD — У этого термина существуют и другие значения, см. BSD (значения). «Новая» лицензия BSD Автор Регенты Калифорнийского университета Издатель Общественное достояние Опубликована 1983[1] Совместима с DFSG Да … Википедия

Лицензия свободного программного обеспечения — Не следует путать с лицензией open source. Пожалуйста … Википедия

Лицензия open source — Не следует путать с лицензией свободного ПО. Пожалуйста, улучшите и дополните этот раздел. Замечания о том, что нужно улучшить … Википедия

Исходная лицензия BSD — Лицензия BSD, Программная лицензия университета Беркли (англ. BSD license) это лицензионное соглашение, впервые применённое для распространения операционных систем свободного программного обеспечения и используются для многих программ (помимо… … Википедия

Можно ли LGPL использовать как библиотеку в коммерческом продукте, не открывая код продукта

Какая должна быть линковка? Статическая или обязательно динамическая? Нужно ли поставлять текст лицензии LGPL. Прочитал саму лицензию, исходя из этого ответ, что LGPL динамическая линковка позволяет держать свой код закрытым. Но хочу перестраховаться, поэтому спрашиваю вас! Большое спасибо, все-таки лицензии момент тонкий…

И еще правильно ли я понимаю, что GPL никак не обойти, чтобы использовать его в каком-нибудь виде, но не открывать свои коды? Или у кого есть какие идеи? Спасибо!

  • Вопрос задан более трёх лет назад
  • 14322 просмотра

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

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

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

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

то есть тоже может быть использована и коды открывать свои не нужно?

Нет, наоборот: статическая линковка делает из LGPL-кода и не-GPL-кода единый, неделимый модуль, и код всего этого модуля ты обязан открыть.

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

Значит, подводим итоги. Для того, чтобы не открывать свои коды мы:

1) Используем LGPL динамической линковки
2) Используем отдельное приложение на любой (?) лицензии и взаимодействуем с ним как внешним приложением
3) GPL можно использовать в закрытых проектах, если связь между компонентами происходит не путём загрузки в адресное пространство процесса, а, например, запуском GPL-программы как отдельного процесса и общением с ней через пайпы.
4) Используем BSD лицензию

Лицензирование GNU GPlv3 — программное обеспечение предоставляет услугу — не распространяется

У меня есть пара вопросов относительно лицензии GNU GPLv3. Мое приложение с закрытым исходным кодом, и я не собираюсь его публиковать. Однако он генерирует коммерческие элементы. Использование dll, лицензированных по вышеуказанной лицензии, используется и связано с программным обеспечением, которое генерирует эти коммерческие продукты.

Я просто хотел бы уточнить, что, поскольку программное обеспечение на самом деле не распространяется — только то, что генерирует программное обеспечение. Следовательно, выпуск исходного кода и т. Д. Не требуется. Лицензированные библиотеки не изменяются никаким образом.

Во-вторых, из интереса. Когда GNU GPLv3 используется коммерческим программным обеспечением (скажем, это программное обеспечение выпущено). На этот раз лицензионный материал представляет собой EXE-файл, а не .DLL и, следовательно, фактически не связан с кодом программного обеспечения. Скорее, программное обеспечение выполняет лицензионное программное обеспечение напрямую и отправляет ему аргументы в стиле командной строки и использует то, что возвращает исполняемый файл. Должен ли исходный код быть выпущен?

Спасибо, я новичок в сфере этих лицензий и немного растерялся.

1 ответ

Относительно вашего первого вопроса (если я правильно его понимаю) см. этот отрывок , взятый из FAQ по GPL:

В каких случаях продукция GPL также распространяется на GPL?


Only when the program copies part of itself into the output.

Что касается вашего второго вопроса, см. этот отрывок из FAQ по GPL (выделено мое):

Могу ли я выпустить несвободную программу, предназначенную для загрузки плагина под GPL?

It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Если вы хотите получить более подробный ответ для вашей конкретной ситуации, вы можете обратиться в Free Software Foundation напрямую по адресу (по адресу) fsf (точка) org , объяснив свой точный вариант использования.

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

Топ-10 юридических событий в сфере свободного программного обеспечения в 2015 году

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

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

1. Урегулирование судебных дел компании Versata о толковании лицензии General Public License второй версии (GPLv2)

Как мы отметили в прошлом году, GPLv2 продолжает оставаться наиболее широко используемой и самой важной лицензией для бесплатного и свободного программного обеспечения. Компания Black Duck Software полагает, что по лицензии GPLv2 было лицензировано 16 миллиардов строк программного кода. Суды разрешили несколько важных вопросов в делах компании Versata еще в 2014 году, однако все процессы были завершены в 2015 году без последующих определений.

Определения были вынесены исключительно на заявленные вопросы, и таким образом, их прецедентное значение ограничено, но они наводят на мысли, как суды будут разрешать основные вопросы, связанные с GPLv2:

(a) суд утвердил «одноуровневую» структуру GPLv2, в которой нарушение промежуточным дистрибьютором (в данном деле таковым была компания Versata Software, Inc.) не прекращает прав его последующих лицензиатов (таких компаний, как Pacific Life Ins. Co., Metropolitan Life Ins. Co., и Prudential Ins. Co. of America)

(b) определение типа деятельности, который устанавливает «распространение» и, тем самым, накладывает обязательства по лицензии GPLv2

(с) природа патентных прав, предоставленных в определенных обстоятельствах по лицензии GPLv2 (для более детального описания фактов и решений см. http://opensource.com/law/14/12/gplv2-court-decisions-versata)

Эти дела придают особое значение необходимости управления использования программного обеспечения с открытым кодом, потому что спор возник, когда Versata, вендор проприетарного программного обеспечения, включила в состав своего программного обеспечения ПО компании Ximpleware, распространяемое по лицензии GPLv2. Versata не дала пояснений, как программное обеспечение Ximpleware оказалось в ее собственном ПО, и тем самым были нарушены положения GPLv2. После обнаружения нарушения положений GPLv2, Ximpleware подала иск ко всем клиентам Versata. Учитывая то, что дела в итоге завершились мировыми соглашениями, придется подождать иное судебное разбирательство, чтобы уточнить толкование положений лицензии GPLv2.

2. Первое решение о толковании лицензии General Public License третьей версии (GPLv3)

Земельный суд г. Халле, Германия в июле 2015 г. вынес первое решение о толковании лицензии GPLv3. Дело касалось действий института высшего образования. Ответчик (лицензиат) не возражал против заявлений о нарушении GPLv3. Вместо этого, спор был сосредоточен на применении «восстановительных» положений раздела 8 лицензии GPLv3. Раздел 8 сохраняет автоматическое расторжение, предусмотренное в лицензии GPLv2, но предусматривает восстановление прав в рамках этой лицензии, если лицензиат устранил нарушение в течение 30 дней.

В этом деле, пользователь устранил свое нарушение в рамках требуемого срока, но отказался подписать заявление о прекращении продолжения противоправных действий, которое было испрошено истцом для того, чтобы стимулировать ответчика воздержаться от повторного нарушения положений GPLv3. Суд постановил, что положение раздела 8 о восстановлении прав не лишает истца права на предварительный судебный запрет для предотвращения нарушений в будущем, в частности, если ответчик отказался подписать заявление истца о прекращении продолжения противоправных действий. Для более детальной информации смотрите материал «Немецкий суд исследует положения раздела 8 лицензии GPLv3 о расторжении» авторства Ричарда Фонтаны (Richard Fontana).

3. Linux-программист судит VMWare за нарушение GPLv2 для Linux

Операционная система Linux является одной из наиболее широко используемых в мире программ из ряда свободного программного обеспечения, но до сих пор редко затронутой судебными процессами. Как бы то ни было, в марте 2015 года Кристоф Хелльвиг (Christoph Hellwig), ключевой разработчик ядра Linux, подал иск к компании VMware в окружной суд Гамбурга, Германия. Хельвиг заявил, что VMware нарушила условия GPLv2 путем комбинирования собственного кода VMware, именуемого как «vmkernel», с Linux таким образом, что была создано производное произведение, но не был при этом предоставлен соответствующий исходный код vmkernel по лицензии GPLv2. Vmkernel является «ядром» операционной системы ESXi компании VMware, которая управляет аппаратными и программными ресурсами физического сервера.

VMware ответила, что vmkernel не является производным произведением по отношению к Linux, а только взаимодействует с Linux посредством VMK API. VMware также отметила, что драйверы, работающие с vmkernel, не нуждаются в Linux-драйверах, но VMware предлагает «совместимую альтернативу посредством загружаемого модуля ядра «vmklinux», связанного с любыми Linux-драйверами, которая загружается посредством vmkernel и подключается через VMK API». Факты, относимые к делу, не могли быть подтверждены, поскольку иск и другие судебные документы являются конфиденциальной информацией в соответствии с правилами судопроизводства в Германии. Это дело с большой долей вероятности станет очень важным в определении объема GPLv2, поскольку стороны, видимо, не достигнут соглашения в этом споре.

4. Соблюдение норм сообщества GPL

Организации Software Freedom Conservancy и Free Software Foundation объединились в этом году для разработки «Принципов сообщества, ориентированных на применение GPL» (Руководящих принципов), опубликованных в сентябре 2015 года (здесь и здесь). Возрастание судебных процессов в отношении свободного программного обеспечения стало источником озабоченности сообщества, и поэтому Руководящие принципы предназначены помочь сообществу в подготовке базы для последовательного и единого подхода к правоприменению. Руководящие принципы следуют за прошлогодней публикацией второго издания Практического руководства по соблюдению GPL, подготовленного организацией Software Freedom Law Center, и совместной публикации совместного первого издания SFC и FSF «Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide».

5. Антимонопольное расследование Европейской Комиссии в отношении Google и ее операционной системы Android

Европейская Комиссия начала неофициальное расследование с целью определить, являются ли определенные положения договоров Google на дистрибуцию операционной системы Android нарушением антимонопольного законодательства Европейского союза. Комиссия с особым вниманием изучает вопрос, нарушают ли положения соглашений по ОС Android, требующих использование собственных приложений и сервисов Google, правовые нормы ЕС. Расследование Комиссии будет сфокусировано на трех следующих заявлениях:

действительно ли Google неправомерно препятствует развитию и доступу на рынок конкурирующих мобильных приложений или сервисов путем требования или стимулирования производителей смартфонов и планшетов эксклюзивной предустановки мобильных приложений или сервисов Google;

действительно ли Google препятствует производителям смартфонов и планшетов, которые желают устанавливать приложения и сервисы Google, от разработки и маркетинга модифицированных и потенциально конкурирующих версий Android (так называемых «форков Android») на других устройствах, тем самым неправомерно препятствуя развитию и доступу на рынок конкурирующих мобильных операционных систем и мобильных приложений или сервисов;

действительно ли Google неправомерно препятствует развитию и доступу на рынок конкурирующих приложений и сервисов путем навязывания или предоставления в комплекте определенных приложений и сервисов Google, распространяемых на Android-устройствах, вместе с другими приложениями, сервисами и/или программными интерфейсами приложений Google.

Расследование демонстрирует важность ОС Android на рынке смартфонов и планшетов, т.к. Комиссия исследует потенциальное нарушение Google касательно ее «доминирующей позиции» в отношении ОС Android.

6. Продолжается ветвление Android

CyanogenMod LLC является компанией, поддерживаемой венчурным капиталом, которая разработала CyanogenMod, специализированную послепродажную прошивку для устройств, работающих на Android. Прошивка CyanogenMod основана на проекте Android Open Source Project. Прошивка CyanogenMod позиционируется как важный потенциальный конкурент для ОС Android из-за ее существенного финансирования. Как бы то ни было, потенциальная бизнес-модель компании является сейчас объектом судебного разбирательства в Индии.

Одним из первых лицензиатов компании CyanogenMod была компания Oppo Electronics, которая является частью BBK Electronics Group, огромной компании из КНР. CyanogenMod предоставила Oppo неисключительную, действительную на территории всего мира лицензию, и Oppo основала новую компанию, OnePlus, для дистрибуции своего телефона на базе прошивки CyanogenMod. Тем не менее, CyanogenMod также предоставила исключительные права в Индии компании Micromax Informatics, Ltd. Индийский суд установил, что Micromax обладала исключительными правами на прошивку CyanogenMod и товарный знак в Индии. Позднее, OnePlus решила развивать свою собственную версию ОС Android и прекратить использование прошивки CyanogenMod. Такая версия будет, равно как и прошивка CyanogenMod, базироваться на проекте Android Open Source Project. Это дело демонстрирует гибкость использования ОС Android, равно как и трудности разработки альтернативной версии Google Android.

7. Политики содействия

Все проекты с открытым исходным кодом нуждаются в основаниях о получении прав на интеллектуальную собственность (ИС) от контрибьюторов [1] в таком объеме, который позволит быть убежденными в том, что проекты могут лицензировать своим пользователям софт, разрабатываемый в рамках проектов. Многие проекты используют либо «проектные лицензии», либо контрибьюторские лицензионные соглашения (проекты, которые взамен этого требуют отчуждения исключительного права на контрибьюты, очень малочисленны). Как бы то ни было, использование «контрибьюторских лицензионных соглашений» очень противоречиво в определенных сообществах, и в частности, в Linux-сообществе. С другой стороны, мой обзор электронных писем во время разработки лицензии Apache Software License второй версии (ASLv2) и обсуждение с лицами, вовлеченными в подготовку этого документа, дает ясно понять, что ASLv2 была предназначена для использования совместно со стандартными контрибьюторскими лицензионными соглашениями, разработанных в то же время, что и ASLv2, при том, что содержащийся в ASLv2 раздел 5 является «резервной копией» для контрибьютов.

Различные взгляды сообществ свободного программного обеспечения были очень наглядны в споре с сообществом OpenStack по поводу использования стандартных контрибьюторских лицензионных соглашений Apache. Многие опытные разработчики из Linux-сообщества сильно возражали против продолжения использования контрибьюторских лицензионных соглашений Apache и хотели применять Сертификат происхождения разработки (Developers Certificate of Origin, сокр. DCO), используемый в Linux-сообществе. После существенных дебатов Совет директоров [2] принял решение продолжать использовать стандартное контрибьюторское лицензионное соглашение Apache в отношении контрибьютов, предоставляемых компаниями, но применять процедуру DCO к контрибьютам от физических лиц.

8. Компании публикуют проекты под свободными лицензиями

Как мы отмечали в прошлом году, многие крупные компании использовали СПО как явную стратегию для развития своего программного обеспечения, и эта тенденция продолжает сохраняться и набирать обороты в этом году. Джим Землин (Jim Zemlin), исполнительный директор фонда Linux Foundation, описал такое стратегическое использование СПО как внешние «исследование и разработка». В прошлом году Microsoft опубликовала под свободной лицензией программный фреймворк .NET (программное обеспечение, используемое миллионами разработчиков для создания функциональных сайтов и других крупных онлайн-приложений). В этом году корпорация Apple анонсировала раскрытие программного кода языка программирования Swift. Это событие продолжает тенденцию, когда крупные компании используют методы разработки СПО для управления проектами, изначально созданными внутри компаний, но которые могут быть более эффективными под управлением сообщества.

9. Успешное предоставление освобождения по статье 501(c)(6)

Несколько лет назад фонды СПО в соответствии с федеральным налоговым законодательством регулярно освобождались Налоговым управлением США (IRS) от уплаты налогов на основании статьи 501(c)(6). [3] Такое освобождение позволяло исключать из налоговой базы фондов СПО взносы их участников. Однако, в последние 3-4 года IRS обычно отказывала фондам СПО в таких освобождениях. Тем не менее, в этом году фонд OpenStack Foundation успешно добился получения подобного освобождения от уплаты налога на основании положений статьи 501(c)(6), хотя для этого фонду пришлось оспорить первоначальный отказ в получении такого освобождения, который и был оспорен в его пользу.

Ответы Управления фонду демонстрируют существенное непонимание того, как функционируют фонды СПО и какую роль они играют. Например, Управление полагало, что фонд является прямым конкурентом Amazon, Google и Microsoft в отношении облачных предложений. Хотя фонд в конечном итоге добился своего, такие непонимания продолжат оставаться головной болью для подобных запросов об освобождении на основании статьи 501(c)(6). Чтобы помочь сообществу, фонд сделает в этом году доступными на сайте Open Source Initiative (OSI) свои заявления, ответы IRS и свои последующие действия.

10. Потенциальный запрет от FCC на свободное программное обеспечение в роутерах

Федеральная комиссия по связи США (FCC) продемонстрировала схожее непонимание свободного программного обеспечения в предлагаемых ею новых правилах в отношении роутеров. Первоначальный проект правил, по-видимому, запрещал использование СПО, т.к. содержал требование, в соответствии с которым производители должны предотвращать использование пользовательских модификаций, которые могут активировать радиосвязь в роутерах, что будет выходить за пределы их лицензии или лицензионных параметров. Комиссия отметила, что действия направлены на устранение помех в доплеровских радарах Федерального авиационного агентства США (FAA), возникающих из-за подобных модифицированных устройств и других возможных проблем.

После массовых негативных отзывов со стороны сообщества свободного программного обеспечения Комиссия дала разъяснения, что ее правила не направлены на запрет использования свободного программного обеспечения и что производители роутеров могут реализовать эти правила на практике, используя технические средства. Многие авторы замечаний в адрес Комиссии из числа сообщества СПО остаются скептически настроенными к ответу Комиссии. Сама она пока еще не вынесла окончательного решения. Тем не менее, по крайней мере, один из таких авторов отзывов отметил, что в прошлом Комиссия взаимодействовала с Linux-дистрибьюторами в целях обеспечения возможности развертывания беспроводных точек доступа на базе компьютеров под управлением Linux, поэтому мы можем надеяться, что эта проблема будет разрешена с учетом интересов сообщества свободного программного обеспечения.

Могу ли я использовать программу GNU GPLv3 для коммерческих целей?

Можно ли использовать wkhtmltopdf (лицензию под GNU GPL v3 ) в качестве части моего коммерческого приложения?

Если я использую часть программного обеспечения, полученную под GNU GPL, могу ли я изменить исходный код в новую программу, а затем распространять и продавать эту новую коммерческую программу?

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

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

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

Из комментариев становится ясно, что вы намерены запускать программное обеспечение на сервере и продавать его.

Это не распространяется ( «передача» ) в терминах лицензии GPLv3.

Если, с другой стороны, если wkhtmltopdf был покрыт под GNU Affero Public License, вам пришлось бы сделать исходный код, включая любые сделанные вами изменения.

У меня есть хорошие новости для всех

В официальном FAQ GPL говорится:

Если программа, выпущенная под GPL использует плагины, каковы требования к лицензиям плагин?

Если программа использует fork и exec для вызывать плагины, тогда плагины отдельные программы, поэтому лицензия на основная программа не требует никаких требований для них.

Мастер Йода рекомендует:  SEO — всё по этой теме для программистов
Добавить комментарий