Bsd лицензия

Лицензия BSD software license (BSD)

Данное лицензионное соглашение разработано университетом Беркли, где впервые были применены условия распространения программы с открытым кодом для распространения UNIX – подобных операционных систем. Лицензия BSD предусматривает следующие условия использования программы для ЭВМ:

  • 1) распространение полученного открытого кода ПО с изменениями или без них, исходя из условий, полученных и определенных лицензией;
  • 2) указание неимущественных прав учредителей университета Калифорнии на исходный открытый код BSD;
  • 3) использование открытого кода ПО;
  • 4) возможность модификации исходного кода, полученного в любой форме;
  • 5) возможность коммерческого использования ПО;
  • 6) отсутствие ответственности лицензиара за качество распространяемого открытого кода ПО;
  • 7) отсутствие ответственности лицензиара за любые убытки, возникшие в связи с использованием лицензируемой программы.

Лицензия BSD налагает меньше ограничений на пользователя, чем GNU GPL. По данной лицензии разработанное ПО можно включать в коммерческие продукты, однако полученное ПО обязано соответствовать требованиям лицензии. Наиболее заметные примеры таких программ – использование сетевого кода BSD в продуктах корпорации Microsoft, а также использование многих компонентов FreeBSD в операционной системе Mac OS X.

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

Несмотря на такое принципиальное положение, лицензия BSD и другие лицензии признаны Фондом свободного программного обеспечения [1] соответствующими принципам свободного ПО и считаются лицензиями на свободное ПО.

Лицензия MIT (Massachusetts Institute of Technology) создана на основе лицензии BSD Массачусетским технологическим институтом и признается совместимой с лицензией GPL. Лицензия содержит следующие условия:

  • 1) право распоряжения открытым кодом программного обеспечения, в том числе распространения сетевым способом;
  • 2) право воспроизводить (копировать) открытый код ПО;
  • 3) право на использование;
  • 4) право модифицировать открытый код ПО;
  • 5) право публиковать ПО или исходный открытый код;
  • 6) допускаются сублицензии при условии, что текст лицензионного соглашения должен быть включен во все копии или значимые части разрабатываемого и распространяемого ПО;
  • 7) право определять форму возмездности;
  • 8) отсутствие любого вида гарантий со стороны лицензиара, в том числе ответственности за качество распространяемого открытого кода ПО, за любые убытки, возникшие в связи с использованием лицензируемой программы.

Наиболее известным ПО, распространяемым по данной лицензии, является X Window System.

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

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

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

Есть много вариантов простых лицензий свободных программ без авторского лева, таких, как лицензии Expat, FreeBSD, X10, X11 и две лицензии BSD (Дистрибутива программ Беркли). Большинство из них различаются только деталями формулировок, но у лицензии, которую BSD применял до 1999 года, была особая проблема: “злостный параграф BSD о рекламе”. В нем говорилось, что любая реклама, упоминающая программу, должна содержать определенное предложение:

Сначала злостный параграф BSD о рекламе использовался только в Дистрибутиве программ Беркли. Это особых проблем не вызывало, потому что добавление одного предложения в рекламу больших затруднений не представляет.

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

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

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

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

Чтобы решить эту проблему, в свое “свободное время” я обращаюсь к разработчикам, применяющим лицензии в стиле BSD, и уговариваю их удалить параграф о рекламе. Приблизительно в 1996 году я разговаривал об этом с разработчиками FreeBSD, и они решили удалить параграф о рекламе изо всех своих исходных текстов. В мае 1998 года разработчики Flick из Университета Юты удалили этот параграф.

Хел Вериэн, декан Университета Калифорнии, занялся этим параграфом и воевал по этому поводу с администрацией. В июне 1999 года, после двух лет обсуждений, Университет Калифорнии удалил этот параграф из лицензии BSD.

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

Но если они следовали примеру Беркли раньше, то может быть, изменение в правилах Беркли убедит некоторых из них поступить так же. Попросить об этом стоит.

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

И если вы хотите выпустить свободную программу без авторского лева, пожалуйста, не применяйте параграф о рекламе. Так, вместо того чтобы копировать лицензию BSD из какого-нибудь выпущенного пакета программ — в котором все еще может оказаться старая версия лицензии — возьмите, пожалуйста, одну из других либеральных лицензий, таких, как лицензия Expat или FreeBSD.

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

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

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

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

