Чи важливо для вас, що програмне забезпечення є "доступним джерелом", але не "відкритим кодом"

Напевно, ви знаєте список ліцензій з відкритим кодом, офіційно затверджених OSI. Найбільш помітним, мабуть, був би GPL, MIT, [вставте сюди свою улюблену ліцензію].

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

• Він випустив джерело, але не обіцяв випустити джерело у майбутньому.

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

• Це дозволяло використовувати програмне забезпечення в комерційних або платних проектах, але забороняло продаж самого програмного забезпечення.

Я припускаю, що це можна назвати "доступним джерелом", а не відкритим кодом, як нам це подобається.

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

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

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

Цікаво, що про це думають інші.

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

Але чи буде краще порівняльний пакет з відкритим кодом, залежить від інших факторів:

• чи він буде використовуватися для надання певної послуги або в комплекті з іншим продуктом?
• чи мають вони ресурси для самостійного покращення та підтримки продукту?
• Чи є конкурентна перевага використовувати це програмне забезпечення над відкритою версією (або в коді, або в проекті)?

Якщо не відповісти ні на один із цих факторів, то OSS є кращим вибором.

В більшості випадків сам код не є визначальним фактором. Потрібно вивчити більшу картину.

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

Питання до цієї та будь-якої іншої зовнішньої бібліотеки - це обслуговування .

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

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

Сама ця думка може зробити бібліотеку занадто дорогою у використанні.

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

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

Ви можете вільно обговорювати цю бібліотеку?

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

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

Єдині ситуації, коли ІМХО "відкритий код" перемагає ліцензію "доступного джерела", викладену у питанні, - коли

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

Ось чому Фонд вільного програмного забезпечення використовує терміни "вільне" або "невільне" для опису програмного забезпечення. Вони мають на увазі не ціну, а обмеження, що застосовуються до використання чи розповсюдження програмного забезпечення.

Схоже, ви потрапили в один з рідкісних кутових випадків, коли ви маєте повний доступ до вихідного коду чогось, але програмне забезпечення не є "Відкритим кодом" за визначенням OSI .

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

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

Як КТО, я намагаюся зробити все, щоб ми не залежали від невільного програмного забезпечення. У минулому я кілька разів опинився на поганому завершенні блокування постачальників, помилка, яку мені подобається уникати. Хоча ми використовуємо деякі власні речі, наш бізнес не зазнав би надмірних труднощів, якби ми раптом ми більше не могли ним користуватися.

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

Це має значення зовсім небагато. Основні проблеми щодо описаного вами підходу "доступного джерела":

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

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