загальна публічна ліцензія

Що таке GNU General Public License (GPL)?

GNU General Public License (або "GPL") — це одна з найвідоміших ліцензій для програмного забезпечення з відкритим кодом. Вона вимагає, щоб при використанні, зміні або розповсюдженні коду його вихідний код залишався відкритим і поширювався на тих самих умовах. GPL — одна з найвпливовіших ліцензій у сфері відкритого програмного забезпечення.

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

Які основні принципи GPL?

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

Головні принципи:

• Відкритість вихідного коду: при розповсюдженні виконуваних файлів необхідно надати доступ до відповідного вихідного коду.
• Безперервність ліцензії: похідні роботи залишаються під GPL.
• Збереження повідомлень: оригінальні авторські права та ліцензійні заяви мають залишатися незмінними.
• Відсутність гарантій: програмне забезпечення надається "як є", без гарантій від авторів.
• Патентні положення (v3): третя версія GPL містить окремі положення щодо патентного захисту.

Ядро Linux тривалий час використовує GPL-2.0 (станом на 2025 рік), це один із найвідоміших прикладів застосування GPL.

Як GPL впливає на розробку Web3?

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

Наприклад, якщо ваш dApp frontend інтегрує компонент із ліцензією GPL і ви розповсюджуєте виконувану версію користувачам, можливо, потрібно буде оприлюднити вихідний код фронтенду та зберегти всі оригінальні повідомлення. Це сприяє прозорості співпраці, але може обмежити закриті бізнес-моделі.

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

Як GPL застосовується до смартконтрактів?

Смартконтракти зазвичай пишуться мовою Solidity, а ліцензія вказується у верхній частині файлів через SPDX-License-Identifier (наприклад, "SPDX-License-Identifier: GPL-3.0-or-later"). Вимоги GPL щодо взаємної ліцензії створюють низку важливих аспектів для смартконтрактів:

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

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

Третє — поширена практика: багато команд обирають більш ліберальні ліцензії, такі як MIT чи Apache, для основних контрактів, щоб зменшити подальші зобов’язання. Якщо використовується GPL, надайте повний вихідний код, авторські права й інструкції зі збирання у репозиторії для полегшення аудиту та повторного використання.

Чим GPL відрізняється від ліцензій MIT та Apache?

Головна різниця між GPL, MIT і Apache полягає у силі взаємних зобов’язань.

• MIT: Як поширення рецепта із зазначенням автора — дуже ліберальна, не вимагає використання тієї ж ліцензії для похідних робіт. Підходить для закритих продуктів або подвійного ліцензування.
• Apache-2.0: Схожа на MIT, але містить окремі патентні гарантії та відмову від відповідальності — відповідає потребам підприємств.
• GPL: Вимагає взаємної ліцензії і підходить для проєктів, які прагнуть постійного обміну покращеннями у спільноті; більш обмежувальна для закритого розповсюдження.

Підсумок: обирайте GPL для максимальної відкритої співпраці та обов’язкового обміну покращеннями; обирайте MIT чи Apache для більшої гнучкості між відкритою та закритою комерціалізацією.

Як дотримуватися GPL у своєму проєкті?

Крок 1: Розмістіть файл LICENSE (повний текст GPL) у кореневій директорії репозиторію та зазначте ліцензійні деталі у README.

Крок 2: Додайте заголовок SPDX-License-Identifier (наприклад, "SPDX-License-Identifier: GPL-3.0-or-later") у верхній частині кожного вихідного файлу, щоб інструменти могли ідентифікувати ліцензію.

Крок 3: Зберігайте оригінальні авторські права та ліцензійні повідомлення; чітко позначайте власні зміни із датою, автором та коротким описом.

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

Крок 5: Перевіряйте сторонні залежності на сумісність ліцензій; за потреби використовуйте LGPL (більш підходить для бібліотек).

Крок 6: Проведіть перевірку відповідності перед запуском; зверніться до юриста, якщо передбачено комерційне використання, щоб мінімізувати ризики.

Які відмінності між версіями GPL?

Основні версії — v2 та v3:

• v2 (наприклад, ядро Linux): найстаріша й найвідоміша версія; не охоплює сучасні патентні питання або блокування пристроїв.
• v3: посилює патентні гарантії, додає положення проти Tivoization (запобігання блокуванню модифікованих версій пристроями) та умови щодо DRM — краще підходить для сучасних сценаріїв розповсюдження.

