Лицензии open source: что можно и нельзя и как избежать юридических рисков

Лицензии open source - это юридические условия, по которым вы можете использовать, модифицировать и распространять чужой код. Почти всегда "можно" включает коммерческое применение, а "нельзя" - игнорировать требования об уведомлениях, текстах лицензий и (для copyleft) раскрытии исходников при распространении. Минимизируйте юридические риски open source через учёт компонентов, проверку совместимости и корректную поставку лицензий.

Кратко о юридической сути лицензий OSS

Лицензия OSS - это договор-оферта: права появляются при соблюдении условий, а не "по умолчанию".
Главные обязательства: сохранение уведомлений об авторских правах, включение текста лицензии, корректная атрибуция.
Copyleft-лицензии (например, GPL) добавляют условие: при распространении производного произведения нужно раскрывать исходники на условиях той же лицензии.
Риск обычно возникает не от использования в разработке, а от распространения (поставка клиенту, публикация контейнера/аппстора, отдача образа устройства).
"Безопасность" зависит от сценария интеграции: линковка, встраивание, копирование кода, плагины, статическая сборка.

Как работают лицензии open source: базовая логика и термины

Open source лицензии дают вам разрешение на действия, которые иначе требовали бы отдельного согласия правообладателя: копирование, модификацию, распространение. Это не "передача собственности" на код, а набор условий, которые нужно выполнить, чтобы право на использование было законным.

Ключевые термины, которые важно различать: использование (run/use), распространение (distribution/conveying), производное произведение (derivative work), комбинированное произведение (combined work), атрибуция (notices/credits), исходный код (source) и объектный код (binary). В большинстве ситуаций обязанностей меньше, пока вы не начали распространять продукт за пределы организации.

Лицензирование open source почти всегда сводится к двум вопросам: (1) что вы сделали технически (встраивание, линковка, копирование файлов), (2) что вы сделали юридически (распространили или нет, и в каком виде). На пересечении этих ответов и возникают требования лицензии.

Мини-сценарии (как это выглядит в жизни)

Внутренний сервис: вы используете библиотеку под GPL только на своих серверах и не отдаёте бинарники клиентам. Обычно требования о предоставлении исходников при этом не запускаются, но уведомления и тексты лицензий в репозитории хранить стоит.
Мобильное приложение: вы включили OSS-библиотеки в APK/IPA и публикуете в стор. Это распространение: обязаны включить notices/лицензии, а при copyleft - оценить обязанность раскрытия исходников производного приложения.
On‑prem поставка: вы отдаёте клиенту контейнер-образ или инсталлятор. Это распространение: нужно приложить лицензии/уведомления и подготовить пакет исходников, если условия требуют.

Зафиксируйте, где заканчивается "использование" и начинается "распространение".
Опишите техническую форму интеграции (копирование кода, линковка, отдельный процесс).
Собирайте и храните тексты лицензий и copyright-notice для каждого компонента.
Проверяйте, нет ли ограничений на товарные знаки/патенты (актуально для некоторых лицензий).

Разрешённые и запрещённые действия в популярных лицензиях: MIT, Apache 2.0, GPL, LGPL, MPL

На практике различия между лицензиями проявляются в трёх плоскостях: (1) обязанность сохранять уведомления и текст лицензии, (2) требования к раскрытию исходников при распространении, (3) патентные условия и ограничения на использование брендов. Ниже - прикладная "механика", которая чаще всего влияет на продуктовые релизы.

