У компаній, які розробляють програмні продукти, питання ліцензування виникають на двох етапах. Перший – під час розробки команда може використовувати сторонні компоненти, зокрема відкритий код та ШІ-інструменти. Другий – після створення продукту компанія має визначити, на яких умовах передавати його користувачам та які права вони отримують.
Це актуально для розробників SaaS, PaaS, мобільних і веб-додатків, сервісів, веб-сайтів та платформ. У статті розглянемо обидві сторони ліцензування: як IT-компанії можуть використовувати сторонні компоненти у власному продукті та як ліцензувати готове ПЗ для клієнтів.
Ліцензії на сторонні компоненти
Під час розробки IT-продукту компанія може використовувати готове програмне забезпечення та компоненти з відкритим вихідним кодом. Перед включенням стороннього коду до продукту важливо визначити, яка ліцензія на нього поширюється, що саме вона дозволяє та які обов'язки виникають у розробника продукту.
Типи ліцензій залежно від умов використання відкритого коду
Для роботи з open source важливо перевіряти умови конкретної ліцензії та враховувати вимоги, які вона встановлює для розробника. Для ідентифікації ліцензій можна використовувати стандартизовані SPDX-ідентифікатори.
За характером прав та обов’язків, які вони встановлюють для користувача, open source-ліцензії поділяють на permissive, copyleft та public domain.
- Permissive
MIT, BSD та Apache 2.0 належать до ліцензій із відносно широкими правами на використання, модифікацію та розповсюдження коду. При цьому вони встановлюють певні умови, наприклад вимоги щодо збереження повідомлення про авторські права або тексту ліцензії.
- Copyleft
GPL, AGPL та LGPL встановлюють додаткові вимоги до розповсюдження похідного коду. Застосування таких ліцензій може вплинути на умови ліцензування та розповсюдження власного продукту – конкретні наслідки залежать від умов відповідної ліцензії та способу використання компонента.
- Public domain
Код або інший твір може перебувати у суспільному надбанні (public domain), якщо на нього не поширюються відповідні майнові права або вони були належним чином відмовлені чи припинені. Такий статус потрібно перевіряти окремо для конкретного компонента та юрисдикції.
Чому важливо перевіряти ліцензії з відкритим кодом?
Умови open source-ліцензії можуть встановлювати конкретні обов’язки для компанії, яка включає компонент до свого продукту: від збереження повідомлень про авторські права до розкриття вихідного коду. Тому перед використанням компонента потрібно визначити ці вимоги та оцінити їхній вплив на подальше ліцензування продукту.
За даними Black Duck, у 2025 році 56% перевірених кодових баз містили конфлікти з умовами open source-ліцензій. Аналіз грунтувався на аудитах комерційних кодових баз і показує, що ліцензійні ризики залишаються поширеною проблемою для компаній, які використовують відкритий код у власних продуктах.
Перед використанням стороннього компонента варто перевірити:
- яка саме ліцензія поширюється на компонент;
- чи дозволене комерційне використання;
- чи можна змінювати та розповсюджувати код;
- які повідомлення про авторські права потрібно зберегти;
- чи виникають обов'язки щодо розкриття вихідного коду;
- чи сумісна ліцензія компонента з моделлю розповсюдження вашого продукту.
Для компаній, які регулярно використовують open source, доцільно вести реєстр компонентів та їхніх ліцензій. SPDX прямо передбачає використання ліцензійних метаданих для аналізу комплаєнс-ризиків та прийняття рішень щодо використання і розповсюдження ПЗ.
Використання ШІ під час розробки програмного забезпечення
ШІ-інструменти можуть використовуватися для створення коду, який згодом стає частиною комерційного програмного продукту. Тому перед його включенням до продукту IT-компанії варто перевірити умови використання AI-сервісу та можливі права третіх осіб на отриманий код.
AI може генерувати код, схожий на фрагменти програмного забезпечення, що вже поширюються за open source-ліцензіями. Дослідження 2025 року за участю комерційних ШІ-інструментів виявило випадки відтворення фрагментів існуючого коду.
Перед використанням ШІ-коду у власному ПЗ варто:
- перевірити умови ліцензування AI-сервісу;
- перевірити, чи не містить код фрагментів стороннього програмного забезпечення;
- визначити, чи поширюється на такі фрагменти open source-ліцензія;
- переконатися, що її умови сумісні з тим, як компанія планує ліцензувати та розповсюджувати власний продукт.
Наприклад, актуальні умови GitHub прямо передбачають, що результат роботи AI може містити матеріал, на який поширюються права третіх осіб або умови ліцензій з відкритим кодом. При цьому саме користувач відповідає за перевірку такого результату та дотримання відповідних ліцензійних умов.
AI-код потрібно перевіряти так само, як і будь-який інший сторонній компонент, перш ніж включати його до продукту, який компанія планує ліцензувати.
Ліцензування готового програмного продукту
Ліцензія на програмне забезпечення – це дозвіл правовласника на використання програмного продукту на визначених умовах. Вона встановлює, які права отримує клієнт, як він може використовувати продукт, протягом якого строку та на якій території.
Види ліцензій на програмне забезпечення за обсягом прав
Залежно від обсягу прав, які отримує користувач, ліцензія може бути виключною або невиключною.
- Виключна ліцензія на програмне забезпечення – ліцензіар не може надавати право використання об'єкта іншим особам у межах наданих ліцензіату прав та не може використовувати його самостійно, якщо інше не передбачено договором.
- Невиключна ліцензія на програмне забезпечення – правовласник зберігає право використовувати ПЗ самостійно та надавати аналогічні ліцензії іншим користувачам.
Для продуктової IT-компанії вибір між цими видами ліцензій безпосередньо впливає на модель монетизації продукту. Невиключна ліцензія дозволяє одночасно працювати з кількома клієнтами та масштабувати продажі одного програмного продукту. Виключна ліцензія може бути доцільною, коли клієнту потрібні особливі права на використання ПЗ, а компанія готова обмежити подальше ліцензування.
Важливо також чітко визначати межі наданих прав. Клієнт може використовувати ПЗ лише в тому обсязі, який передбачений договором: наприклад, для визначеної кількості користувачів, пристроїв, процесорних ядер або копій.
Показовою є справа 4DD Holdings, LLC v. United States. Компанія 4DD Holdings передала уряду США програмне забезпечення TETRA з обмеженням щодо кількості копій. Підрядники уряду створили більше копій, ніж було дозволено договором. У результаті суд присудив 4DD Holdings $12,683 млн компенсації, але у 2026 році апеляційний суд скасував частину рішення та направив справу на новий розгляд щодо розміру компенсації.
Для IT-компаній цей кейс показує, чому в ліцензійному договорі важливо чітко прописувати, скільки і як саме клієнт може використовувати ПЗ.
Що написати у ліцензійному договорі?
Ліцензійний договір має чітко визначати, які права компанія передає клієнту і в яких межах він може використовувати програмний продукт.
Зокрема, у договорі варто визначити:
- предмет договору – яке саме програмне забезпечення передається у користування та як його можна ідентифікувати;
- вид ліцензії – виключна чи невиключна;
- способи використання ПЗ – наприклад, запуск, відтворення, встановлення, інтеграція з іншими системами;
- кількість користувачів, пристроїв, копій або інших одиниць використання, якщо це передбачено моделлю ліцензування;
- територію та строк дії ліцензії;
- можливість модифікації, адаптації або декомпіляції ПЗ;
- можливість передачі прав третім особам та субліцензування;
- розмір і порядок сплати ліцензійної винагороди;
- порядок надання доступу до ПЗ та його оновлень, якщо вони входять до домовленостей;
- відповідальність сторін за порушення умов використання;
- умови припинення ліцензії та наслідки її припинення.
Важливо узгодити ліцензійні умови з реальною бізнес-моделлю продукту. Наприклад, якщо SaaS-продукт продається за кількістю користувачів, саме цей показник має бути відображений у договорі. Якщо ПЗ встановлюється на певну кількість пристроїв або використовується в межах визначеної інфраструктури, відповідні обмеження також варто зафіксувати.
Команда Stalirov&Co підготувала ліцензійну угоду на програмне забезпечення для SaaS-рішення KVSaaS, яке компанія передавала клієнтам у Німеччині. У договорі визначили невиключну ліцензію, обмеження щодо використання ПЗ, заборону субліцензування та модель доступу за платною підпискою. Цей кейс показує, як умови ліцензійної угоди можна адаптувати до конкретної бізнес-моделі IT-продукту.
Таким чином, IT-компанії варто перевіряти ліцензування програмного продукту на всіх етапах його створення та використання. Під час розробки потрібно враховувати умови сторонніх компонентів, відкритого коду та інструментів ШІ. Після завершення розробки – чітко визначити права клієнта та закріпити їх у ліцензійному договорі відповідно до моделі використання продукту.
