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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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