Чому компанії переходять із відкритих ліцензій на source-available

Проблема виникає, коли хмара продає чужий продукт

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

Source-available — не те саме, що відкритий код

Source-available ліцензія зазвичай дозволяє будь-кому переглядати, змінювати й самостійно розгортати код, але забороняє конкретну категорію використання — найчастіше пропонувати продукт як хмарний сервіс третім особам. Це порушує принаймні одну з формальних вимог відкритого коду, тому такі проєкти вже не можуть коректно називатися open source за визнаними означеннями, навіть якщо код так само публічний. Різниця важлива для компаній, які включають залежності у власні продукти: юридичний відділ має окремо перевіряти кожну зміну ліцензії, а не покладатися на попередню репутацію проєкту. Зміна ліцензії тісно пов’язана з пошуком стійких моделей фінансування, а довіру до випусків підтримує перевірюваний підпис релізів.

Спільнота реагує на зміну довіри, а не лише на текст ліцензії

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

Вибір ліцензії потрібно пояснювати заздалегідь

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