Вибір open source ліцензії. Особливості використання для комерційних проєктів

Привіт, мене звати Олексій, я працюю в компанії Cisco, у вільний час займаюсь соціальними та волонтерськими проєктами. Я та компанія в тому числі підтримували та організовували безкоштовні курси по CCNA в рамках проєкту Veteranius (IT-освіта для ветеранів).

Розробники не часто звертають увагу на ліцензії, коли користуються різними open source проєктами. Дуже часто ми можемо використовувати проєкти*/ частину проєкту або функції для своїх застосунків та програм, навіть не замислюючись, як це може вплинути надалі. Чи треба зберігати копірайти? Які вимоги та зобов’язання існують у різних ліцензій? В цій статті я хочу висвітлити питання вибору ліцензій для свого проєкту, особливості використання проєктів з різними видами ліцензій. Дуже часто цьому питанню приділяють час за залишковим принципом.

* тут і далі під проєктом мається на увазі open source проєкт або репозиторій.

В Cisco я вже більше 3-х років розвиваю дві платформи для обміну кодами. Code Exchange та Automation Exchange це агрегатори open-source проєктів. У нас є вимоги до наявності ліцензій до наявності копірайтів і тп. Нижче я поділюсь інформацією про ліцензії, їх використання для комерційних проєктів/ пропрієтарного ПЗ.

Про open source ліцензії

Ліцензія для open source проєктів — це юридичний договір, що регулює відносини між автором (авторами) і користувачем, в якому описуються умови використання проєкту/ коду в тому числі в комерційних програмах. Ліцензія визначає, що можна і не можна робити з компонентами програмного забезпечення, зобов’язання та особливості використання. В ліцензіях дуже часто борються прагматизм і ідеологія вільного програмного забезпечення. Коли ми чуємо open source ми можемо подумати, що можна без проблем використовувати/ змінювати проєкти, але як було зазначено вище, кожна ліцензія накладає певні зобов’язання з моменту використання, як мінімум — зберігати копірайт. Певні ліцензії можуть зобов’язати опублікувати вихідний код всього проєкту, в якому був використаний код, наприклад, коли використовується проєкт під ліцензією GPL.

Ліцензії можна поділити на

• Copyleft (GNU, Microsoft Public License),
• Permissive (Apache, MIT, BSD).

Copyleft можна також розділити на «слабкі» та «сильні»:

• до «сильних» відносять GNU,
• до «слабких» — наприклад, Eclipse, GNU Lesser General Public License (LGPL).

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

Так виглядає Топ ліцензій у 2021 році. Дані: MEND open source research

Але у чому відмінність, наприклад, між різними копілефт або дозвільними ліцензіями?

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

Частково в цьому плані можуть допомоги інфографіки на кшталт:

GNU General Public License

Якщо ви використовуєте проєкти під GPL ліцензією у своєму програмному забезпеченні, тоді все ваше програмне забезпечення вважається «твором, заснованим на» GPL, права використання патентів, авторських прав нерегульовані. Хто ж тоді слідкує, що б GPL проєкти залишались copyleft? Free Software Foundation (FSF) — цій організації належать права на частини проєктів GNU систем.

І взагалі GPL вважається досить «агресивною» ліцензією, яка в деяких випадках навіть не сумісна з іншими copyleft ліцензіями. Окрім того, цю ліцензію та ліцензію Creative Commons часто називають вірусними ліцензіями, через те, що вона передається з проєкту в проєкт.

Винятки для GNU Lesser General Public License

До 1999 ліцензія мала назву GNU Library General Public License. Відповідна ліцензія була створена, щоб не порушувати принципи вільного програмного забезпечення, щоб розробники могли використовувати цю ліцензію для своїх бібліотек, скриптів. Поруч з тим, щоб інші розробники та компанії могли використовувати відповідні проєкти з ліцензією LGPL, без впливу на ліцензію загального/компільованого проєкту, в тому числі комерційного.

Проєкти, що використовують GNU GPL: Linux Kernel, WordPress (GNU GPL-2.0), Solidity, the Smart Contract Programming Language (GNU GPL v3.0), Grafana (GNU Affero General Public License v3.0), FFmpeg (GNU Lesser General Public License (LGPL) version 2.1).

Apache

На відміну від інших дозвільних ліцензій має пункт 3 (3. Grant of Patent License.), що стосується патентів. Пункт регулює утилізацію патентів, а саме: учасники надають дозвіл на використання будь-яких їхніх патентів, які можуть стосуватися їхнього внеску.

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