Лицензия	Можно использовать в коммерческом продукте	Нужно включать notices/текст лицензии при распространении	Нужно раскрывать исходники при распространении производного	Патентные условия (в общем виде)
MIT	Да	Да (сохранить copyright и текст лицензии)	Нет (если не приняли иных обязательств)	Обычно без явного патентного гранта
Apache 2.0	Да	Да (включая NOTICE при наличии)	Нет	Есть явный патентный грант и условия прекращения при патентных исках
GPL (сильный copyleft)	Да	Да	Обычно да, если распространяете производное/связанное произведение	Зависит от версии/формулировок, но обычно есть требования, связанные с патентами
LGPL (слабее copyleft)	Да	Да	Обычно да для модификаций самой библиотеки; для приложения - зависит от способа линковки и соблюдения условий relinking	Зависит от версии/формулировок
MPL 2.0 (file-level copyleft)	Да	Да	Да, но обычно в пределах изменённых файлов под MPL при распространении	Есть патентный грант в рамках вклада

Что обычно "можно"

Использовать, копировать и модифицировать код в составе продукта (включая коммерческий), если выполняете условия лицензии.
Распространять бинарники (и исходники), прикладывая требуемые уведомления и тексты лицензий.
Комбинировать компоненты, если лицензии совместимы и вы соблюдаете наиболее строгие применимые условия.

Что часто "нельзя" или опасно делать

Удалять/не включать copyright-notice, NOTICE-файл (если требуется) и текст лицензии в поставку.
Брать код "из GitHub" без лицензии и считать его open source: без лицензии прав на использование обычно нет.
Подмешивать сильный copyleft (например, GPL) в продукт так, что он становится производным, не планируя раскрытие исходников при распространении.
Игнорировать условия по патентам и товарным знакам (особенно в корпоративных поставках).

Для каждой библиотеки зафиксируйте: лицензия, версия, ссылка на исходный репозиторий/архив.
Проверьте, есть ли NOTICE и требования к атрибуции в документации/об "About".
Отдельно пометьте copyleft-компоненты (GPL/LGPL/MPL) и путь их попадания в релиз.
Сведите требования к "комплекту поставки": куда кладёте тексты лицензий и исходники (если нужно).

Коммерческое использование, модификации и распространение: реальные кейсы и правовые последствия

Большинство продуктов легально используют open source, но проблемы появляются, когда команда не различает "использую внутри" и "распространяю наружу", а также не управляет обязанностями по атрибуции и исходникам. Ниже - типовые ситуации, где юридические риски open source проявляются быстрее всего.

Кейс: SaaS без поставки. Вы используете OSS на сервере и продаёте доступ. Обычно обязаны соблюдать уведомления в кодовой базе и внутри организации; требования о передаче исходников часто не возникают, пока вы ничего не распространяете клиенту.
Кейс: поставка on‑prem. Вы отдаёте клиенту Docker-образы/установщик. Это распространение: подготовьте пакет лицензий/уведомлений и проверьте, не нужно ли предоставлять исходники (особенно при GPL/LGPL/MPL и при модификациях).
Кейс: форк библиотеки. Вы изменили OSS-библиотеку и включили в продукт. Для permissive лицензий обычно достаточно сохранить уведомления; для MPL/GPL/LGPL часто появляется обязанность предоставить исходники изменений (в рамках условий).
Кейс: копирование фрагмента кода. Разработчик копирует файл/функцию из проекта под copyleft в проприетарный репозиторий. Риск выше, чем при использовании как зависимости: это прямое создание производного произведения.
Кейс: OEM-устройство/прошивка. Вы поставляете устройство с прошивкой, где есть OSS. Это распространение, и требования к предоставлению исходников/уведомлений должны быть реализованы в процессах производства и поддержки.

Мини-контрпримеры (что ломает комплаенс)

В релизе нет третьесторонних лицензий, потому что "они в node_modules".
В документации написали "используем open source", но не указали компоненты и лицензии.
Исходники модифицированного компонента обещают "по запросу", но процесса выдачи нет.

Сопоставьте каждый канал доставки (app store, on‑prem, контейнер, SDK) с понятием "распространение".
Отделите "использую как зависимость" от "копирую код в свой репозиторий".
Если модифицировали OSS-компонент - заранее решите, как будете публиковать/предоставлять изменения.
Включите в Definition of Done проверку третьесторонних лицензий для релиза.

