Общедоступная лицензия

Что такое GNU General Public License?

GNU General Public License (GPL) — одна из самых распространённых лицензий для открытого программного обеспечения, включая версии GPLv2 и GPLv3. Она разрешает использовать, изменять и распространять код, но требует, чтобы любые производные работы также оставались открытыми и использовали аналогичные лицензионные условия.

В экосистеме Web3 GPL применяется к блокчейн-клиентам, репозиториям смарт-контрактов, фронтендам децентрализированных приложений (dApp) и инструментам разработки. Например, клиент Ethereum Geth использует семейство лицензий GPL, что определяет его правила использования и распространения.

Как действует GNU General Public License в Web3?

В Web3 GPL выполняет две ключевые задачи: поддерживает открытость исходного кода и формирует условия для сотрудничества и конкуренции. Проекты на GPL обязаны сохранять форки открытыми, что повышает прозрачность и облегчает аудит.

Для разработчиков GPL способствует обмену улучшениями и снижает дублирование работы. Для команд проектов эта лицензия напрямую влияет на бизнес-стратегии: определяет, какие компоненты могут быть закрытыми, когда открывать исходный код и как управлять брендом и операциями. В отрасли часто сначала используют более ограничительную лицензию, а затем переходят на GPL-3.0 в определённую дату (например, в 2023 году), чтобы обеспечить соответствие форков и стимулировать вторичные инновации.

Ключевые положения GNU General Public License

Главный принцип GPL — “copyleft”: если вы используете или изменяете код, лицензированный по GPL, и распространяете свои изменения, вы обязаны публиковать исходный код на тех же условиях и сохранять авторские права и отказ от ответственности оригинального автора.

“Производные работы” — это разработки на основе исходного кода. Например, если вы добавляете маршрутизацию и комиссионную логику в контракт децентрализованной биржи и запускаете свою версию, это считается производной работой. Если вы распространяете копии или бинарные файлы, вы обязаны предоставить исходный код и информацию о лицензии.

GPL также содержит пункт “без гарантии”, согласно которому код предоставляется “как есть”. В GPLv3 добавлены положения о патентах и обходе ограничений (например, DRM), что снижает юридические риски.

Чем GNU General Public License отличается от лицензий MIT и Apache?

Главное отличие GPL — принцип copyleft, который требует, чтобы все последующие распространения оставались открытыми и использовали ту же лицензию. Лицензии MIT и Apache-2.0 более либеральны: они разрешают использование в коммерческих продуктах с закрытым исходным кодом при условии сохранения уведомлений об авторских правах и лицензии.

По совместимости лицензии Apache-2.0 и GPLv3 обычно считаются совместимыми, но возможны конфликты с “GPLv2 only”. Выбор лицензии должен соответствовать целям вашей команды: MIT/Apache — для максимальной коммерческой гибкости, GPL — для гарантии, что вклад сообщества останется открытым. По данным GitHub Octoverse 2023, лицензии MIT, Apache и GPL наиболее популярны в отрасли.

Как использовать GNU General Public License в смарт-контрактах?

В файлах Solidity рекомендуется явно указывать идентификатор SPDX и добавлять файл LICENSE в корень репозитория, соответствующий используемой версии:

// SPDX-License-Identifier: GPL-3.0-or-later

Во-первых, убедитесь, что библиотеки, на которые опирается ваш контракт, совместимы с GPL, чтобы избежать смешивания несовместимых лицензий. Во-вторых, синхронизируйте LICENSE, NOTICE и авторские права в репозитории перед публикацией. В-третьих, публикуйте скрипты сборки и инструкции для воспроизведения экспериментов — это облегчает аудит и повторение работы сообществом.

Во время проверки проектов и аудита контрактов на Gate команды обычно сверяют идентификаторы SPDX и лицензии репозиториев, чтобы подтвердить отсутствие конфликтов в зависимостях и минимизировать риски несоблюдения требований после запуска.

Как GNU General Public License влияет на форки и коммерциализацию?

Выбор GPL означает, что форки также должны оставаться открытыми, что снижает барьеры для новых участников и повышает эффективность сотрудничества в экосистеме. Коммерциализация не ограничивается продажей закрытого программного обеспечения; она может включать управляемые сервисы, брендинг, операции, токены управления и поддержку экосистемы. Конкурентное преимущество смещается от “закрытого кода” к продукту и сетевым эффектам.

В Web3 ведущие протоколы иногда переводят отдельные версии на GPL-3.0 после определённого периода, что приводит к появлению соответствующих форков и новых функций. Такой подход способствует инновациям и конкуренции в рамках прозрачной лицензионной политики, но требует от команд заранее продумывать вопросы бренда, доменов фронтенда, ликвидности и управления сообществом, чтобы избежать быстрой потери уникальности из-за форков.

Связь между GNU General Public License, AGPL и LGPL

AGPL (Affero General Public License) — более строгий вариант для “сетевого использования”: если пользователи взаимодействуют с вашим ПО через сеть, вы должны предоставить доступ к исходному коду. Это особенно важно для фронтендов Web3, сервисов индексирования и шлюзов данных. Если ваш dApp-фронтенд использует компоненты AGPL и размещён как публичный сервис, вы также обязаны публиковать соответствующий исходный код.