Впоследствии был введен другой вариант лицензии BSD, в котором были только первые два из четырех параграфов первоначальной лицензии BSD. Мы называем ее “лицензией FreeBSD”. Это безвольная лицензия свободных программ без авторского лева, совместимая с GNU GPL, практически как модифицированная лицензия BSD.

Смотрите так же:  Приказ 173 минфина

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

Фонд свободного программного обеспечения — ведущая организация, ответственная за разработку операционной системы GNU. Поддержите GNU и ФСПО покупкой руководств и других товаров, присоединением к ФСПО в качестве члена-партнера или пожертвованиями.

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

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

Сведения по координации и предложениям переводов наших статей см. в “Руководстве по переводам”.

Copyright © 1998, 1999, 2001, 2003, 2007, 2010, 2012, 2013, 2014, 2015 Free Software Foundation, Inc.

Вопрос по лицензии BSD

НИ В КОЕМ СЛУЧАЕ НИ ОДИН ВЛАДЕЛЕЦ АВТОРСКИХ ПРАВ И НИ ОДНО ДРУГОЕ ЛИЦО, КОТОРОЕ МОЖЕТ ИЗМЕНЯТЬ И/ИЛИ ПОВТОРНО РАСПРОСТРАНЯТЬ ПРОГРАММУ, КАК БЫЛО СКАЗАНО ВЫШЕ, НЕ НЕСЁТ ОТВЕТСТВЕННОСТИ, ВКЛЮЧАЯ ЛЮБЫЕ ОБЩИЕ, СЛУЧАЙНЫЕ, СПЕЦИАЛЬНЫЕ ИЛИ ПОСЛЕДОВАВШИЕ УБЫТКИ, ВСЛЕДСТВИЕ ИСПОЛЬЗОВАНИЯ ИЛИ НЕВОЗМОЖНОСТИ ИСПОЛЬЗОВАНИЯ ПРОГРАММЫ (ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ПОТЕРЕЙ ДАННЫХ, ИЛИ ДАННЫМИ, СТАВШИМИ НЕПРАВИЛЬНЫМИ, ИЛИ ПОТЕРЯМИ, ПРИНЕСЕННЫМИ ИЗ-ЗА ВАС ИЛИ ТРЕТЬИХ ЛИЦ, ИЛИ ОТКАЗОМ ПРОГРАММЫ РАБОТАТЬ СОВМЕСТНО С ДРУГИМИ ПРОГРАММАМИ), ДАЖЕ ЕСЛИ ТАКОЙ ВЛАДЕЛЕЦ ИЛИ ДРУГОЕ ЛИЦО БЫЛИ ИЗВЕЩЕНЫ О ВОЗМОЖНОСТИ ТАКИХ УБЫТКОВ.

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

мЙГЕОЪЙС FreeBSD

Copyright 1992-2012 FreeBSD Project. чУЕ РТБЧБ ЪБЭЙЭЕОЩ.

тБУРТПУФТБОЕОЙЕ Й ЙУРПМШЪПЧБОЙЕ ЙУИПДОЩИ Й ‘УЛПНРЙМЙТПЧБООЩИ’ ЖПТН, У НПДЙЖЙЛБГЙЕК ЙМЙ ВЕЪ ПОПК, ТБЪТЕЫЕОЩ РТЙ УПВМАДЕОЙЙ УМЕДХАЭЙИ УПЗМБЫЕОЙК:

  1. тБУРТПУФТБОСЕНЩЕ ЛПРЙЙ ЙУИПДОПЗП ЛПДБ ДПМЦОЩ УПИТБОСФШ ЧЩЫЕХРПНСОХФЩЕ ПВЯСЧМЕОЙС copyright, ЬФПФ УРЙУПЛ РПМПЦЕОЙК Й УПИТБОСФШ УМЕДХАЭЙК ПФЛБЪ ПФ РТБЧ.
  2. тБУРТПУФТБОСЕНЩЕ ЛПРЙЙ УЛПНРЙМЙТПЧБООЩИ ЖПТН ДПМЦОЩ РПЧФПТСФШ ЧЩЫЕХРПНСОХФЩЕ ПВЯСЧМЕОЙС copyright, ЬФПФ УРЙУПЛ РПМПЦЕОЙК Й УМЕДХАЭЙК ПФЛБЪ Ч ДПЛХНЕОФБГЙЙ Й/ЙМЙ ДТХЗЙИ НБФЕТЙБМБИ, РПУФБЧМСЕНЩИ У ДЙУФТЙВШАГЙЕК.