Різниця між ліцензіями Apache 1.0 та Apache 1.1, Apache 2.0 полягає в тому, що з версії 1.0 прибрали вимогу про те, що всі рекламні матеріали проєкту повинні містити повідомлення «This product includes software developed by the Apache Group* for use in the Apache HTTP server project (www.apache.org).» В пізніших версіях достатньо просто помістити ліцензію в корінь вашого репозиторію.

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

Популярність цієї ліцензії постійно зростає, не в останню чергу, тому що цей тип ліцензії вибраний як обов’язковий для проєктів Cloud Native Computing Foundation.

Проєкти, що використовують Apache 2.0: Kubernetes, Selenium, TensorFlow.

BSD (Berkeley Source Distribution)

Дозвільна ліцензія для open source, яка зберігає повідомлення про ліцензію та авторські права. Ліцензія дозволяє розповсюджувати більші або ліцензовані твори без вихідного коду та за іншими умовами ліцензії. Ліцензія 2-Clause BSD License дуже схожа на ліцензію MIT.

Модифікована версія 3-Сlause BSD завдяки положенню про непідтримку, захищає вас/ контриб’ютора від використання вашого імені в проєкті, якщо ви цього не хочете.

Зокрема частина коду проєктів BSD які розповсюджуються під BSD або схожими ліцензіями використовуються в комерційному ПЗ Windows, macOS, iOS.

Проєкти, що використовують BSD: Flutter, libssh2.

MIT

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

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

Проєкти що використовують MIT: Visual Studio Code, Julia Language, Electron, Angular.js, Rails.

Public Domain (Creative Commons)

Ліцензія надає право користувачам поширювати, копіювати твори автора. Використовуються в тому числі на платформі YouTube для відеокреаторів.

Інші цікаві ліцензії, які я зустрічав

Do What The F*ck You Want To Public License — тут без коментарів, по суті ліцензію можна віднести до дозвільної.

The Unlicense

Розробники з однієї сторони витрачають час на вибір ліцензії, з іншої — цей тип ліцензії є copyleft, відповідно, явно буде юридичною проблемою в комерційному проєкті. Хоча треба відзначити, що ліцензія є в списку Рекомендованих (approved) ліцензій Open source initiative, і дійсно описує можливості щодо копіювання, модифікації та ін.

Open Government Licence — Canada

Державна ліцензія Канади для open source. За текстом ліцензію можна віднести до дозвільної (пермісивної). Як зазначається в файлах License, ліцензія також підпадає під «Crown Copyright».

Business Source License 1.1

Ліцензія від MariaDB Corporation, яка розвиває однойменний проєкт реляційної бази даних. Ліцензія цікава тим, що встановлює обмеження з використання проєкту тільки в невиробничому проєкті (non-production use of the Licensed Work).

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

Як щодо проєктів без ліцензії

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

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

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

Особливості ліцензування в компаніях. Правила для найманих працівників

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

Зокрема серед допустимих, як правило, додають пермітивні/ дозвільні ліцензії (Apache, MIT, BSD) або інші спеціальні ліцензії компаній. У більшості компаній/ організацій копірайт за замовчуванням — юридична назва. При створенні та внеску у відповідні проєкти інтелектуальні права можуть належати як окремим працівникам, так і передаватись компанії/ замовнику (на якій працює співробітник), якщо про інше не зазначено в договорі.

Наприклад, патентний захист охоплює певні процеси, продукти та методи; а авторські права захищають відповідний твір, в нашому випадку програмний код, графічні елементи, зображення. Зокрема в Cisco open source агрегаторах я і моя команда при розгляді і тестуванні проєктів перевіряємо, в тому числі наявність ліцензій, копірайтів та NOTICE файлів, якщо цього потребує ліцензія (Apache 2.0, GPLv3.0). У випадку, якщо проєкт розроблений співробітником або контрактором Cisco, існує політика додавання копірайту «Copyright © 2022 Cisco Systems, Inc. and/or its affiliates».

Розкажіть в коментарях які вимоги до ліцензій копірайтів існують в компаніях, в яких ви працюєте?

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

Крім того, перед поглинанням компанії або IPO, залучення інвестицій може проводитись Open source inventory (BoM), як результат можна отримати інформацію про залежності і ліцензії різних компонентів.

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

