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

Розробники програмного забезпечення можуть вибрати відповідну ліцензію відповідно до цілей роботи.

Хтось може дати рекомендації / досвід щодо того, яку ліцензію вибрати для програмного забезпечення?

Які плюси та мінуси "віддати" всі кодовані роботи як коди з відкритим кодом?

Як боротися з промисловими гравцями, які хотіли б отримати користь від коду дослідження?

Хтось може дати рекомендації / досвід щодо того, яку ліцензію вибрати для програмного забезпечення?

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

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

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

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

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

• Чудовим ресурсом для визначення того, яка ліцензія є правильною ліцензією, є дуже всебічний, інтерактивний диференціатор ліцензій від Oxford Universities OSS Watch .

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

Які плюси та мінуси "віддати" всі кодовані роботи як коди з відкритим кодом?

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

Якщо вони використовуватимуть їх, вони знайдуть, повідомлять і часто виправлятимуть помилки, економлячи ваші зусилля робити те саме.

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

Це дуже багато ifs, хоча.

Як боротися з промисловими гравцями, які хотіли б отримати користь від коду дослідження?

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

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

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

Зауважте, якщо ви збираєтесь це робити, пропонуйте це з самого початку - це, швидше за все, спричинить менше тертя у ваших дописувачів з відкритим кодом, ніж згодом ви починаєте пропонувати комерційні ліцензії. Якщо ваша громада стає популярною, ви не хочете, щоб люди звинувачували вас у продажі, якщо ви не були зрозумілі про можливість комерційної експлуатації пізніше. В ідеалі вам слід створити відповідну ліцензійну угоду для дописувачів (CLA), перш ніж ви почнете приймати внески сторонніх осіб у свою кодову базу.

Ця відповідь на це питання також дає хорошу інформацію про цей варіант.

PETSc використовує цю ліцензію , яка є менш обмежувальною формою BSD . Важлива відмінність від GPL, полягає в тому, що програмне забезпечення можна використовувати комерційно. Багато людей мають принципове заперечення проти закритого програмного забезпечення, проте, на мій досвід, жоден бізнес не наблизиться до вашого коду, якщо він має ліцензію GPL. Більше того, промислові користувачі PETSc були надзвичайно цінними. Вони, як правило, мають досить складні проблеми, які більшості науковців виявляться складніше, ніж гарантовано для публікації. Вони також внесли чимало коду назад у PETSc, щоб він увійшов у звичайний ланцюжок підтримки. Я б радив проти будь-якої ліцензії без потенціалу комерційного використання, і насправді виступав за найменш обмежувальну ліцензію (ви, безумовно, можете записати PETSc на компакт-диск і спробувати продати його довірливим).

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

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

По-перше, плюси та мінуси відкритого джерела:

Про: більше людей використовуватиме ваш код, надаватиме зворотній зв'язок, виправлення, вдосконалення тощо. У вас з’явиться кращий код і більше людей, які йому довіряють.

Con: якщо ви хочете коли-небудь засновувати бізнес у своєму коді, у вас є менше варіантів (але є ще кілька, наприклад продаж консультаційних послуг)

Щодо вибору ліцензії, я б діяв у наступному порядку:

1. Ваш роботодавець / грантове агентство щось нав'язує? Тоді у вас немає вибору. Перевірте це для всіх учасників коду.
2. Чи повторно використовуєте код, який має певну ліцензію, яка обмежує ваш вибір? Тоді ваш вибір також обмежений. На практиці інтеграція фрагментів коду з ліцензією GPL є найчастішим джерелом таких обмежень.
3. Вирішіть, що ви більше цінуєте: філософія all-code-must-be-open за GPL та подібними ліцензіями або філософія заохочення до найширшого використання за ліцензією BSD.
4. У межах кожної з двох великих ліцензійних сімей з відкритим кодом вибирайте те, що є найбільш поширеним / прийнятим у вашій громаді.

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

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

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

Ніхто цього не написав дуже чітко, тому я думаю, що варто сказати:

Деякі ліцензії з відкритим кодом (зокрема: GPL) є "вірусними" в тому сенсі, що коли код використовується в новому проекті, новий проект повинен ліцензуватися аналогічно. Також код не може бути пов'язаний (певними способами) з різним ліцензованим кодом.

Одним із практичних наслідків є:

• Якщо ви реалізуєте новий числовий метод в C, ліцензія не дозволить викликати його з такого поширеного програмного забезпечення, як MATLAB або Mathematica

• Якщо ви реалізуєте новий алгоритм обробки зображень, ліцензія не дозволить зробити з нього плагін Photoshop

• і так далі ...

Це не тільки запобіжить комерційному повторному використанню, але і зручному повторному використанню іншими науковцями (якщо вони використовують закрите програмне забезпечення), і якщо хтось будує над вашим кодом, це заважатиме їм віддавати свою роботу в режимі "робити" -как-ти-будеш-з-за ».

Це те, що ви повинні розглянути, перш ніж закінчити формувати свою ліцензію.

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

^{(Це лише особиста думка, але я вважаю, що застосовувати такі обмеження до роботи, що виходить із (за рахунок державних коштів) академій, не є доцільним. Тому я або зберігаю код, або віддаю його.)}

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

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

Для великих тел коду я шукаю одну з ліцензій, описану в інших відповідях, і зазвичай LGPL. Однак, хоча зазвичай не рекомендується для програмного забезпечення , для невеликих автономних сценаріїв, які я можу надсилати колезі по галузі, я часто вибираю ліцензію Creative Commons . Це тому, що вони, як правило, зрозуміліші для людини, до якого я надсилаю код, що зупиняє будь-які можливі проблеми непорозуміння. Це минуло добре спрацювало для мене.

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

Щодо моїх продуктів, код закритий, і для цього все ще залишаються основні переваги для бізнесу. Але, звичайно, є й інші способи зробити це (наприклад, як це демонструє MySQL серед інших). Я часто бачу комерційний ліцензійний підхід LGPL + для бібліотек. Мені ще доводиться використовувати таку бібліотеку в комерційній системі, але я б не виключав її (до цих пір я використовував лише такі бібліотеки, наприклад, ALGLIB, на рівні НДДКР). Це контрастує з продуктом GPL - який я можу використовувати внутрішньо, але ніколи б не використовував у продукті, головним чином через вірусну природу.

Коли я випускаю вихідний код (практичні зразки, безкоштовні програми тощо), я зазвичай використовую ліцензію Berkeley. Це, здається, набагато більше в дусі "безкоштовного" коду, з атрибуцією, але без рядків і політики GPL. Можливо, саме тому (або подібні ліцензії, такі як ліцензія MIT) настільки популярні серед університетів та громадських організацій. Вихідний код надається у справжньому значенні "безкоштовно" (ось якийсь код, виконайте з ним все, що завгодно), але автор все одно отримує кредит / атрибуцію.

Це давнє запитання, але я думаю, що публічну ліцензію Mozilla варто згадати як середину між дозвільними ліцензіями (BSD, MIT) та потужними ліцензіями на копілефт (GPL). MPL-код можна використовувати та перерозподіляти, але код MPL та будь-які його модифікації повинні бути доступними. Наприклад, компанія може взяти якийсь код MPL, внести свої вдосконалення до нього та розповсюдити його у фірмовому пакеті програмного забезпечення із закритим кодом, доки вони надають модифіковану версію оригінального коду MPL. Вони не зобов’язані випускати весь власний вихідний код, як це було б із GPL.

Завдяки ліцензії BSD існує побоювання, що корпорація може прийняти ваш код і вдосконалити його, не віддаючи ці внески вам або громаді взагалі, на підставі того, що вдосконалення, які вони вносять до неї, надають конкурентну перевагу. (Відповідь Метта Кнеплі говорить про те, що не кожен діє так). З іншого боку, багато людей можуть взагалі уникати GPL-коду. MPL уникає обох цих можливих підводних каменів, принаймні в принципі.