ьфп ртпзтбннопе пвеуреюеойе рпуфбчмсефус ртпелфпн FREEBSD «лбл еуфш» веъ лблпзп-мйвп чйдб збтбофйк, чщтбцеоощи счоп ймй рпдтбъхнечбенщи, члмаюбс, оп ое пзтбойюйчбсуш йнй, рпдтбъхнечбенще збтбофйй лпннетюеулпк геоопуфй й ртйзпдопуфй дмс лполтефопк гемй. ой ч лпен умхюбе, еумй ое фтевхефус уппфчефуфчхаэйн ъблпопн, ймй ое хуфбопчмеоп ч хуфопк жптне, ой пдйо детцбфемш бчфптулйи ртбч й ой пдоп дтхзпе мйгп, лпфптпе нпцеф йънеосфш й/ймй рпчфптоп тбуртпуфтбосфш ртпзтбннх, лбл вщмп тбътеыеоп чщые, ое пфчефуфчеоощ ретед чбнй ъб хвщфлй, члмаюбс мавще пвэйе, умхюбкоще, урегйбмшоще ймй рпумедпчбчыйе хвщфлй, ртпйуфелбаэйе йъ йурпмшъпчбойс ймй оечпънпцопуфй йурпмшъпчбойс ртпзтбннщ (члмаюбс, оп ое пзтбойюйчбсуш рпфетек дбоощи, ймй дбоощнй, уфбчыйнй оертбчймшощнй, ймй рпфетснй ртйоеуеоощнй йъ-ъб чбу ймй фтефшйи мйг, ймй пфлбъпн ртпзтбннщ тбвпфбфш упчнеуфоп у дтхзйнй ртпзтбннбнй), дбце еумй фблпк детцбфемш ймй дтхзпе мйгп вщмй йъчеэеощ п чпънпцопуфй фблйи хвщфлпч.

нОЕОЙС Й УПЗМБЫЕОЙС, УПДЕТЦБЭЙЕУС Ч РТПЗТБННОПН ПВЕУРЕЮЕОЙЙ Й ДПЛХНЕОФБГЙЙ, СЧМСАФУС БЧФПТУЛЙНЙ Й ОЕ ДПМЦОЩ ВЩФШ ЙОФЕТРТЕФЙТПЧБОЩ ЛБЛ РТЕДУФБЧМЕОЙЕ ПЖЙГЙБМШОЩИ РТБЧЙМ, СЧОЩИ ЙМЙ УЛТЩФЩИ, рТПЕЛФБ FreeBSD.

чбцоп: ДБООЩК РЕТЕЧПД МЙГЕОЪЙПООПЗП УПЗМБЫЕОЙС РТЙЧПДЙФУС ДМС ПЪОБЛПНЙФЕМШОЩИ ГЕМЕК. пЖЙГЙБМШОПК ЧЕТУЙЕК МЙГЕОЪЙПООПЗП УПЗМБЫЕОЙС СЧМСЕФУС БОЗМПСЪЩЮОБС; РТЙ ЬФПН, ОЕ ЙУЛМАЮЕОП, ЮФП ЕЈ РТЙНЕОЕОЙЕ ПЗТБОЙЮЙЧБЕФУС МПЛБМШОЩН ЪБЛПОПДБФЕМШУФЧПН.

Сравнительный анализ основных лицензий Open Source: GPL, LGPL, BSD, MIT, Mozilla public license, Apache software license