LGPL (Lesser General Public License) больше подходит для библиотек и компонентов: она разрешает связывание с закрытыми приложениями при условии, что изменения в самой библиотеке LGPL публикуются в открытом доступе. Основное приложение может оставаться закрытым. Для кошельков или плагинов узлов LGPL позволяет сохранить открытость библиотек и использовать закрытые приложения.

Этапы соблюдения GNU General Public License

Шаг 1: Подтвердите версию и совместимость. Ясно укажите GPLv2, GPLv3 или “или более поздняя”, и проверьте совместимость зависимостей с выбранной версией.

Шаг 2: Сохраняйте авторские права и лицензионные заявления. Оставляйте сведения об оригинальных авторах и текст лицензии в исходных файлах и README, добавляя NOTICE при необходимости.

Шаг 3: Открывайте производные работы. Предоставляйте пользователям полный исходный код, скрипты сборки и инструкции по установке, чтобы другие могли воспроизвести вашу работу.

Шаг 4: Явно указывайте идентификаторы SPDX. Вставьте строку SPDX в каждый ключевой исходный файл и разместите файл LICENSE в корне репозитория для единообразия.

Шаг 5: Различайте распространение и использование. Публикация бинарных файлов, образов или пакетов программного обеспечения приводит к возникновению обязательств; внутренняя разработка обычно не требует этого. Является ли размещение байткода в блокчейне “распространением” — вопрос интерпретации, обратитесь к юристам для уточнения.

Шаг 6: Документируйте Software Bill of Materials (SBOM). Перечисляйте все зависимости и их лицензии для упрощения аудита и проверки на платформах вроде Gate.

Риски и рекомендации по соблюдению GNU General Public License в Web3

Основные риски — конфликты лицензий и невыполнение обязательств: использование несовместимых лицензий, непубликация производных работ или отсутствие информации об авторских правах и отказе от ответственности может привести к удалению кода (например, по DMCA), затруднить сотрудничество или нанести ущерб репутации бренда.

Рекомендации: выбирайте лицензии, соответствующие бизнес-целям на старте проекта; используйте комбинированные стратегии, например, AGPL для фронтендов или MIT/Apache для сервисов; ведите SBOM и чек-листы соответствия; проводите сторонние аудиты до запуска; консультируйтесь с юристами по критическим вопросам. Проекты, планирующие масштабирование на торговых платформах, должны заранее уделять внимание лицензионным вопросам, чтобы избежать операционных проблем в будущем.

Основные выводы по GNU General Public License

GPL обеспечивает открытость исходного кода благодаря принципу copyleft — это оптимально для Web3-проектов, желающих, чтобы улучшения сообщества возвращались в экосистему. В отличие от MIT/Apache, GPL сильнее ориентирована на открытость производных работ; по сравнению с AGPL/LGPL — больше подходит для локальных сценариев распространения. Корректное использование идентификаторов SPDX, файлов LICENSE, SBOM, а также аудит и чёткая бизнес-стратегия позволяют командам сочетать открытость с коммерческой эффективностью.

FAQ

Мой проект использует открытый код под GPL, но я хочу сделать его закрытым или коммерческим в будущем. Это разрешено?

Нет. GPL требует, чтобы производные работы также оставались открытыми под той же лицензией — это принцип copyleft. Если ваш проект содержит код под GPL, весь проект должен быть открытым. Если вы хотите коммерциализировать закрытое программное обеспечение, заранее проверьте лицензии зависимостей или получите разрешение оригинального автора на двойное лицензирование.

Могу ли я скопировать код проекта под GPL в свой приватный проект, если не буду его публиковать?

В теории приватное использование не нарушает GPL; однако при распространении или развертывании (включая онлайн-сервисы) необходимо соблюдать требования открытости. Многие разработчики игнорируют это и сталкиваются с юридическими рисками. Лучше заранее определить лицензионную стратегию, чтобы избежать сложных изменений в будущем.

Если я изменяю код под GPL, но не публикую новую версию, обязан ли я раскрывать исходный код?

Если используете код только внутри компании и не распространяете его, публиковать исходный код не требуется. Но если предоставляете модифицированное ПО пользователям или клиентам — либо через сетевые сервисы — необходимо предоставить исходный код и описание изменений. Это особенно важно для SaaS-проектов.

Можно ли реально применять GPL в Web3 или смарт-контрактах?

Юридическая применимость GPL зависит от юрисдикции; в Web3 она менее надёжна, поскольку развертывания в блокчейне трудно отслеживать, а майнеры и узлы не могут легко проверить соблюдение лицензии. Нарушение GPL может привести к негативной реакции сообщества или появлению форков, что повредит репутации проекта — даже если юридические последствия ограничены. Рекомендуется соблюдать GPL, чтобы сохранить доверие к проекту.

Могу ли я выпустить свой проект одновременно под GPL и другими лицензиями?

Да — это называется двойным или мультилицензированием. В open-source-сообществах этот подход часто используется: например, можно предложить бесплатную версию под GPL и коммерческую версию по другой лицензии (за плату). Разные лицензии могут конфликтовать, поэтому чётко указывайте, какая версия использует какую лицензию в документации проекта, чтобы избежать путаницы у пользователей.