Выбор лицензии для проектов с открытым исходным кодом

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

Вот что я хотел сделать:

Для полных заявлений :

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

Для библиотек (компонентов, плагинов, ...):

• могут быть включены в коммерческие проекты без изменений
• любая модификация библиотеки / компонента должна быть с открытым исходным кодом (предоставлена ​​обратно) - остальная часть проекта, коммерческая или нет, не затрагивается

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

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

Это подводит меня к моему вопросу (ам): является ли LGPL логичным выбором для библиотек с открытым исходным кодом, компонентов, плагинов и т. Д.? Есть ли лучшая альтернатива? Является ли GPL хорошим выбором для моих приложений или есть что-то лучше?

Обновить:

Для тех, кто заинтересован в моем окончательном решении, я решил выпустить свои библиотеки по мультилицензионной схеме, MPL, LGPL и GPL. Это позволяет практически каждому использовать мой код без каких-либо обязательств, если только он не модифицирует его в соответствии с MPL, и в этом случае его необходимо будет вернуть обратно.

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

Мне кажется, что GPL и LGPL - это то, что вы хотите для своих проектов.

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

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

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

Я не знаю, нужна ли вам лицензия Creative Commons Attribution Non-Commercial No Derivatives (единственное упомянутое вами ограничение - коммерческое использование ), но если нет, вам может понадобиться лицензия, подготовленная для вас адвокатом, которая содержит язык, на котором вы хотите обладать правами обладателя лицензии.

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

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

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

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

(это особенно актуально для библиотеки, поскольку библиотека под GPL может использоваться только в программном обеспечении GPL).

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

То, можете ли вы подать заявку на MPL или только GPL, зависит от одного критического различия:

«Права по настоящему Соглашению» включают в себя право, предоставляемое получателям, на связывание «Покрытого кода» MPL с частным не-MPL кодом для формирования «Большей работы» (MPL 3.7 Larger Works). GPL не дает получателям такого права. Следовательно, получатель не может изменить условия лицензирования для применения GPL вместо MPL.

Смотрите это .

Для вас это означает, что если вы используете какой-либо компонент, который сам по себе является GPL, вы (вероятно) не сможете выпустить код (который использует это) под MPL; MPL будет ошибочно пытаться разрешить распространять GPL-код под MPL, что является неправильным. Это нормально, если ваши зависимости находятся в порядке лицензии MIT или Apache.

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

Единственное критическое изменение, которое обеспечивает MPL, - это защита от неосознанно вызванных патентных нарушений. Как сказано в лицензии:

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

MPL и GPL не совсем совместимы.

Вы можете увидеть здесь: MIT против BSD против двойной лицензии для обсуждения вопроса о двойных лицензиях.

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