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

26

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

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

Каковы плюсы / минусы «раздачи» всей закодированной работы в виде открытых исходных кодов?

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

Аллан П. Энгсиг-Каруп
источник
Хороший вопрос, мне тоже было интересно.
milancurcic
Это не относится к этому сайту. Я бы порекомендовал опубликовать что-то вроде переполнения стека.
aterrel
Я просто хочу исправить утверждение Мэтта о том, что лицензионное программное обеспечение GPL / LGPL не может использоваться в коммерческих целях. Это тоже может! Лицензионное программное обеспечение GPL может использоваться для любых целей, которые коммерческая организация хочет, они просто не могут создавать производный программный продукт и продавать (распространять) его как закрытый источник (которого должно быть достаточно, если коммерческая организация не является компанией-разработчиком программного обеспечения). LGPL более либерален и позволяет продавать закрытые программные продукты, которые ссылаются на оригинальную библиотеку. Я согласен с Мэттом, что индустрия боится трогать программное обеспечение GPL, но оно основано на неправильном представлении GPL. Мы первоначально использовали
Андерс Логг
1
Я не согласен. Многие люди тратят много времени и усилий на разработку новых основ кода для решения сложных задач вычислительной науки. В рамках этих усилий может быть полезно иметь стратегию для обмена работой с другими.
Аллан П. Энгсиг-Каруп
2
Да, и многие вычислительные люди тратят время на приготовление пищи, но приготовление пищи здесь не по теме. Есть и другие многоуровневые обмены на основные проблемы с программным обеспечением.
aterrel

Ответы:

18

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

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

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

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

Существует множество бесплатных лицензий с открытым исходным кодом, в том числе GPL <= 2, GPL 3 , LGPL , BSD , Eclipse и так далее. У каждого есть свои плюсы и минусы, поэтому прочитайте, какие ограничения они накладывают на код, и решите, кого вы хотите использовать. Внимание , в зависимости от того вы выбираете кто - то будет жаловаться - это является священной войны территория.

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

  • Отличным ресурсом для определения того, какая лицензия является для вас подходящей, является всеобъемлющий интерактивный дифференциатор лицензий от Oxford Universities OSS Watch .

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

Каковы плюсы / минусы «раздачи» всей закодированной работы в виде открытых исходных кодов?

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

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

Если им это нравится, и ваше программное обеспечение делает почти то, что они хотят, они могут улучшить ваше программное обеспечение и внести эти улучшения обратно.

Это очень много, если .

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

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

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

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

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

Этот ответ на этот вопрос также дает некоторую полезную информацию об этой опции.

Марк Бут
источник
12

PETSc использует эту лицензию , которая является менее строгой формой BSD . Принципиальное отличие от GPLявляется то, что программное обеспечение может быть использовано в коммерческих целях. Многие люди имеют принципиальное возражение против закрытого программного обеспечения, однако, по моему опыту, ни один бизнес не приблизится к вашему коду, если у него есть лицензия GPL. Более того, промышленные пользователи PETSc были невероятно ценными. Они, как правило, сталкиваются с довольно сложными проблемами, которые большинство ученых сочли бы более трудными, чем это оправдано для публикации. Они также внесли большой объем кода в PETSc, чтобы он вошел в нормальную цепочку поддержки. Я бы посоветовал против любой лицензии, не имеющей потенциала коммерческого использования, и на самом деле выступал бы за наименее ограниченную возможную лицензию (вы могли бы точно записать PETSc на CD и попробовать продать ее доверчивым).

Мэтт Кнепли
источник
Как финансировалась разработка PETSc? и как это поддерживается (через финансирование) сегодня? Как это работает с поддержкой базы кода для PETSc?
Аллан П. Энгсиг-Каруп
2
Вот финансирование . У нас есть открытый репозиторий и много участников.
Мэтт Кнепли
Ваше заявление о коде GPL: OpenFOAM - это GPL и широко используется в промышленности. Причина в том, что код GPL должен быть опубликован только для распространения программного обеспечения. Лицензия GPL может повлиять только на компании, которые хотят продавать свой код широкой аудитории.
AKID
3
@akid Я не могу найти информацию о пользователях OpenFOAM на сайте, но я скептически отношусь к «широко используемой» характеристике. Я могу вам сказать, что люди из крупных компаний (Shell, Boeing, MS) заявили, что политика компании в отношении исследовательского кода никогда не касается GPL. Возможно, у небольших компаний есть больше возможностей, но более крупные просто хотят избежать даже появления неуместности (глядя на код GPL и кодируя что-то еще).
Мэтт Кнепли,
2
@Tshepang GNOME и Linux используются как канцелярские товары, что никогда не случится с вашим научным кодом. Я имею в виду, когда ваш код используется в целях, непосредственно связанных с бизнесом.
Мэтт Кнепли,
5

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

Во всяком случае, самая важная вещь в этой теме заключается в том, что любая лицензия лучше , чем ничего, что, к сожалению , довольно часто в научном мире развития - и я просто ненавижу всех тех / * Stolen из программы Джона Смита, он никогда не огласку * / или Я думаю, что видел это в посте Джейн Смит о какой-то группе в 1995 году ... или, может быть, в 1993 году?