Слияние проприетарного кода с OSS: где возникают обязательства по раскрытию

Обязательства по раскрытию исходников возникают не из факта наличия OSS, а из условий конкретной лицензии и того, образует ли ваш продукт производное/комбинированное произведение при распространении. На практике критичны три технических точки: копирование кода, статическая линковка, "слишком тесная" интеграция в одном бинарнике.

Ситуации, где риск раскрытия выше

Копирование файлов/фрагментов из проекта под GPL в ваш проприетарный код.
Сборка единого бинарника с сильным copyleft-компонентом, где нет чёткой границы (особенно при распространении).
Встраивание компонента так, что ваш код и OSS образуют единое произведение (оценка всегда зависит от конкретики и условий лицензии).

Ситуации, где чаще удаётся ограничить обязательства

Лицензии open source: что можно, что нельзя и как избежать юридических рисков - иллюстрация

Разделение по процессам: OSS-компонент работает как отдельный сервис/демон, а взаимодействие идёт по API/IPC (при условии корректной архитектуры и отсутствия копирования кода).
Плагинная модель: ваш продукт загружает сторонние модули, и границы лицензий выдержаны (важны детали поставки и способ связывания).
Использование permissive лицензий (MIT/Apache 2.0) для библиотек, которые встраиваются в продукт.

Опишите интеграцию: один бинарник или отдельные процессы, статическая или динамическая линковка, копирование кода или зависимость.
Для copyleft-компонентов определите "единицу распространения": что именно вы отдаёте пользователю.
Не "лечите лицензией архитектуру": сначала проектируйте границы модулей, потом подтверждайте их юридически.
Если сомневаетесь - запланируйте консультацию по open source лицензиям до релиза, а не после.

Выбор лицензии и правила совместимости между компонентами

Совместимость - это не про "все open source дружат между собой", а про возможность одновременно выполнить условия нескольких лицензий в одном продукте и канале распространения. Ошибка в совместимости чаще всего проявляется в конце, когда релиз уже собран, а требование одной лицензии конфликтует с запретом другой.

Миф: MIT/Apache всегда совместимы со всем. Обычно они проще, но NOTICE/патентные условия Apache 2.0 могут влиять на документацию и юридические тексты поставки.
Ошибка: смешали разные copyleft-условия без плана. Даже "слабый" copyleft (LGPL/MPL) требует соблюдения условий по модификациям и форме поставки.
Ошибка: лицензия неизвестна или кастомная. "No license" или нестандартная лицензия в зависимости - это стоп-фактор для корпоративного использования, пока не будет правового основания.
Ошибка: транзитивные зависимости. Вы выбираете MIT-библиотеку, но внутри тянется компонент под GPL, и риск переносится в ваш продукт.
Миф: если библиотека динамически подключается, то copyleft не применим. Техническая форма важна, но автоматического "иммунитета" нет: проверяйте условия конкретной лицензии и сценарий распространения.

Мини-сценарий выбора

Если вы выпускаете проприетарный SDK для клиентов, обычно безопаснее заранее ограничить зависимости до permissive лицензий (MIT/Apache 2.0/BSD), а copyleft-компоненты изолировать в отдельный сервис, который не поставляется клиенту, либо заменить.

Соберите полный SBOM/перечень зависимостей, включая транзитивные.
Отметьте, что поставляется наружу (SDK, бинарник, контейнер, исходники, библиотека).
Проверьте совместимость лицензий именно в вашем способе поставки.
Утвердите "политику допуска" лицензий для проекта (allow/deny/needs-review).

Практики снижения рисков: аудит, документирование и автоматизация соответствия

Рабочий способ снизить риски - встроить аудит open source лицензий в жизненный цикл разработки: от PR до релиза. Цель - не "запретить OSS", а гарантировать, что обязательства исполнимы: вы знаете, что используете, и можете корректно включить лицензии/уведомления и исходники при необходимости.

Мини-кейс: релиз перед поставкой on‑prem