"Or later" vs "Only": вибір "GPL-3.0-or-later" дозволяє використовувати майбутні версії для більшої гнучкості; "only" фіксує версію для кращого управління сумісністю.

Додатково, LGPL призначена для бібліотек (дозволяє зв’язування на більш ліберальних умовах), а AGPL розширює вимоги відкритого коду на програмне забезпечення, що надається через мережу — бекенд-сервіси Web3 і фронтенди мають уважно враховувати тригери AGPL.

Чи можна використовувати GPL у комерційних цілях?

Так — GPL дозволяє комерційне використання. Проте при розповсюдженні похідних робіт із кодом GPL потрібно відкривати свій код і зберігати всі повідомлення. Типові стратегії для підприємств:

• Подвійне ліцензування: відкриття основного коду під GPL із паралельною комерційною ліцензією для корпоративних клієнтів.
• Модель сервісу: монетизація через хостинг, підтримку, аудит чи інтеграційні послуги при дотриманні відкритих вимог (зверніть увагу на особливі вимоги AGPL для використання через мережу).
• Відокремлення компонентів: ізоляція компонентів, які мають бути відкритими, від власної бізнес-логіки; використання LGPL чи власних альтернатив для бібліотек для мінімізації взаємних зобов’язань.

Які поширені ризики та хибні уявлення про GPL?

Поширені хибні уявлення:

• "GPL не можна використовувати комерційно" — неправда. Комерційне використання дозволено, але при розповсюдженні похідних робіт виникають обов’язки щодо відкриття коду.
• "Не потрібно дотримуватися, якщо не розповсюджуєш" — неповна інформація. Чи є розгортання розповсюдженням, залежить від контексту; розгортання на блокчейні чи в мережі може вважатися публічним релізом.
• "GPL можна вільно поєднувати з MIT/Apache" — обережно. Похідні відносини можуть вимагати застосування GPL до всього проєкту; уникайте змішування несумісних ліцензій.
• "Мінімальне використання уникає зобов’язань" — спосіб інтеграції коду (наслідування, статичне/динамічне зв’язування) може створити похідні роботи; потрібна перевірка відповідності.

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

Рекомендації та підсумок щодо вибору GPL

Якщо ваша мета — сприяння співпраці у спільноті, забезпечення повернення покращень і підтримка можливості аудиту, GPL — надійний вибір. Якщо потрібна більша свобода для закритих чи подвійних моделей ліцензування, MIT чи Apache забезпечують гнучкість. Забезпечте послідовне й відстежуване ліцензування для смартконтрактів і фронтендів — включайте LICENSE-файли та заголовки SPDX у репозиторії й стандартизуйте шляхи розповсюдження вихідного коду. Звертайте увагу на різницю між версіями, сумісність залежностей і чи є ваш випадок розповсюдженням або похідною роботою. Завжди проводьте перевірку відповідності та консультуйтеся з юристом перед комерціалізацією. Чітка ліцензійна стратегія дозволяє досягти надійної співпраці та відповідності регуляторним вимогам у екосистемі Web3.

FAQ

Чи можна використовувати код із ліцензією GPL безпосередньо у комерційних проєктах?

Так — але потрібно також відкривати похідний код як open source. "Віральний" принцип GPL означає, що якщо ви створюєте продукт на основі GPL-коду й продаєте його, ви зобов’язані оприлюднити вихідний код на тих самих умовах ліцензії. Ця вимога робить GPL несумісною із закритими бізнес-моделями. Якщо ваш бізнес залежить від збереження коду в таємниці, краще використовувати бібліотеки з ліцензією Apache чи MIT.

Які юридичні ризики виникають при посиланні на смартконтракт із GPL у Web3-проєкті?

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

Чому кажуть, що GPL "заражає" проєкт?

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

Якщо мій проєкт лише викликає API бібліотеки GPL, чи потрібно відкривати код проєкту?

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

Що буде, якщо використовувати код із GPL та MIT у одному проєкті?

Потрібно дотримуватися обох ліцензій — це може бути складно. GPL вимагає відкриття всіх похідних робіт; MIT дозволяє закритий код — ці умови суперечать одна одній. На практиці проєкт має підпорядковуватися "жорсткій" ліцензії (GPL) для сумісності. Уникайте змішування ліцензій або чітко розділяйте модулі за типом ліцензії для спрощення відповідності.