Тезисы доклада на семинаре «Открытые системы: философия, технология, бизнес» (проведенного 30 января 2002 г. Институтом Логики и ALT Linux): Все шесть лицензий, которые будут рассматриваться в настоящем докладе, являются лицензиями, одобренными Open Source Initiative для распространения ПО с открытым исходным текстом. Эти же лицензии называются «лицензиями на свободное ПО» (free software licenses) на сайте проекта GNU Free software foundation (FSF).

1. Различие между категориями «free software» и «Open source».

Все шесть лицензий, которые будут рассматриваться в настоящем докладе, являются лицензиями, одобренными Open Source Initiative для распространения ПО с открытым исходным текстом. Эти же лицензии называются «лицензиями на свободное ПО» (free software licenses) на сайте проекта GNU Free software foundation (FSF). При этом совместимыми с лицензией GPL из указанных лицензий являются только три: LGPL, BSD и лицензия MIT. Лицензии Apache (версии 1.0 и 1.1), и Mozilla (версии 1.0 и 1.1) — лицензии на свободное ПО, несовместимые с GPL. В связи с этим хотелось бы кратко остановиться на различиях между концепциями «свободного ПО» (free software) и «ПО с открытыми исходными текстами».

Представители «Open Source Initiative», в частности г-н Давид Уилер (David A. Wheeler) употребляет эти термины, как синонимы, определяющие одно и то же понятие, однако указывает на их различное содержание. В своей статье он пишет: «Те, кто использует термин «ПО с открытыми исходными текстами» хотят подчеркнуть технические преимущества такого ПО (например, большую надежность и безопасность), тогда как те, кто использует термин «свободное ПО», хотят подчеркнуть независимость от контроля со стороны третьих лиц за использованием ПО».

Как считают представители FSF, в настоящее время Free Software и Open Source являются двумя самостоятельными движениями. «Мы не против движения Open Source, но мы не хотим, чтобы нас путали с этим движением», — так так указано на сайте FSF. Представители FSF считают, что понятие «ПО с открытыми исходными текстами» более-менее соответствует понятию «свободного ПО», однако предпочитают использовать именно последнее определение и приводят для этого целый ряд аргументов:

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

2. Названия и тексты лицензий.

Тексты лицензий на английском языке можно найти как на сайте Open Source Initiative, так и на сайте GNU. Очевидно, что текст GPL и LGPL, а также изменения к ним или новые версии этих лицензий, если они появятся, лучше всего брать с сайта GNU. Однако тексты остальных лицензий: MIT, BSD, Mozilla public license, Apache software license лучше всего взять с сайта Open Source. Если вы внимательно прочитаете список лицензий на сайте Open Source и сравните его со списком лицензий на сайте GNU, то убедитесь, что отдельные лицензии на сайте GNU называются иначе. В частности, лицензия MIT на сайте GNU называется Expat license. Текст этой лицензии почти полностью соответствует тексту лицензии BSD, за исключением одного условия. В русских компьютерных изданиях упоминается также лицензия X-консорциума, или X11 (так она называется на сайте GNU). Этой лицензии нет в списке лицензий на сайте Open Source, может быть потому, что она практически повторяет лицензию MIT.

Отдельно следует остановиться на тексте лицензии BSD. Как известно, существует два варианта ее текста: с оговоркой о рекламе и без этой оговорки. Лицензия, которая одобрена для применения как Open Source, так и FSF — это лицензия без оговорки о рекламе. Эта оговорка была официально отменена директором Департамента Технологического Лицензирования Калифорнийского университета 22 июля 1999г. Текст лицензии BSD лучше брать с сайта Open Source.

В 2001г. появился еще один вариант лицензии BSD — это лицензия корпорации Intel «BSD+Patent License». Она специально разработана для того, чтобы позволить модифицировать и распространять ПО, которое может защищаться патентами на программное обеспечение корпорации Intel.

3. Совместимость с GPL.

Как уже было сказано выше, совместимыми с GPL из остальных пяти указанных лицензий, являются только три: LGPL, BSD, MIT. Совместимость с GPL означает, что разработчик вправе объединить модуль, который распространяется на условиях совместимой с GPL лицензии с модулем, распространяемым на условиях GPL, чтобы получить одну программу. Дальнейшее распространение полученной программы должно осуществляться в соответствии с условиями GPL (так называемый «Copyleft virus»).