Звіти також містять інформацію про всі включені бібліотеки/ проєкти, в тому числі, враховуючи транзитивні залежності.

Частина MEND Dashboard

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

Автоматичне застосування шаблонів ліцензій

Раніше дуже багато open source проєктів публікувались без ліцензій, ситуацію в цьому напрямку змінилась після додавання відповідного функціоналу у GitHub. При створенні репозиторію можна вибрати ліцензію і в тексті, якщо це передбачає ліцензія, буде включений відповідний копірайт (підтягнеться ваше ім’я або назва організації). Наприклад для Apache 2.0 copyright повинен додаватись в окремий NOTICE файл, але файл автоматично не створюється.

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

У Gitlab також доступний функціонал вибору ліцензії, але функціонал доступний вже після створення репозиторію (а не під час, як у Github), і для цього треба спеціально зайти у розділ Ліцензія для репозиторію. Крім цього в GitLab для окремих ліцензій копірайт додається не у відповідний файл, а в текст ліцензії. А саме для ліцензій Apache 2.0, GPLv3.0 копірайт правильно додавати не в сам текст ліцензії, а в NOTICE файл. Для Apache 2.0 у тексті ліцензії в розділі Додаток, 189-190 рядок, вказано, яку саме інформацію треба вносити в NOTICE файл. Те ж саме для ліцензії GPLv3.0 рядок 633-635.

Інші платформи агрегатори open source проєктів також можуть пропонувати на вибір відповідні ліцензії або, як Google developers, обмежити вибір серед 6-9 найпопулярніших варіантів. Як правило, є загальна практика рекомендувати до використання ліцензію (окрім замінених) зі списку ​​Open Source Initiative.

Для комерційних компаній

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

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

Дуже багато комерційних організацій, некомерційних організацій створювали свої open source ліцензії з відповідними назвами:

• Common Public License (IBM).
• Eclipse.
• PHP License 3.01.
• Mozilla Public License 2.0 (використовує Terraform).
• W3C License (W3C).
• European Union Public License.
• Python License.

Для багатьох проєктів та продуктів важливо слідкувати за тим, які open source проєкти та під якими ліцензіями ви використовуєте.

Зокрема це обов’язковий етап у випадках:

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

За мій досвід роботи зі стартапами тільки один раз запитали про те, чи дозволяють ліцензії open source компонентів використовувати їх в комерційних рішеннях і які зобов’язання виникають при цьому.

На жаль, більшість аналізаторів проєктів (Open source inventory) застосовується власне перед зовнішніми вимогами, а не інтегровані в процес розробки. І тоді репорт про сумісність ліцензій може виглядати як невтішний діагноз лікаря, а умовне лікування у такому випадку може бути болісним — переписування компонентів, пошук заміни з відповідними ліцензіями/ патентами.

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

Сумісність ліцензій

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

Black Duck Audit Services виявив, що 53% перевірених кодових баз у 2021 році містили відкритий вихідний код з конфліктами ліцензій. 20% містило open source проєкти без ліцензій або кастомних ліцензій. Загалом 97% комерційного коду містить в собі різні частини та проєкти open source. Більшість ліцензій захищає та убезпечує авторів від можливих судових позовів або збитків, що можуть бути заподіяні під час використання open source компонентів та проєктів в комерційних продуктах.

Далі перерахую деякі приклади сумісності/ несумісності ліцензій.

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

Сумісність Microsoft Public License (Ms-PL) and Microsoft Reciprocal License (Ms-RL). Різниця між ними в тому, що Ms-RL — copyleft, відповідно ви можете модифікувати і використовувати файли до тих пір, поки зберігаєте вихідний код під Ms-RL ліцензією. Цікаво що більшість проєктів зараз розповсюджується під ліцензіями MIT та Apache-2.0

Ms-PL не сумісна з GNU GPL. (Ms-PL clause that enables to compile the program without distributing the source code.)

2-clause BSD та 3-clause BSD сумісні з GNU GPL.

Ліцензія Apache 2.0 сумісна з GPLv3, звичайно, за умови, якщо кінцеве програмне забезпечення має бути випущене під GPLv3.

Однак Apache 2.0 несумісна з GPLv2 через обмеження, яке припиняє надання на використання патентованої роботи, якщо судовим рішенням було визнано порушення патенту (пункт 7 GNU GPL-2.0).

