Причини НЕ відкривати вихідний код некомерційного коду? [зачинено]

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

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

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

Пояснення: Під "неприбутковим" я включаю мотиви прибутку нижче, такі як визнання бренду материнської компанії та очікування прибутку інвестора. Іншими словами, питання стосується лише програмного забезпечення, для якого НЕ БУДЬ мотив прибутку, пов'язаний із програмним забезпеченням.

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

Як приклад, у цій публікації блогу інженер Sun / Oracle описує зусилля, які їм доводилося докладати, коли відкривати код свого коду: Open Source або брудна пральня?

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

Ще одна підготовча діяльність - «очищення» коду патентованої інформації, згадування конкретних замовників, розробників, технологій тощо. Це трохи менш очевидно, але врахуйте наступний приклад:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

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

Інша частина діяльності "вичісування" - це видалення нецензурних лексик та інших "небажаних" слів ...

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

Безпека.

Наприклад, скажіть, ви будуєте веб-фреймворк і ви самі ним користуєтеся.

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

• КСРР
• XSS
• Введення SQL
• Фіксація сесії
• Використання грізних сторонніх бібліотек або навіть мов

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

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

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

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

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

Вам потрібно бути обережним у виборі ліцензії, щоб уникнути можливих проблем з відповідальністю.

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

Попередження: Я не юрист .

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

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

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

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

Зауважте також, що закони про авторські права відрізняються від країни до країни. Багато європейських країн вважають закони про захист авторських прав США та патентну систему США досить глухими, наприклад, тому культурні передумови та вагу важко позбутися.

За мої 2 центи на цю тему.

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

Існує щонайменше два різні види відкритого коду.

Якщо ваше ставлення до "ось щось корисне, я з цим закінчую" (і це виявляється точно), то недоліків мало.

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