4. Сравнительная характеристика лицензий.

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

Смотрите так же:  Гпк иск по месту нахождения имущества

[Внезапно! Вещества] BSD лицензия позволяет её отGPLить?

За примером далеко ходить не нужно. Взять и выпустить GNUBSD под лицензией GPL?

но допускается двойное лицензирование.

Щас придёт iZen

и отGPLит тебя. Но сначала поBSDит.

лицензия BSD даёт свободу делать с кодом что угодно при условии что будут публиковаться имен авторов кода. Можно в том числе и «открыть» код.

>лицензия BSD даёт свободу делать с кодом что угодно

Как говорят коммунисты, «свобода воровать».

Можно использовать BSD код (за исключением 4-clause BSD license) в своём GPL проекте, но «отGPLить» BSD код нельзя.

Даже так — нафига GPLить, если можно просто использовать в своём GPL коде BSD код? Из принципа?

Выпустить FreeBSD хочу под лицензией GPL

они говорят «грабь награбленное».

лицензия BSD даёт свободу делать с кодом что угодно при условии что будут публиковаться имен авторов кода.

именно по этому она и не совместима с GPL, так как накладывает дополнительное ограничение

Выпустить FreeBSD хочу под лицензией GPL

Хм, почему-то это ещё никто не сделал 😉

Если выпустишь — авторы (любой из авторов) имеют право и причину подать в суд.

Если ты не автор с исключительными правами, то:

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

2) И не можешь её удалять.

3) Можешь менять код, и добавлять к лицензии фразу — «мои изменения под такой-то лицензией» и писать свою лицензию туда (см. пункт 1).

А вообще — я не люблю лицензии. Если разработчик лицензирует софт, это значит, что он имеет желание (потенциально) с кем-то судиться. Нфг?

Смотря что подразумевать под BSDL. Они бывают разные, и даже некоторые лицензии в BSD-style обзывают BSDL (например Apache и ISC). Например, отGPLить код под лицензией ISC можно (OpenBSD, например). Код, который распространяется на условиях старой BSDL — нельзя.

Похоже ты путаешь «compatible with GPL» и «отGPLить» в смысле ТС.

Они все compatible, кроме 4-clause.

Но «отGPLить», т.е. сменить лицензию не может никто кроме автора.

quasimoto> Но «отGPLить», т.е. сменить лицензию не может никто кроме автора.

Имеется в виду — использовать лицензию конечного продукта. Можно взять OpenBSD, подправить в попов-стайл — и выложить под GPL. Никаких нарушений тогда не будет.

Если сохранять копирайты то да — всё ок, просто двойное лицензирование. А если затирать — это нарушение. Правда если в попов-стайл — кому до этого дело.

quasimoto> Если сохранять копирайты то да — всё ок, просто двойное лицензирование. А если затирать — это нарушение. Правда если в попов-стайл — кому до этого дело.

Копирайты к лицензии никакого отношения не имеют. Копирайты — это закон об авторском праве.

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

Ну. В составе MS Windows я что-то не видел текст BSDL — только EULA.

В составе MS Windows я что-то не видел текст BSDL — только EULA.

Ну они могли списать реализацию TCP/IP, отрефакторить код — в итоге продукт всё равно закрыт. А вот при BSD -> GPL диверсии можно будет верифицировать подмену (так как код в итоге открыт). Так что не пройдёт.

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

А кто тут у нас закалён в лицензионных срачах?
Какая у нас есть лицензия чтобы код по ней можно было влинковывать в проприетарщину, но закрыть код было нельзя и чтобы изменения в этот маленький кусочек кода должны быть сводобными?
Код будет распространяться, разумеется, в исходниках, но нужно чтобы у проприетарщиков не было проблем вообще никаких. Т.е. чтобы не нужно было танцевать вокруг .so и т.п. Чтобы код можно было просто бросить в проект и юзать как хочешь, но если вдруг в код внесены изменения и кому-то хочется так же, то лицензия обязывала бы такими изменениями делиться.

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

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

Не распарсил, открытыми должны быть изменения библиотеки или библиотека полностью, включая изменения?

в исходниках, но нужно чтобы у проприетарщиков не было проблем вообще никаких.