МБк
источник
1
Помните, что если код не имеет лицензии, то в большинстве стран (которые подписали Бернскую конвенцию ) на него все еще распространяется авторское право, поэтому он не может быть юридически использован кем-либо, кроме владельца авторских прав, не говоря уже о распространении.
Марк Бут
@MarkBooth Это моя точка зрения.
МБК
5

Во-первых, плюсы / минусы открытого исходного кода:

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

Против: если вы когда-нибудь захотите основать бизнес на своем коде, у вас будет меньше вариантов (но есть еще несколько, например, продажа консультационных услуг)

Что касается выбора лицензии, я бы поступил в следующем порядке:

  1. Ваш работодатель / грантовое агентство что-то навязывает? Тогда у тебя нет выбора. Проверьте это для всех участников кода.
  2. Вы повторно используете код с определенной лицензией, которая ограничивает ваш выбор? Тогда ваш выбор также ограничен. На практике интеграция фрагментов GPL-лицензированного кода является наиболее частым источником таких ограничений.
  3. Решите, что вы цените больше: философию «весь код должен быть открыт» за лицензией GPL и аналогичными лицензиями или за философию поощрения как можно более широкого использования за лицензию BSD.
  4. В каждом из двух больших семейств лицензий Open Source выберите в соответствии с тем, что наиболее распространено / принято в вашем сообществе.
khinsen
источник
5

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

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

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

Дэниэл Стендж
источник
5

Никто не объяснил это очень четко, поэтому я думаю, что стоит сказать:

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

Одним из практических следствий является:

  • Если вы реализуете новый численный метод в C, лицензия не позволяет вызывать его из таких распространенных программ, как MATLAB или Mathematica.

  • Если вы реализуете новый алгоритм обработки изображений, лицензия не позволит сделать из него плагин Photoshop

  • и так далее ...

Это не только предотвратит коммерческое повторное использование, но также и удобное повторное использование другими учеными (если они используют закрытое программное обеспечение), а если кто-то строит поверх вашего кода, это не позволит им отдать свою работу в "do" -что-ты-с-это "путь.

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

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


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

Сабольч
источник
4

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

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

фомиты
источник
4

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

qubyte
источник
4

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

Для моих продуктов код закрыт, и для этого по-прежнему существуют серьезные бизнес-преимущества. Но, конечно, есть и другие способы сделать это (например, как продемонстрировано MySQL среди других). Я часто вижу LGPL + коммерческий лицензионный подход для библиотек. Я еще не использовал такую ​​библиотеку в коммерческой системе, но я бы не стал исключать ее (пока я использовал такие библиотеки, например, ALGLIB, на уровне НИОКР). Это контрастирует с продуктом GPL - который я мог бы использовать внутри, но никогда не использовал бы в продукте, главным образом из-за вирусной природы.

Когда я выпускаю исходный код (примеры с инструкциями, бесплатные программы и т. Д.), Я обычно использую лицензию Berkeley. Похоже, что это гораздо больше в духе «свободного» кода, с указанием авторства, но без строк и политики GPL. Возможно, именно поэтому он (или аналогичные лицензии, такие как лицензия MIT) так популярен среди университетов и общественных организаций. Исходный код отдан в истинном значении «бесплатный» (вот какой-то код, делайте с ним что хотите), но автор все равно получает кредит / атрибуцию.

winwaed
источник
Я не тот, кто проголосовал за это, и я на самом деле хотел бы проголосовать за это, так как кажется, что вы предпочитаете лицензию BSD и подробнее о том, почему это может быть интересно. Тем не менее, у него есть проблема. Используемый язык провокационный. Точно такая же информация может быть передана без желчи, и вы, вероятно, дойдете до большего числа людей с вашим сообщением.
Квебайт
@ MarkS.Everitt: Помимо комментариев о политике, что именно здесь является провокационным?
Aeismail
Да, не желчь была предназначена. Мой комментарий по поводу политики GPL - это личное мнение, но также и наблюдение - я предположил, что голосование «за» было именно той политикой, которая меня отталкивает (как я смею критиковать GPL и писать закрытый код!)
winwaed
Возьмите, например, ваше вступительное предложение. Это непосредственное « я против вас» , которое продолжается в предложении «вопреки чему ...». Это не должно иметь значения, но, к сожалению, это имеет значение. Это также скользкий путь для генерации аргументов, и молодой SE не нуждается в них.
qubyte
Первое предложение устанавливает контекст моего ответа - ВСЕ пишут из своего собственного опыта, признают они это или нет. Контекст важен - и я подумал, что это особенно важно для меня. Я постараюсь отредактировать следующий абзац, но я могу просто сдаться и удалить все это. Я думал, что могу сказать что-то полезное ...
winwaed
0

Это старый вопрос, но я думаю, что Mozilla Public License стоит упомянуть в качестве посредника между разрешительными лицензиями (BSD, MIT) и лицензиями с сильным авторским левом (GPL). Код MPL можно использовать и распространять, но код MPL и любые его изменения должны быть доступны. Например, компания может взять некоторый код MPL, внести в него свои собственные усовершенствования и распространить его в проприетарном пакете программного обеспечения с закрытым исходным кодом, при условии, что они предоставляют свою модифицированную версию исходного кода MPL. Они не обязаны выпускать весь свой собственный исходный код, как это было бы с GPL.

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

Даниэль Шаперо
источник