Собрали SBOM для релизной сборки.
Отметили компоненты с copyleft и проверили, что они не "утекли" в проприетарные модули через копирование кода или статическую сборку.
Сгенерировали пакет THIRD-PARTY-NOTICES и положили тексты лицензий в дистрибутив.
Подготовили процедуру выдачи исходников модифицированных компонентов (если требуется условиями).

Мини-псевдокод проверки в CI (логика, не инструмент)

# pipeline step: oss_compliance_check
deps = build.getDependencies(includeTransitive=true)
for d in deps:
  assert d.licenseDetected == true
  if d.license in ["GPL", "AGPL", "LGPL", "MPL"]:
    risk.register(d, reason="copyleft", owner="legal+tech")
  notices.collect(d.copyright, d.licenseText, d.noticeFile)
assert notices.bundleGenerated == true
assert policy.isCompatible(deps, distributionChannel=release.channel) == true

Что делать, когда нужна внешняя проверка

Если продукт поставляется enterprise-клиентам (on‑prem/SDK) и есть copyleft-зависимости.
Если в код попали фрагменты из чужих репозиториев без чётких метаданных лицензии.
Если планируется M&A/инвестраунд и потребуется юридическая чистота IP.

Автоматизируйте сбор перечня зависимостей и лицензий на каждый релиз.
Храните артефакты соответствия: SBOM, THIRD-PARTY-NOTICES, архивы исходников модификаций (если нужно).
Внедрите политику лицензий и процесс исключений с ответственными.
Периодически делайте консультацию по open source лицензиям для спорных архитектурных решений.

Самопроверка перед релизом (быстрый чек-лист)

Я знаю все зависимости, включая транзитивные, и их лицензии (нет "unknown/no license").
Я понимаю, что именно распространяю (бинарники/контейнер/SDK) и какие обязательства это запускает.
В поставку включены тексты лицензий и корректные уведомления (notices/атрибуция).
Copyleft-компоненты либо изолированы, либо для них подготовлен план предоставления исходников/изменений по условиям лицензии.
Есть повторяемый процесс (CI/релизный пайплайн), а не разовая ручная проверка.

Частые юридические сомнения разработчиков об open source

Можно ли использовать open source лицензии в коммерческом продукте?

Обычно да: большинство OSS-лицензий прямо разрешают коммерческое использование. Важно выполнить условия: атрибуция, включение текста лицензии, а для copyleft - правила раскрытия исходников при распространении.

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

Чаще всего обязанности по предоставлению исходников не возникают без распространения. Но хранить метаданные лицензий и соблюдать внутренние правила использования всё равно полезно для будущих релизов и аудитов.

Что считается распространением в контексте лицензирование open source?

Любая передача копии: бинарника, контейнера, прошивки, SDK или исходников третьей стороне. Публикация в app store и выдача установщика клиенту - типичные примеры.

Правда ли, что динамическая линковка всегда спасает от GPL-обязательств?

Нет, это упрощение: значение имеют условия конкретной лицензии и фактическая форма интеграции. Оценивайте, образуется ли производное/комбинированное произведение при распространении.

Нужно ли включать тексты лицензий в дистрибутив?

Почти всегда да, если вы распространяете продукт с OSS-компонентами. Минимум - сохранить copyright-notice и приложить текст лицензии; для Apache 2.0 часто важен NOTICE, если он есть у компонента.

Какие юридические риски open source самые частые?

Отсутствие атрибуции и текстов лицензий в поставке, неизвестные/несовместимые лицензии, попадание copyleft в проприетарный модуль без плана раскрытия. Эти ошибки обычно обнаруживаются при поставке enterprise-клиентам или при due diligence.

Когда нужен аудит open source лицензий?

Перед крупным релизом, перед on‑prem поставкой, при появлении copyleft-зависимостей и перед сделками/инвестициями. Аудит фиксирует состав компонентов, совместимость лицензий и набор артефактов соответствия.