А какая разница? Будет открыто всё — ок. Будут открыты лишь диффы — берёшь оригинальную либу и накладываешь диффы.

I am not a lawyer

Вроде LGPL подходит, разрешает линковаться к закрытому ПО при условии открытия всех изменений библиотеки.

Не уверен, как там обстоят дела с танцами вокруг .so, но посмотри LGPL. По описанию похоже.

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

«Обычно» просто обычно или это диктуется какими-то хитрыми нюансами?

Наверное имеется в виду что закрытое ПО и LGPL библиотеку нельзя линковать статически.

но закрыть код было нельзя
закрыть код

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

Если вы имеете в виду то, что сказали, то такая лицензия называется *несвободной*.

Наверное имеется в виду что [несвободное] ПО и [библиотеку под] LGPL нельзя линковать статически.

Нет, если бы имелось в виду эта ложная мысль, то сказано так, как сказано, быть не могло.

А вот хотелось бы чтобы было можно.

«Обычно» [— это] просто обычно.

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

http://stackoverflow.com/a/10179181
Библиотеки лицензированные под LGPL нельзя линковать с закрытым ПО, если только не предоставить способ перелинковать ПО с другой версией библиотеки.

они обычно разделяемые

Можно статически собрать в один бинарник.

А вот хотелось бы чтобы было можно.

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

Можно. Но нужно предоставить объектники, чтобы юзер мог перелинковать при желании.

Можно статически собрать в один бинарник.

Нет, ты утверждал:

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

Но используя библиотеку лицензированную под LGPL нельзя линковать код статически, получается что «свободная» лицензия всё же запрещает.

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

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

Мы обсуждаем лицензионную возможность, а не лень вендора.

Библиотеки лицензированные под LGPL нельзя линковать с закрытым ПО

Может быть, я просто неправильно вас понимаю — вы используете какие-то странные термины.

Вот это что такое?

Если же я вас все-таки правильно сначала понял, то у вас формулировка с ног на голову перевернута.

Отличительная черта GNU Lesser GPL — она разрешает компоновать (в расширенном смысле) программу Б под собой с любыми (в том числе несвободными) программами при условии, что программа Б сама по себе останется свободной: и в частности всякий пользователь сохранит за собой право на изменение программы Б, даже когда она связана с несвободной программой.

Никакой умышленной дискриминации того или иного способа компоновки тут нет.

Теоретически возможность есть, но на практике может получиться совсем иначе.

Это уже проблемы вендора, пусть он их и разгребает. У тех, кто разрабатывает СПО в публичном репозитории кода, таких проблем нет. Вендор сам выбрал путь страдания.

Лицензия позволяет использовать код как угодно

Это целая плеяда лицензий, что зовутся свободными.

Смотрите так же:  Пособие выплачивается после рождения ребенка

на условии раскрытия изменений в код под такой же лицензией.

«Раскрытия» — это как? Обратите внимание на первое мое письмо в эту ветку.

Если вы не имеете в виду ничего сверх условий GNU AGPL, то это тоже целая плеяда лицензий, что зовутся лицензиями авторского лева.

Разница (в том числе умышленная) между ними в том, что́ же считается «изменениями в код».

Вот что это такое

https://en.wikipedia.org/wiki/Closed_source
Воин Свободы, closed это алиас proprietary.
И мы с тобой прожигаем время на opensource.ru, а не на freesoftware.ru

Отличительная черта GNU Lesser GPL — она разрешает компоновать (в расширенном смысле) программу Б под собой с любыми (в том числе несвободными) программами при условии, что программа Б сама по себе останется свободной: и в частности всякий пользователь сохранит за собой право на изменение программы Б, даже когда она связана с несвободной программой.

Too complicated, проще не касаться копилефта и не кормить юристов FSF.

нужно чтобы у проприетарщиков не было проблем вообще никаких

*Никаких* проблем у них не будет, когда вы им свои исключительные имущественные права уступите.

что́ же считается «изменениями в код».

Я может совсем тупой, но как можно различно трактовать слово «изменение»? Есть код. Изменил хоть сраный байт, пусть это даже прибежал Саакрихту и перекодировал в КОИ-7, то будь любезен предоставить полученный результат по требованию.
Изменил логику — предоставь по требованию.
Не понимаю.
Приведи пример когда изменение может не считаться изменением.

