Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 94
— Так, на Гитхабе 85% репозиториев вообще не содержат никаких указаний на лицензию
Но ведь это как раз плохо.
Но ведь это как раз плохо.
А можете подсказать какой-нибудь подробный материал про лицензии?
Желательно на русском (не критично) и так, чтобы чтобы не очень длинно.
Желательно на русском (не критично) и так, чтобы чтобы не очень длинно.
Возьмите это www.libertarium.ru/18586 и далее на Википедии смотрите статьи на русском по названиям. Типа вот ru.wikipedia.org/wiki/GNU_General_Public_License
www.tldrlegal.com/
На английском, но короче некуда.
На английском, но короче некуда.
Я это видел. Просто из вашего предложения выше получается, что это хорошо (хотя это не так), ну и оно несколько расходится с последним абзацем.
85% проектов на Гитхабе являются чем-то непонятным с парой (в лучшем случае) коммитов 3-летней давности, без какого-либо описания, и не представляющем никакого интереса.
Процент проектов, действительно воспринимаемых авторами как продукты с некоторым версионированием, возможностью улучшения со стороны сообщетства и т. д., без лицензии, вряд ли больше 10%.
Процент проектов, действительно воспринимаемых авторами как продукты с некоторым версионированием, возможностью улучшения со стороны сообщетства и т. д., без лицензии, вряд ли больше 10%.
Мне кажется надо оценивать еще по количеству кода. Всякие снипеты по-умолчанию будут иметь либеральные лицензии и еще хорошо было бы оценить по количеству affiliated. Понятно, что Google/Apple/… если и будут иметь open source code, то либарельную лицензию.
На самом деле маленькие заброшенные проекты (особенно те которые не имеют даже LICENSE) представляют малый интерес для open-source развития, в этом плане stackoverflow будет помощнее.
На самом деле маленькие заброшенные проекты (особенно те которые не имеют даже LICENSE) представляют малый интерес для open-source развития, в этом плане stackoverflow будет помощнее.
Apple купили ESP вместе с их CUPS шесть лет назад. Лицензия на CUPS — GPL/LGPL + исключения для Apple-систем, несмотря на то, что CUPS теперь Apple.
На самом деле это не совсем коректно. В смысле что вообще-то да, но в неясном случае применяется понятие обычаев делового оборота для данной отрасли/ситуации. Так что отсутствие указания на лицензию будет трактоваться как GPL скорее всего.
Видимо тут пояснение нужно. Начну с аналогии, совсем на пальцах: если вы, скажем, положили $100 на приступочку на улице и приложили записку «берите кто хотите», а кто-то эти деньги взял, то теоретически это кража. Записка не есть формальный договор дарения, может это вы просто ручку расписывали. Однако, естественно, в нормальной ситуации посадить тут никого не получится. Вполне естественно будет заключено что вы, кладя деньги в открытом месте да с такой запиской, прекрасно понмали что потом произойдет. Однако деньги придется вернуть.
Вот и тут также. Если вы выложили исходники на гитхаб, да с коментами, то даже при отсутствии прямого указания на лицензию будет вполне разумно заключить, что вы понимали прекрасно что произойдет. Другое дело — если вы с противополодной стороны прилавка и хотите взять чей-то код и сделать его существенной частью вашей последующей деятельности, а прямого указания на лицензию нет, то лучше поинтересоваться у автора.
Вот и тут также. Если вы выложили исходники на гитхаб, да с коментами, то даже при отсутствии прямого указания на лицензию будет вполне разумно заключить, что вы понимали прекрасно что произойдет. Другое дело — если вы с противополодной стороны прилавка и хотите взять чей-то код и сделать его существенной частью вашей последующей деятельности, а прямого указания на лицензию нет, то лучше поинтересоваться у автора.
Т.е, допустим если я просто в начале скрипта впишу комментарий:
// free for all
это не будет значить что я разрешаю делать с этим скриптом что угодно?
// free for all
это не будет значить что я разрешаю делать с этим скриптом что угодно?
Лучше напишите
Это юридический термин, в отличии от free которое то ли как пиво, то ли как слово.
// public domainЭто юридический термин, в отличии от free которое то ли как пиво, то ли как слово.
Вообще-то в России, если уж следовать букве закона — нет. В России это должен быть простой письменный договор. В штатах это будет достаточное основание что бы вы особо не могли песочить мозг тем, кто скрипт таки использует купившись на ваше free for all. То есть по сути тут просто открывается просто дверь для спекуляций на тему что именно вы имели ввиду этим вот «free for all». теоретически завтра вы же можете заявить что у вас просто привычка начинать код с этой фразы и данный текст в данном месте не явлеется никоим образом указанием на ваше отношение к вопросу о собственности. Ну а обороняющаяся сторона, естественно, заявит что вы не могли не понимать как люди будут трактовать подобную строку.
Нет, конечно. Юристы таких простых слов не понимают. Надо писать что-нибудь вроде: «На этот скрипт наложено неисключительное и неотчуждаемое право использования третьими лицами в коммерческих и некоммерческих целях без необходимости осуществления перевода денежных средств автору или его полномочным представителям…» И так далее, десятка на три страниц. Тогда всё будет в порядке.
А что с
благословлением
в исходниках SQLite?/*
** 2005 July 8
**
** The author disclaims copyright to this source code. In place of
** a legal notice, here is a blessing:
**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
**
*************************************************************************
** 2005 July 8
**
** The author disclaims copyright to this source code. In place of
** a legal notice, here is a blessing:
**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
**
*************************************************************************
Если бы он вместо may использовал should или must, это бы автоматически делало лицензию несвободной, как это произошло с каким-то кодом для разбора JSON.
Обьясните подробнее пожалуйста, про вопросы may, should и must.
Конкретно этот случай рассмотрен в <lists.debian.org/debian-legal/2010/03/msg00065.html>, <bugzilla.redhat.com/show_bug.cgi?id=455507> и ещё много где. А вообще, разница между MAY, SHOULD, MUST объясняется в начале практически любого IETF RFC, а кроме того — в начале многих лицензионных соглашений.
Скорее как MIT/BSD/Apache, а то и вообще public domain, если обычаи делового оборота применять. С другой стороны, закон явно указывает на необходимость лицензии для использования чужого софта и можно ли тут вообще на обычаи ссылаться неяясно.
На обычаи тут можно ссылаться не в качестве замены лицензии, а в качестве доказательства ее фактического существования. На рынке фактически сложилась вот такая сиутация, что уведомление о лицензии делается в таких ситуациях вот так. Таковы сформировавшиеся обычаи. Собственно доказательством тут будет банальный опрос всех тех на гитхабе, кто не описал лицензию. Если 99% из них говорят «открыто», а мы все понимаем что так оно и будет, то как бЭ вот, доказано.
Правда в некоторых юрисдикиях закон накладывает ограничения на форму договора. Но в большинстве — нет. Там где налагает — действительно, обычаи приплести не получится.
Правда в некоторых юрисдикиях закон накладывает ограничения на форму договора. Но в большинстве — нет. Там где налагает — действительно, обычаи приплести не получится.
У нас. большинства хаброюзеров. юрисдикция российская. а она налагает хоть какую-то лицензию. А. главное. зная нашу правоприменительную практику. определения «открытая» скорее всего не хватит. нужно будет доказывать. что в обычаях состоит конкретно MIT. или конкретно GPL. что. имхо, несколько проблематично
Не знаю, правильно мыслю или ошибаюсь, но я стараюсь выбирать либеральные лицензии для того, чтобы самому потом иметь право использовать свой код в каких либо коммерческих проектах. Или я не прав?
Ну свой то код, если он полностью свой, вы можете как вам угодно использовать :) Что с лицензией, что без таковой.
Не правы. Самому себе вам просто лицензия не нужна (если не передавали исключительных прав). Но вот если вы хотите использовать пулл реквесты сообщества в ваш открытый код в своем закрытом продукте, то правильный выбор.
А я предпочитаю LGPL.
С одной стороны код можно линковать с коммерческими проектами, с другой стороны все улучшения в моём коде будут обязаны вернуть в проект. Да, придётся весь код тащить в отдельную разделяемую библиотеку, просто взять и скопировать его к себе лицензия не позволит, но это не большая цена за то, что мой проект будет улучшаться по мере использования другими людьми где бы то ни было.
Проблема пермиссивных лицензий в том, что коммерческие компании не любят возвращать улучшения назад, а данный тип лицензий позволяет им это не делать с чистой совестью.
Другая сторона медали в том, что многие компании, имея выбор между двумя аналогичными по функциональности проектами под LGPL и пермиссивной лицензией, с вероятностью стремящейся к 100% выберут вторую, тут уж ничего не поделать.
С одной стороны код можно линковать с коммерческими проектами, с другой стороны все улучшения в моём коде будут обязаны вернуть в проект. Да, придётся весь код тащить в отдельную разделяемую библиотеку, просто взять и скопировать его к себе лицензия не позволит, но это не большая цена за то, что мой проект будет улучшаться по мере использования другими людьми где бы то ни было.
Проблема пермиссивных лицензий в том, что коммерческие компании не любят возвращать улучшения назад, а данный тип лицензий позволяет им это не делать с чистой совестью.
Другая сторона медали в том, что многие компании, имея выбор между двумя аналогичными по функциональности проектами под LGPL и пермиссивной лицензией, с вероятностью стремящейся к 100% выберут вторую, тут уж ничего не поделать.
компании не любят возвращать улучшения назадПочему вы так думаете? В компаниях работают такие же люди, как и те что делают библиотеки/проекты. То есть, это одни и те же люди. Поэтому если где-то в компании нашли и поправили баг в открытом проекте, не вижу причин почему им будет лень оформить пулл-реквест или хотя бы завести тикет. Если же они кардинально переработали проект, или интегрировали его в свою систему, возвращать «новый» проект вряд ли имеет смысл, разве что опубликовать форк, но с этим заморачиваться как правило очень лень, причем без разницы, какая там была исходная лицензия.
Кстати иногда наблюдаю такую ситуацию что авторы проектов очень неохотно или вообще никогда не принимают пулл-реквестов, потому что либо их не устраивает качество или стиль кода, либо действует принцип «Not Invented Here», уж не знаю. Поэтому даже если исправил проблему лучше завести тикет, чтобы автор сам ее тоже решил, потому что пулл-реквест он не примет.
Делают всё же программисты, а политику распространения определяют менеджеры. Мне вот явно запрещено даже тикеты создавать, которые я сам решил — типа у нас будет конкурентное преимущество.
Хм, даже не догадывался о существовании такой практики.
Опять же, в таком случае у программистов не будет моральных страданий по поводу укрывания копилефтного кода, потому что им явно запретили его публиковать. Lampus же писал что LGPL в лучшем случае воздействует на совесть программистов, потому что в принципе понятно что копилефт нарушается сплошь и рядом и особой проблемы с этим нет.
А как же новые версии этого софта, будете каждый раз мерджить с вашим кодом?
у гитхаба с битбакетом и прочими подобными ресурсами есть ещё проблема — это засилье форков. Хорошо, когда первоначальный проект поддерживается и реквесты принимаются. А вот если он подзаброшен или полузакрыт, то начинают плодится форки, которые каждый сам по себе решают небольшую проблему, и попробуй ещё все свести. А сведя нужно свой форк делать :)
Какой-то бред про Perl. Авто оригинала пишет:
Действительно, большинство Perl проектов так или иначе находятся на CPAN, и там преобладает Perl license, т.е. Artistic/GPL dual licensed.
И какой логикой руководствовался автор считая эту лицензию копилефтной?? Либой может использовать этот код под Artistic license, т.е. менее строгой.
For the relatively small number of multi-licensed projects (765 total out of close to 60,000), I preferred the more copyleft variant — Perl stuff is generally Artistic/GPL dual licensed.
Действительно, большинство Perl проектов так или иначе находятся на CPAN, и там преобладает Perl license, т.е. Artistic/GPL dual licensed.
И какой логикой руководствовался автор считая эту лицензию копилефтной?? Либой может использовать этот код под Artistic license, т.е. менее строгой.
Наличием в исходниках строки GPL, наверное.
Итак, есть проект XYZ, под лицензией Artistic/GPL
Интересует его «копилефтность».
Три случая:
1. Кто-то берёт исходники, форкает, линкует или модифицирует и хочет оставить изменения себе. Да, у него это получится, т.к. он решил использовать
Artistic. Ни какой копилефтности.
2. Кто-то берёт исходники, форкает, меняет одну строчку кода, меняет лицензию на GPL.
Любому, кто захочет обойти такую копилефтность, достаточно найти оригинал, до форка.
3. Кто-то берёт исходники, форкает, меняет лицензию на GPL. Делает большую работу в исходниках, улучшая продукт.
Теперь продукт действительно под копилейт лицензией.
Таким образом, проекты под Artistic/GPL можно модифицировать чтобы они были копилефтные, вложив большой труд.
ИМХО Это не корректно отображать на графике как копилефтность, копилефтными стоит отображать проекты типа (3) — уже форкнутые, где уже сменили
лицензию и внесли серьёзные изменения, имхо таких на практике вообще единицы.
Лучше вообще не отображать на графике эти данные, либо сделать отдельных график для двойных лицензий, чем показывать заведомо ложные данные.
Интересует его «копилефтность».
Три случая:
1. Кто-то берёт исходники, форкает, линкует или модифицирует и хочет оставить изменения себе. Да, у него это получится, т.к. он решил использовать
Artistic. Ни какой копилефтности.
2. Кто-то берёт исходники, форкает, меняет одну строчку кода, меняет лицензию на GPL.
Любому, кто захочет обойти такую копилефтность, достаточно найти оригинал, до форка.
3. Кто-то берёт исходники, форкает, меняет лицензию на GPL. Делает большую работу в исходниках, улучшая продукт.
Теперь продукт действительно под копилейт лицензией.
Таким образом, проекты под Artistic/GPL можно модифицировать чтобы они были копилефтные, вложив большой труд.
ИМХО Это не корректно отображать на графике как копилефтность, копилефтными стоит отображать проекты типа (3) — уже форкнутые, где уже сменили
лицензию и внесли серьёзные изменения, имхо таких на практике вообще единицы.
Лучше вообще не отображать на графике эти данные, либо сделать отдельных график для двойных лицензий, чем показывать заведомо ложные данные.
Смысла использовать GPL нет. Если кто-то плохой захочет использовать и не возвращать код — лицензия не будет ему помехой. За всё время существования лицензии было по пальцам одной руки счесть успешных судебных разборок при версии GPLv2, в двух странах на весь мир. GPLv3 и AGPL в суде свою силу не доказали ни разу. И обращу внимание, что это в том числе Штатах, где заваливать конкурента исками по каждому чиху — это неотъемлемая часть ебизнеса. Мнение FSF по поводу dynamic vs static линковки библиотек в суде не тоже обосновано ни разу, причём Линус имеет иное мнение, и я с ним согласен. А если следовать рекомендациям FSF, то возникают обходные пути типа загрузки библиотеки в соседнем фиктивном процессе и т.п.
Если же человек хочет поделиться наработками, то лицензия не имеет значения. Я лучше один раз сделаю пулл-реквест, чем буду на протяжении лет мержить все изменения. Жадным быть невыгодно.
GPL — это пережиток прошлого. Лицензия позволила популяризовать опен-сорс среди коммерческих компаний, и за это ей спасибо. GPL отчасти спасал от страхов, что конкурент возьмёт сорцы и сделает свой продукт лучше (по факту от этого GPL не защищал, но видимость создавал). Но сейчас время GPL прошло. Вера в опен-сорс есть, и ему не нужна поддержка лицензией, которая мешает нормально комбинировать сорцы разных лицензий, которая заставляет делать финты ушами при использовании в коммерческих продуктах с закрытыми исходниками, которая пролезла в сравнения всех лицензий со своим флажком на совместимость и т.п.
Если же человек хочет поделиться наработками, то лицензия не имеет значения. Я лучше один раз сделаю пулл-реквест, чем буду на протяжении лет мержить все изменения. Жадным быть невыгодно.
GPL — это пережиток прошлого. Лицензия позволила популяризовать опен-сорс среди коммерческих компаний, и за это ей спасибо. GPL отчасти спасал от страхов, что конкурент возьмёт сорцы и сделает свой продукт лучше (по факту от этого GPL не защищал, но видимость создавал). Но сейчас время GPL прошло. Вера в опен-сорс есть, и ему не нужна поддержка лицензией, которая мешает нормально комбинировать сорцы разных лицензий, которая заставляет делать финты ушами при использовании в коммерческих продуктах с закрытыми исходниками, которая пролезла в сравнения всех лицензий со своим флажком на совместимость и т.п.
Я лучше один раз сделаю пулл-реквест, чем буду на протяжении лет мержить все изменения. Жадным быть невыгодно.
А если за пулл-реквесты увольняют, а за мержи деньги платят?
Откуда такая статистикеа что лицензия не будет помехой? По судебным разборкам? Это не правильно, не учитываются случаи когда кто-то хороший добравольно следовал правилам лицензии. Может этих случаев миллионы.
У меня на работе, купили коммерческую лицензию программы, которая была под двойной лицензией GPL (и GPL не устраивало). Так же являюсь автором программы GPLv3, иногда люди пишут, спрашивают подробности при лиценизию, предлагают двойное лицензирование.
У меня на работе, купили коммерческую лицензию программы, которая была под двойной лицензией GPL (и GPL не устраивало). Так же являюсь автором программы GPLv3, иногда люди пишут, спрашивают подробности при лиценизию, предлагают двойное лицензирование.
Что, по-вашему, есть «свобода»?
По мне так лучше уж GPL, чем MS EULA.
По мне так лучше уж GPL, чем MS EULA.
Просто нужно различать свободу софта и свободу разработчика и не смешивать (и уж тем более не путать) эти понятия.
GPL во главу угла ставит свободу софта, накладывая тем самым ограничения на разработчиков. Более либеральные лицензии наоборот, дают свободу разработчикам, допуская изменения в свободе софта.
GPL во главу угла ставит свободу софта, накладывая тем самым ограничения на разработчиков. Более либеральные лицензии наоборот, дают свободу разработчикам, допуская изменения в свободе софта.
Спасибо за статью, сходил на github и добавил MIT лицензию.
Использую MIT. Причины:
1. Нет ни строчки о патентах. А патенты — дело мутное. Формально, в наших странах software patents не действуют, но при этом мы признаем патенты, выданные в других странах — членах WPO. В том же GPL, Apache и прочих есть пункты о патентах, сводящиеся к тому, что мои пользователи защищены, и если меня судят, то я отнимаю право на свои патенты у атакующего и могу использовать их против него. Но во-первых, у меня нет патентов и скорее я по незнанию нарушу чей-то патент, чем придумаю и запатентую что-то новое. А во-вторых, судиться с кем-то у меня нет желания и возможности. Проще о патентах вообще не говорить.
Кстати, если бы я выпускал опенсорс продукт как компания и зарабатывал на нем, я бы предпочел Apache, чтобы обеспечить своим клиентам дополнительную защиту. С другой стороны, Google для своего WebM сделал вообще финт ушами: отдельно лицензия BSD, где нет ни слова о патентах, и отдельно — патентный грант. Я несколько часов убил, пытаясь понять, чем такой «бутерброд» отличается от Apache лицензии, но так и не въехал. Так что ну их нафиг, эти патенты.
2. Я сам пишу закрытый софт и считаю, что другие тоже должны иметь на это право. Поэтому не копилефт. Возможно, я использовал бы «файловую» лицензию типа MPL 2.0, но не хочу добавлять геморроя тем, кто будет использовать мой код в своих проектах. Проще сказать «пулл-реквесты принимаются с благодарностью». Кто-то пришлет мне баг-репорт, кто-то забъет и поправит у себя в своем форке. Но мне не кажется, что использование MPL или LGPL заставит кого-то из «забивших» все-таки прислать мне патч или багрепорт.
3. Не BSD, т.к. их миллион разных видов, и между ними большая путаница. MIT с вероятностью 99% означает одно и тоже (нет гарантий, все даром, укажите меня в титрах).
4. С GPL или LGPL есть непонятки с тем, как она работает для некомпилируемых языков. Для Java, например, есть отдельный их вариант, а вот как ее интерпретировать для JavaScript, вообще непонятно. Скажем, вставил я на клиенте Ext JS, что мне теперь нужно обнародовать? Только те JS- файлы, где я использую Ext? Только тот код, который загружается на страницах, где есть Ext? Как быть с фреймами? Может, всю клиентскую часть приложения открыть? Или вообще все приложение целиком? Влияет ли возможность использования приложения в оффлайне на это? Т.е. я использую HTTP для дистрибуции моего приложения на JS, а сервер — это просто сервис данных, и частью приложения он не является :) Мутно в общем. И на сервере та же история.
5. Есть Boost License и WTFPL — еще более разрешительные (можно не указывать автора в титрах), но мне приятно знать о том, что кто-то моим софтом пользуется.
6. Бонус: раз я не беспокоюсь о патентах, и моя лицензия совместима практически со всеми, это означает, что мне не нужно заморачивасться с Contributions License Agreement, чтобы принимать патчи и пул-реквесты.
1. Нет ни строчки о патентах. А патенты — дело мутное. Формально, в наших странах software patents не действуют, но при этом мы признаем патенты, выданные в других странах — членах WPO. В том же GPL, Apache и прочих есть пункты о патентах, сводящиеся к тому, что мои пользователи защищены, и если меня судят, то я отнимаю право на свои патенты у атакующего и могу использовать их против него. Но во-первых, у меня нет патентов и скорее я по незнанию нарушу чей-то патент, чем придумаю и запатентую что-то новое. А во-вторых, судиться с кем-то у меня нет желания и возможности. Проще о патентах вообще не говорить.
Кстати, если бы я выпускал опенсорс продукт как компания и зарабатывал на нем, я бы предпочел Apache, чтобы обеспечить своим клиентам дополнительную защиту. С другой стороны, Google для своего WebM сделал вообще финт ушами: отдельно лицензия BSD, где нет ни слова о патентах, и отдельно — патентный грант. Я несколько часов убил, пытаясь понять, чем такой «бутерброд» отличается от Apache лицензии, но так и не въехал. Так что ну их нафиг, эти патенты.
2. Я сам пишу закрытый софт и считаю, что другие тоже должны иметь на это право. Поэтому не копилефт. Возможно, я использовал бы «файловую» лицензию типа MPL 2.0, но не хочу добавлять геморроя тем, кто будет использовать мой код в своих проектах. Проще сказать «пулл-реквесты принимаются с благодарностью». Кто-то пришлет мне баг-репорт, кто-то забъет и поправит у себя в своем форке. Но мне не кажется, что использование MPL или LGPL заставит кого-то из «забивших» все-таки прислать мне патч или багрепорт.
3. Не BSD, т.к. их миллион разных видов, и между ними большая путаница. MIT с вероятностью 99% означает одно и тоже (нет гарантий, все даром, укажите меня в титрах).
4. С GPL или LGPL есть непонятки с тем, как она работает для некомпилируемых языков. Для Java, например, есть отдельный их вариант, а вот как ее интерпретировать для JavaScript, вообще непонятно. Скажем, вставил я на клиенте Ext JS, что мне теперь нужно обнародовать? Только те JS- файлы, где я использую Ext? Только тот код, который загружается на страницах, где есть Ext? Как быть с фреймами? Может, всю клиентскую часть приложения открыть? Или вообще все приложение целиком? Влияет ли возможность использования приложения в оффлайне на это? Т.е. я использую HTTP для дистрибуции моего приложения на JS, а сервер — это просто сервис данных, и частью приложения он не является :) Мутно в общем. И на сервере та же история.
5. Есть Boost License и WTFPL — еще более разрешительные (можно не указывать автора в титрах), но мне приятно знать о том, что кто-то моим софтом пользуется.
6. Бонус: раз я не беспокоюсь о патентах, и моя лицензия совместима практически со всеми, это означает, что мне не нужно заморачивасться с Contributions License Agreement, чтобы принимать патчи и пул-реквесты.
а вот как ее интерпретировать для JavaScript, вообще непонятно.
Эх, не удачный пример, javascript — клиентский язык — весь сайт придётся под GPL выкладывать. поэтому javascript обычно MIT
Но это совершенно не касается других некомпилируемых языков (а именно серверных).
Если у меня в компании GPL код на сотне серверов, но никаким третьим сторонам я его не отдаю, то я не являюсь его распространителем, и следовательно, релизить в опенсорс ни свои наработки, ни изменения в GPL-коде не должен. Таким образом, например, в Google используются свои версии Linux, компоненты сетевого стека и бессчетное число форков разных OpenSource-проектов,
AGPL по идее должен был решить эту проблему, но он не распространен из-за своей несовместимости с обычным GPL.
А вот если я серверный код распространяю*, то тоже непонятно, как быть. Допустим, у меня веб-приложение на Питоне, и я использую GPL-код на сервере. И допустим, я организовал свое приложение в виде нескольких изолированных модулей, которые хоть и крутятся на одном порту, но меж собой общаются только по HTTP. Мне обнародовать все приложение? А почему не только те модули, которые используюут GPL-код? А если я все компоненты разнесу по разным серверам, что-то изменится? А если некоторые модули будут общаться не по HTTP, а по какому-то другому протоколу — через те же системные вызовы, например?
*Например, я разработчик и пишу серверный софт для своей компании — это не считается распространением. А вот если я — внешний контрактор, то уже спорно.
AGPL по идее должен был решить эту проблему, но он не распространен из-за своей несовместимости с обычным GPL.
А вот если я серверный код распространяю*, то тоже непонятно, как быть. Допустим, у меня веб-приложение на Питоне, и я использую GPL-код на сервере. И допустим, я организовал свое приложение в виде нескольких изолированных модулей, которые хоть и крутятся на одном порту, но меж собой общаются только по HTTP. Мне обнародовать все приложение? А почему не только те модули, которые используюут GPL-код? А если я все компоненты разнесу по разным серверам, что-то изменится? А если некоторые модули будут общаться не по HTTP, а по какому-то другому протоколу — через те же системные вызовы, например?
*Например, я разработчик и пишу серверный софт для своей компании — это не считается распространением. А вот если я — внешний контрактор, то уже спорно.
Угу, с внешним вообще засада.
Если у меня в компании GPL код на сотне серверов, но никаким третьим сторонам я его не отдаю, то я не являюсь его распространителем, и следовательно, релизить в опенсорс ни свои наработки, ни изменения в GPL-коде не должен.
Если используете чужой javascript код под GPL, то распространяете и должны выложить под GPL или весь ваш javascript (без обфускации) или весь сайт (точно не могу сказать).
Вот-вот, и никто не может сказать. И сколько людей, столько и мнений со своими аргументами. Нормального FAQ от самих FSF по GPL нет, есть какой-то 20-илетней давности, который вообще не отвечает современным сценариям. Спрашиввается, как можно ожидать, что люди будут продолжать использовать вашу лицензию, если она (или информация вокруг нее) не отвечает нуждам разработчиков?
Вы ещё у них попросите у них трактовки по российским законам.
Точно нельзя сказать, потому что речь идёт о том на сколько сильно javascript, html и серверная сторона взаимодействуют, и может ли сайт работать без javascript, это надо смотреть сам сайт, а не давать заключения на основании того как он технически слинкован.
А в чём проблема использовать GPL, предполагая худший для Вас сценарий (т.е. не использовать вообще javascript GPL)? Обычно javascript библиотеки либо под MIT, либо под двойной лицензией, одна из которых коммерческая, специально для того чтобы их могли либо купить, либо свободно использовать в open source GPL проекте — такова воля автора библиотеки.
А в чём проблема использовать GPL, предполагая худший для Вас сценарий (т.е. не использовать вообще javascript GPL)? Обычно javascript библиотеки либо под MIT, либо под двойной лицензией, одна из которых коммерческая, специально для того чтобы их могли либо купить, либо свободно использовать в open source GPL проекте — такова воля автора библиотеки.
Я не говорил про JS, просто привел его в качестве примера. По факту я могу с уверенностью трактовать условия GPL только для языков, производящих компилируемые артефаты: C, C++, Haskell, Fortran или Ada, например. Для языков, подразумевающих распространение в виде исходников — Python, Perl, JavaScript, Ruby и т.д. — я не могу быть до конца уверенным. С другой стороны, с CDDL, MPL, APL, BSD или MIT у меня не возникает никаких сомнений в плане использования. Поэтому я считаю, что эта неопределенность — недостаток самой GPL. Причем, у авторов GPL была возможность этот недостаток исправить, когда разрабатывалась третья версия.
По российским законам публикация и распространение — разные вещи.
У меня на гихабе зоопарк: New BSD 3-clause (почти все форки), Simplified BSD 2-clause (свои либы), Public Domain (фреймворк сборник велосипедов, забавы-эксперименты). Надо будет для коллекции MIT к чему-нибудь присобачить. :) По сути разницы между ними нет: укажи автора и делай что хочешь.
Ни разу не видел вживую BSD 4-clause. Практически всегда под BSD подразумевается New BSD 3-clause.
3. Не BSD, т.к. их миллион разных видов, и между ними большая путаница. MIT с вероятностью 99% означает одно и тоже (нет гарантий, все даром, укажите меня в титрах).
Ни разу не видел вживую BSD 4-clause. Практически всегда под BSD подразумевается New BSD 3-clause.
Еще одна попытка бизнеса «промыть мозги» молодым программистам.
Линукс — успешный продукт под лицезией GPL. Как еще можно успешнее прорекламировать лицензию.
Если вы не поставили лицензию на свой код вы все равно остаетесь его автором и имеете все права на свое произвидение. Это очень не нравиться бизннесмену, который имеет соответсвующие «риски» с таким кодом. Ему лучше убедить Вас в том что кругом все распостраниется под MIT-лицензией. Если вы поставили MIT вы уже не сможете попросить открыть код, написанный на основе вашей библиотеки.
Линукс — успешный продукт под лицезией GPL. Как еще можно успешнее прорекламировать лицензию.
Если вы не поставили лицензию на свой код вы все равно остаетесь его автором и имеете все права на свое произвидение. Это очень не нравиться бизннесмену, который имеет соответсвующие «риски» с таким кодом. Ему лучше убедить Вас в том что кругом все распостраниется под MIT-лицензией. Если вы поставили MIT вы уже не сможете попросить открыть код, написанный на основе вашей библиотеки.
>Если вы поставили MIT вы уже не сможете попросить открыть код, написанный на основе вашей библиотеки.
И что несварение случится?
И что несварение случится?
Да, в GPL вы можете потребовать исходники, если кто-то распространяет программу, использующую ваш код. Но когда вы получите этот кот, вы не сможете использовать его в коммерческих целях, т.к. исходники таких проектов придется открыть. Даже вашу собственную библиотеку вы не сможете закрыть без согласия всех контрибьюторов. Очень хорошо сказали выше: GPL — это свобода софта, MIT/BSD — свобода разработчика. Лично я раньше тоже склонялся к GPL, потом разобрался что к чему и открываю код только по лицензии BSD.
> вы не сможете использовать его в коммерческих целях, т.к. исходники таких проектов придется открыть
Это почему ещё? Linux используется в коммерческих целях, код открыт. Коммерческий продукт != закрытый код, и наоборот, открытый код != некоммерческий продукт, поймите уже.
Это почему ещё? Linux используется в коммерческих целях, код открыт. Коммерческий продукт != закрытый код, и наоборот, открытый код != некоммерческий продукт, поймите уже.
Да, теоретически закрытый код != коммерческий проект. Но Linux скорее исключение, большинство программ никто бы не покупал, если бы их исходники были доступны. Но отдавая код в свободное сообщество я хочу пользоваться своим кодов как хочу, даже если кто-нибудь что-нибудь в нем улучшит.
Есть еще модель двойного лицензирования — GPL+коммерческая лицензия (как, например, в MatrixSSL, PolarSSL). Я как-то пробовал сделать контрибуцию в один такой проект. Так мой код так изменили (это мое предположение), чтобы я никоим образом не смог доказать, что идея этих нескольких строчек кода — моя, т.к. они бы не смогли распространять код по «Коммерческой» лицензии (для закрытых проектов).
Линус Торвальдс придумал GPL для того, чтобы каждый, кто улучшит код и распространяет результат возвращал улучшения (производные работы) в сообщество. Это разумно и я полностью с этим согласен и поддерживаю. Но современный GPL (начиная с 2) требует открытия кода всей программы, если я использую крохотную GPL-библиотеку или хотя бы маленький кусочек GPL-кода. Даже если я использую GPL-ную DLL. Это очень широкая формулировка термина «производная работа». А для Web этот термин вообще не ясен до конца.
И еще один нюанс GPL, который я не могу принять. GPL диктует не только то, что я могу или не могу делать с самим GPL-ным кодом, а накладывает обязательства на мой собственный код, который автор GPL-ного кода не писал. Таким образом я как бы лишаюсь права поступать со своим кодом так, как захочу (не могу закрыть), если в нем есть кусочек GPL. Я не юрист, но при обсуждении GPL на форумах часто возникает вопрос о том, возможно ли вообще законодательно в лицензии на один код накладывать ограничение на другой.
Но не поймите меня неверно, я с удовольствием по возможности вношу контрибуции в проекты на GPL. Но если я делюсь чем-то своим, делаю это под BSD.
Есть еще модель двойного лицензирования — GPL+коммерческая лицензия (как, например, в MatrixSSL, PolarSSL). Я как-то пробовал сделать контрибуцию в один такой проект. Так мой код так изменили (это мое предположение), чтобы я никоим образом не смог доказать, что идея этих нескольких строчек кода — моя, т.к. они бы не смогли распространять код по «Коммерческой» лицензии (для закрытых проектов).
Линус Торвальдс придумал GPL для того, чтобы каждый, кто улучшит код и распространяет результат возвращал улучшения (производные работы) в сообщество. Это разумно и я полностью с этим согласен и поддерживаю. Но современный GPL (начиная с 2) требует открытия кода всей программы, если я использую крохотную GPL-библиотеку или хотя бы маленький кусочек GPL-кода. Даже если я использую GPL-ную DLL. Это очень широкая формулировка термина «производная работа». А для Web этот термин вообще не ясен до конца.
И еще один нюанс GPL, который я не могу принять. GPL диктует не только то, что я могу или не могу делать с самим GPL-ным кодом, а накладывает обязательства на мой собственный код, который автор GPL-ного кода не писал. Таким образом я как бы лишаюсь права поступать со своим кодом так, как захочу (не могу закрыть), если в нем есть кусочек GPL. Я не юрист, но при обсуждении GPL на форумах часто возникает вопрос о том, возможно ли вообще законодательно в лицензии на один код накладывать ограничение на другой.
Но не поймите меня неверно, я с удовольствием по возможности вношу контрибуции в проекты на GPL. Но если я делюсь чем-то своим, делаю это под BSD.
Да я понимаю вас верно. Вот вы понимаете неверно.
1. Линус Торвальдс не создавал GPL. Слышали про Ричарда Столлмана?
2. GPL не ограничивает вас в том, что вы будете делать со своим собственным кодом. Вы можете его закрыть. Сменить лицензию уже выпущенного кода вы не сможете и никто не сможет (и это не имеет смысла — код-то уже лицензирован под GPL, могли образоваться форки по GPL, автор которых уже не вы и контроля за ними у вас нет), но вот выпустить новую версию под другой лицензией вы можете запросто, и можете не распространять модификации собственного кода, который вы когда-то выпустили под GPL. Так можете сделать только вы — форки будут обязаны выпускаться под GPL до тех пор, пока в них осталась хоть строчка вашего GPL-ного кода.
Если в вашем приложении есть код контрибьюторов, который тоже лицензирован под GPL, вы обязаны получить их согласие. Это может быть любой способ: например, вы можете купить их код — он станет вашим, и вы сможете его закрыть в новой версии (для которой вы укажете другую лицензию). GPL — это вполне коммерческая лицензия, вовсе не «теоретически».
1. Линус Торвальдс не создавал GPL. Слышали про Ричарда Столлмана?
2. GPL не ограничивает вас в том, что вы будете делать со своим собственным кодом. Вы можете его закрыть. Сменить лицензию уже выпущенного кода вы не сможете и никто не сможет (и это не имеет смысла — код-то уже лицензирован под GPL, могли образоваться форки по GPL, автор которых уже не вы и контроля за ними у вас нет), но вот выпустить новую версию под другой лицензией вы можете запросто, и можете не распространять модификации собственного кода, который вы когда-то выпустили под GPL. Так можете сделать только вы — форки будут обязаны выпускаться под GPL до тех пор, пока в них осталась хоть строчка вашего GPL-ного кода.
Если в вашем приложении есть код контрибьюторов, который тоже лицензирован под GPL, вы обязаны получить их согласие. Это может быть любой способ: например, вы можете купить их код — он станет вашим, и вы сможете его закрыть в новой версии (для которой вы укажете другую лицензию). GPL — это вполне коммерческая лицензия, вовсе не «теоретически».
3. Вирусность GPL имеет прямой смысл: если вы пользуетесь тем, что произвело сообщество, обязаны чем-то сообществу отплатить. Любая работа должна быть оплачена, бесплатного ничего нет — в том числе и работа, выпущенная под GPL не бесплатна.
Таким образом появляется возможность исключить паразитирование на сообществе. А вот более «либеральные» лицензии так не делают — и это плохо, потому, что именно благодаря им паразитирование процветает. Об этом и был комментарий выше: корпорациям-паразитам GPL очень невыгодна, они не хотят делиться, «всё мне, мне и мне», и поэтому всеми способами агитируют людей выпускать код под другими лицензиями — в том числе и ложной статистикой.
Таким образом появляется возможность исключить паразитирование на сообществе. А вот более «либеральные» лицензии так не делают — и это плохо, потому, что именно благодаря им паразитирование процветает. Об этом и был комментарий выше: корпорациям-паразитам GPL очень невыгодна, они не хотят делиться, «всё мне, мне и мне», и поэтому всеми способами агитируют людей выпускать код под другими лицензиями — в том числе и ложной статистикой.
GPL вроде как не регулирует вопрос использования по большому счёту. Можно держать свой форк на своем компе/сервере и его не открывать. Проблемы начинаются когда распространяешь.
корпорациям-паразитам GPL очень невыгодна
Вот пример компании-паразита, которой выгодна GPL, и за что её ненавидят: en.wikipedia.org/wiki/ExtJS#License_history
Под паразитами я имею ввиду тех, кто берёт открытый код и не отдаёт сообществу ничего взамен. Например, Microtik.
А Sencha — определённо не паразиты.
А Sencha — определённо не паразиты.
Sencha взяла код, который был пригоден для всех, и объявила его пригодным только для опен-сорса. Писали изначально код все, а не только идеологические GPL-опен-сорсники — их послали на хутор бабочек ловить. В моей системе ценностей это — свинство, а GPL — средство его достижения.
Microtik — нарушитель GPL, это тоже свинство, разумеется.
Я к тому, что свинство компании ортогонально лицензии на их ПО.
Microtik — нарушитель GPL, это тоже свинство, разумеется.
Я к тому, что свинство компании ортогонально лицензии на их ПО.
Я всё-таки «паразитов» определил вполне конкретно. Под это определение свинство со сменой лицензии в ExtJS кода не попадает.
Кстати говоря, именно в подобном же свинстве SCO упрекает IBM и прочих, мол, взяли наш код и раздали в составе Linux (под GPL). И вопрос стоит там сейчас в основном в том, действительно ли код был «наш», в смысле, принадлежал SCO.
Кстати говоря, именно в подобном же свинстве SCO упрекает IBM и прочих, мол, взяли наш код и раздали в составе Linux (под GPL). И вопрос стоит там сейчас в основном в том, действительно ли код был «наш», в смысле, принадлежал SCO.
дополнение к п. 2:… форки обязаны выпускать под GPL либо пока там есть чужой (не их, например, ваш) GPL-код, либо пока они не получат ваше согласие на смену лицензии. И вы вполне можете за это попросить у них денег.
А это ведь еще до абсурда доводят. Вот у нас есть стартап который на всем этом счастье наживается. А еще одна фирма боится использовать LGPL third parties потому что самый понтовый ее адвокат сказал что могут быть проблемы с этой лицензией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сообщество Open Source склоняется в сторону более либеральных лицензий