Open source не означає «можна використовувати без обмежень»: кожна бібліотека, фреймворк чи інший компонент має ліцензію з конкретними умовами. Найбільші ризики для бізнесу пов’язані з GPL та AGPL, транзитивними залежностями, зміною ліцензій між версіями й кодом із зовнішніх джерел. Щоб уникнути претензій, розкриття власного коду та проблем під час due diligence, компанії варто регулярно перевіряти залежності й вибудувати базовий IP-комплаєнс.Отже, Open source у бізнесі: як працювати з ліцензіями без юридичних ризиків - далі у нашій статті
Середній сучасний застосунок складається з власного коду відсотків на десять-двадцять. Решта — бібліотеки, фреймворки, утиліти, підтягнуті менеджером пакетів разом із транзитивними залежностями. Кожна з них має ліцензію, і жодна з цих ліцензій не означає «робіть що хочете».
Open source — це не відсутність прав, а специфічний спосіб їх реалізації. Автор зберігає авторське право й дозволяє використання на визначених умовах. Порушив умови — залишився без дозволу, тобто в становищі звичайного порушника авторського права.
Три групи ліцензій
Пермісивні — MIT, BSD, Apache 2.0. Вимагають зберігати повідомлення про авторство та текст ліцензії; Apache 2.0 додатково містить патентне застереження й вимогу позначати зміни. Комерційне використання, включно з закритим продуктом, дозволене. Це найбезпечніша категорія, але навіть тут забутий NOTICE-файл є формальним порушенням.
Копілефт — GPL різних версій. Якщо ви поширюєте продукт, що містить GPL-компонент і утворює з ним похідний твір, весь такий продукт має розповсюджуватися на умовах GPL, з відкриттям вихідного коду. Для компанії, чия цінність — у власному алгоритмі, це фактично вимога опублікувати комерційну таємницю. LGPL пом'якшує правило для динамічного лінкування, але межа між «використання» і «похідний твір» — питання, яке краще вирішувати до релізу, а не після.
Мережевий копілефт — AGPL. Найнебезпечніша ліцензія для SaaS. Класична GPL прив'язує зобов'язання до поширення копії, тож хмарний сервіс формально нічого не поширював. AGPL закриває цю прогалину: надання доступу користувачам через мережу прирівнюється до поширення. Багато популярних баз даних і платформ свого часу перейшли на AGPL саме для цього.
Де компанії найчастіше «влітають»
- Транзитивні залежності. Перевірили ліцензію бібліотеки, але не її десяти залежностей. Одна з них — GPL.
- Зміна ліцензії між версіями. Проєкт, який колись був під Apache 2.0, у новій мажорній версії перейшов на BSL або AGPL. Оновлення підтягнулося автоматично.
- Подвійне ліцензування. Компонент доступний під GPL безкоштовно або під комерційною ліцензією за гроші. Використання «за замовчуванням» означає GPL з усіма наслідками.
- Код з форумів і від AI-асистентів. Фрагмент, скопійований зі StackOverflow чи згенерований на основі чужого репозиторію, приходить у продукт без жодної ліцензійної історії.
- Шрифти, іконки, стокові зображення. Формально не код, але той самий механізм ліцензування — і той самий ризик претензії.
Наслідки
Порушення ліцензії відкриває власнику стандартний набір інструментів: вимога припинити використання, стягнення компенсації, а в разі копілефту — тиск у бік розкриття коду. Додаються практичні наслідки: зрив угоди на due diligence, вимога інвестора провести повний ремедіейшн, блокування застосунку в App Store чи Google Play за скаргою правовласника.
Що вибудувати всередині
Комплаєнс тут не потребує великого бюджету, лише системності. Мінімум: реєстр усіх залежностей з ліцензіями, автоматизований scan у CI-пайплайні, внутрішній перелік заборонених і дозволених ліцензій, правило узгодження нових компонентів, генерація NOTICE-файлу під час збірки, а також політика щодо коду з зовнішніх джерел і AI-інструментів. Ці процеси і є ядром того, що називають IP-комплаєнс для бізнесу.
Перевіряти це варто регулярно — при зміні складу команди, перед мажорними релізами й перед будь-якою угодою. Юристи IP EYE проводять такі аудити разом з технічними командами, бо оцінка «похідний це твір чи ні» лежить одночасно в правовій і архітектурній площині.
Найкоротший висновок: безкоштовний компонент — не те саме, що компонент без умов. Умови є завжди, питання лише в тому, чи прочитав їх хтось у команді.
Відповіді на популярні запитання
Чи можна безпечно використовувати open source у комерційному продукті?
Так, але лише з дотриманням умов конкретної ліцензії. Навіть безкоштовна бібліотека може вимагати збереження тексту ліцензії, зазначення авторства, публікації змін або відкриття вихідного коду.
Які open source ліцензії найменш ризиковані для бізнесу?
До найзручніших для комерційних продуктів належать MIT, BSD та Apache 2.0. Вони дозволяють використовувати компоненти в закритому програмному забезпеченні, але встановлені ними вимоги щодо авторства, ліцензійних повідомлень та інших умов усе одно потрібно виконувати.
Чому GPL може створити проблему для закритого програмного продукту?
Якщо GPL-компонент стає частиною похідного твору, під час його поширення можуть виникнути зобов’язання розповсюджувати весь відповідний продукт на умовах GPL і надати вихідний код. Для компанії з власними закритими розробками це може бути критично.
Чим AGPL відрізняється від звичайної GPL?
AGPL поширює вимоги копілефту і на програмне забезпечення, доступне користувачам через мережу. Тому ця ліцензія особливо важлива для SaaS-проєктів, навіть якщо компанія не передає користувачам копію програми.
Чому потрібно перевіряти не тільки основні бібліотеки, а й їхні залежності?
Одна бібліотека може підтягувати десятки інших пакетів із власними ліцензіями. Серед транзитивних залежностей іноді трапляються GPL, AGPL або компоненти з іншими умовами, про які команда навіть не підозрює.
Чи може ліцензія бібліотеки змінитися після оновлення?
Так. Розробники можуть випустити нову версію проєкту вже під іншою ліцензією, тому автоматичне оновлення залежностей іноді змінює і юридичні умови використання компонента.
Що означає подвійне ліцензування open source продукту?
Один і той самий компонент може пропонуватися, наприклад, безкоштовно за GPL і окремо за платною комерційною ліцензією. Якщо компанії не підходять вимоги GPL, вона може придбати комерційну ліцензію з іншими умовами.
Чи є ризик у коді зі StackOverflow або AI-асистентів?
Так, якщо команда не знає походження фрагмента та умов, на яких його можна використовувати. Для такого коду варто мати окремі внутрішні правила перевірки, особливо якщо він потрапляє до комерційного продукту.
Що може статися через порушення open source ліцензії?
Правовласник може вимагати припинити використання компонента, усунути порушення або виплатити компенсацію. Проблемна залежність також здатна ускладнити інвестиційну угоду, due diligence чи розміщення застосунку в магазинах.
Як організувати контроль open source ліцензій у компанії?
Корисно вести реєстр залежностей і їхніх ліцензій, автоматично перевіряти пакети в CI, визначити дозволені та заборонені ліцензії й контролювати додавання нових компонентів. NOTICE-файли та інші необхідні повідомлення краще формувати автоматично під час збірки.
Коли варто проводити аудит open source компонентів?
Перевірку варто робити регулярно, а особливо перед великими релізами, інвестиціями, продажем компанії чи іншими угодами. Чим раніше виявлена проблемна залежність, тим простіше замінити її або врегулювати ліцензійні умови.