closed это алиас proprietary

Ой-ой? Вы никакое слово не пропустили? И потом, вы кажется английских слов тут вовсе не произносили.

проще не касаться копилефта

Переведите в положительную форму. Проще сделать что́?

Я может совсем тупой, но как можно различно трактовать слово «изменение»?

Или в полную силу авторского права — как любое *производное* произведение. Тогда это будет лицензия сильного авторского лева. Хрестоматийный пример такой лицензии — GNU GPL.

Или сколь угодно ослабленно.

то будь любезен предоставить полученный результат по требованию

По чьему требованию?

И вообще, обратите внимание, что предоставление исходников по требованию — это исключительная редкость: я не могу назвать навскидку ни одной прикладной программы для ПЭВМ, распространили какой бы к нему прибегали. Что и понятно — какой дурак будет на такое подписываться — отвечать на любое требование.

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

Я тебя не понимаю.
Ладно, дурацкий вопрос в дурацком месте. Сам разберусь.

Слились со своей проприетарской агитацией? Ну и отлично.

Я тебя не понимаю.

Печаль-грусть. Что именно непонятно? Что такое производное произведение, и почему программа, скомпонованная из N частей производна от них ото всех?

Не хочу показаться хамом, но не думаю.

Что такое производное произведение, и почему программа, скомпонованная из N частей производна от них ото всех?

Я не хочу накладывать никакие ограничения на программу в целом. Меня интересует лишь код моей библиотеки.

Но и не помогаешь.

Ладно, давайте ближе к делу.

Вы не отвечаете на вопросы, что позволили бы отсечь предположение, что на самом деле вы желаете выбрать несвободную лицензию («раскрытие», «требования», вот это все).

Положим, что вы все-таки хотите выпустить свободную программу.

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

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

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

Если да, то GNU Lesser GPL (актуальной версии — третьей или более поздней).

Если нет, то Mozilla PL (опять же актуальной — второй — версии, отказаться от «или более поздней» она вам не даст).

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

CDDL и более старые версии лицензии Мозиллы для новых программ выбирать нельзя — они несовместимы с GNU GPL.

Если да, то GNU Lesser GPL

Разве LGPL можно статически линковать?

Разве [программу под GNU] LGPL можно статически линковать [с несвободными]?

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

Тогда о чём вообще этот разговор?
Делай с кодом что хочешь, но предоставляй доступ к изменениям. Так?
Но, хм. А что там с Qt? Есть версия под LGPL, но со статической линковкой там вроде бы нельзя. Как так?

Тогда о чём вообще этот разговор?

Не знаю. Это же вы затеяли. 🙂

Делай с кодом что хочешь, но предоставляй доступ к изменениям. Так?

Я не могу понять недвусмысленно то, что вы сейчас сказали. GNU Lesser GPL третьей версии не зря занимает столько строчек, сколько занимает — сократить ее до одной нельзя. (То же самое справедливо для любого документа, разумеется.)

Вам пересказать ее условия более подробно? А вы прочитать их в оригинале точно не хотите?

Есть версия под LGPL

Большей частью — да.

но со статической линковкой там вроде бы нельзя. Как так?

Никак. Это не так.

Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.

В качестве альтернативы разрешена статическая линковка если предоставлен исходный код или объектные файлы для линковки.

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

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

Ладно, не вредно. (Хотя оригиналы бы я вашем месте хотя бы попробовал почитать — лицензии ГНУ на удивление понятно для юридического документа написаны.)

Итак, допустим, вы проприетарщик и желаете поставлять вашу несвободную программу *вместе* с библиотекой под GNU LGPL — как бы они ни были скомпонованы, еще как-то об’единены или просто положены рядом.

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

1. Поставить получателей вашей программы в известность, о том, что у них есть такое право: то есть сообщить, что в нее включена такая-то свободная библиотека на условиях GNU Lesser GPL, приложить уведомление об авторских правах на нее, включая полный текст GNU LGPL (включая и GNU GPL, если v3).

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

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

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

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

Для любых предложений по сайту: [email protected]