Якщо ліцензії сумісні — між ними є стрілка, напрямок стрілки вказує на сильнішу ліцензію. Під «сильною» в тому числі розуміється ліцензія, яка по суті включає всі ключові умови іншої ліцензії.

Мультиліцензування

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

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

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

Приклад використання декількох ліцензій — мова програмування Perl. Має ліцензію GPL, яка розміщена в файлі Copying, також в кореневому каталозі розміщена ліцензія Artistic. В Readme зазначено про те, що можна поширювати та/або змінювати проєкт згідно з умовами однієї з ліцензій.

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

Як правильно додати кілька ліцензій до свого проєкту в GitHub? Для коректного відображення в GitHub вам потрібно додати файли ліцензії з відповідним текстом ліцензії всередині. І розмістіть файли в кореневому каталозі вашого проєкту.

В назві файлу на початку треба розмістити ключове слово License, наприклад: License.BSD, License_MIT.

Якщо проєкт включає форк або частини інших проєктів з різними ліцензіями

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

Приклади організації Kubernetes, Elasticsearch client license, CockroachDB.

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

Гарною практикою може бути додавання інформації про відповідну ліцензію та/або інформацію про копірайт у кожний файл з кодом.

Про зміну ліцензії або повну її відсутність

Чи можна змінювати ліцензію? Так, ліцензію можна змінювати, але при цьому зміну ліцензії треба погоджувати з усіма контриб’юторами проєкту. Навіть якщо це був контриб’ютор, який доповнював файл Readme. Тож добре, якщо ви це зробите на початку, коли ви єдиний контриб’ютор. Змінити ліцензію можна навіть на пропрієтарну ліцензію, але така зміна не має зворотної дії. Відповідно всі попередні версії/ релізи можуть використовуватись з ліцензіями, які були на той момент.

Є ряд ліцензій які вимагають випускати проєкт під такою ж ліцензією та версією, або пізнішою версією відповідної ліцензії (наприклад GNU LGPL).

А як щодо того, коли ліцензія взагалі відсутня? Це означає, що програма не має ліцензії на використання. І не важливо, плануєте ви використовувати проєкт в open source проєкті чи іншим чином.

Огляд юридичних кейсів

В українському Єдиному державному реєстрі судових рішень я не знайшов відповідних рішень, які пов’язані саме з конфліктом ліцензій або неправомірним використанням open source. Думаю, це пов’язано з тим, що більшість правовласників зареєстровані в інших юрисдикціях або домовляються вирішувати спори в інших країнах.

Найбільш релевантний кейс — це згадування про Media Player Classic для операційної системи Windows, як засобу для відтворення медіа в судовому засіданні. В судовому рішенні згадується, що плеєр розповсюджується за ліцензією GNU GPL.

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

Відомі та цікаві кейси:

• GOOGLE LLC v. ORACLE AMERICA, INC.

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

Android був поглинутий Google. У коді Android були використані методи Java API. В позові Oracle зазначали про порушення патентів і авторських прав стосовно Java SE. Суд відбувався в кілька етапів, з поновленням слухань в різних судових інстанціях. Рішення верховного суду США визначило, що використання підпадає під термін «fair use».

• Кейс з GitHub Copilot.

Наприклад, якщо ви навчаєте нейромережу або в ваш продукт включені приклади, які ліцензуються під free content license, які зобов’язання виникають в такому разі?

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

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

• Faker

Також був цікавий кейс, який напряму не повʼязаний з ліцензіями, але він підняв декілька питань стосовно відповідальності розробників open source проєктів, розповсюдження і використання комерційними компаніями open source проєктів.

Існувала NPM бібліотека Faker, яка була опублікована під ліцензією MIT (проєкт наразі вже недоступний). Бібліотека використовувалась в багатьох комерційних компаніях та інших open source проєктах (AWS CDK). Ліцензія передбачає комерційне використання, але в один момент розробник вирішив внести певні зміни, які при оновленні порушували нормальну роботу застосунків, в яких використовується проєкт.

Юридично MIT захищає авторів і розробників від можливих збитків та відповідальності «THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT...». Але з іншої сторони, внесені зміни та подальша комунікація від розробника розкрила те, що критичні зміни були внесені до проєкту через те, що багато комерційних компаній не оплачують роботу розробнику. Хоча проєкт був викладений github під публічною ліцензією вільною до користування.

Github згодом закрив доступ до репозиторію, що викликало певні питання від розробника та частини open source ком’юніті.

Замість висновку

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

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

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

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

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