Что такое open source с точки зрения авторского права
Программный код — объект авторского права в России. Охрана возникает в момент создания кода, независимо от его публикации или регистрации (статья 1259 ГК РФ). Open source не означает «без автора» или «можно использовать свободно». Автор сохраняет исключительное право (статья 1270 ГК РФ) и лишь предоставляет лицензию — разрешение на определённые способы использования при соблюдении условий.
Лицензия на open source — это публичная оферта. Правообладатель предлагает неограниченному кругу лиц использовать код на условиях, прописанных в лицензионном тексте. Принятие оферты происходит в момент, когда пользователь начинает использовать код. С этого момента он обязан соблюдать все условия лицензии — независимо от того, читал ли он её.
Существует два принципиально разных семейства open source лицензий. Первое — разрешительные (permissive): MIT, BSD, Apache 2.0. Они позволяют использовать, изменять и распространять код почти без ограничений, требуя лишь сохранить уведомление об авторстве. Второе — лицензии с условием copyleft: GPL, LGPL, AGPL, MPL. Они требуют, чтобы производные произведения распространялись на тех же условиях.
Неочевидный риск состоит в том, что одна и та же библиотека может выходить под несколькими версиями лицензии одновременно. GPLv2 и GPLv3 — разные лицензии с разными условиями. Apache 2.0 совместима с GPLv3, но несовместима с GPLv2. Эта деталь регулярно становится источником нарушений в корпоративных продуктах.
Какие риски несёт коммерческое использование open source?
Использование open source компонента без соблюдения условий лицензии нарушает исключительное право автора по статье 1270 ГК РФ. Роспатент не является стороной в таких спорах — они рассматриваются арбитражными судами или Судом по интеллектуальным правам (СИП). Правообладатель вправе требовать компенсацию по статье 1301 ГК РФ: от 10 000 до 5 000 000 рублей либо двукратную стоимость права использования — по выбору правообладателя.
Три ключевых сценария нарушения в коммерческих проектах:
- Встраивание GPL-библиотеки в закрытый (проприетарный) продукт без раскрытия исходного кода — нарушение условия copyleft.
- Удаление или изменение уведомления об авторстве при использовании MIT- или BSD-кода — нарушение минимального требования разрешительной лицензии.
- Использование AGPL-компонента в SaaS-сервисе без публикации кода — AGPL распространяет действие copyleft на сетевое использование, что отличает её от GPL.
Уголовная ответственность по статье 146 УК РФ наступает при ущербе свыше 100 000 рублей — сумма достигается быстро, если нарушение касается коммерческого продукта с выручкой. На практике уголовные дела по open source редки, но их число растёт по мере того, как правообладатели — в том числе иностранные фонды — начинают активнее защищать права в российских судах через представителей.
Отдельный риск — санкционный контекст. Ряд open source проектов с 2022 года добавили в лицензии ограничения для пользователей из определённых юрисдикций. Формально такие условия спорны с точки зрения классической концепции open source, однако их нарушение создаёт репутационные и юридические риски при выходе на международные рынки.
Если в коде присутствуют open source компоненты с нераскрытыми лицензиями, риск претензий правообладателей реален уже сейчас. MARQA проведёт аудит зависимостей, составит реестр лицензий, выявит конфликты и подготовит план устранения нарушений.
Как работает лицензионное заражение и когда оно опасно?
Лицензионное заражение (copyleft contamination) — механизм, при котором условия лицензии GPL или её производных распространяются на весь продукт, включающий соответствующий компонент. Правовая основа — статья 1286 ГК РФ: лицензионный договор определяет объём разрешённых способов использования; выход за его рамки автоматически нарушает исключительное право.
Степень «заражения» зависит от типа copyleft:
| Лицензия | Тип copyleft | Что затрагивает | Коммерческое использование |
|---|---|---|---|
| MIT, BSD, Apache 2.0 | Отсутствует | Только уведомление об авторстве | Разрешено |
| LGPL v2.1 / v3 | Слабый copyleft | Только изменения самой библиотеки | Разрешено при динамической линковке |
| GPL v2 / v3 | Сильный copyleft | Весь продукт, включающий компонент | Требует раскрытия всего кода |
| AGPL v3 | Сетевой copyleft | Продукт + сетевое использование (SaaS) | Требует раскрытия кода сервиса |
| MPL v2 | Файловый copyleft | Только изменённые файлы | Разрешено при сохранении файлов MPL |
На практике важно учитывать способ включения компонента. LGPL-библиотека при статической линковке «сливается» с кодом продукта и может повлечь те же последствия, что и GPL. При динамической линковке риск ниже — но это предмет судебного толкования, а не однозначного правила. Каждый конкретный случай требует анализа архитектуры продукта.
Разработчик корпоративного CRM-решения из Центрального федерального округа (весна 2024 года) обратился за помощью после получения претензии от немецкого правообладателя GPL-компонента. В продукте использовалась одна библиотека под GPLv3 — без публикации кода. Правообладатель требовал либо немедленного раскрытия исходников, либо выплаты компенсации свыше 3 миллионов рублей.
MARQA провела аудит архитектуры, подготовила правовую позицию и сопровождала переговоры. Компания заменила компонент на Apache 2.0-аналог и закрыла претензию без выплаты компенсации, завершив работу в течение 6 недель.
Как проверить совместимость лицензий перед выпуском продукта?
Проверка совместимости лицензий — обязательный этап перед любым коммерческим релизом. Она не требует специальных технических навыков, но требует системного подхода: составить реестр зависимостей, определить условия каждой лицензии, затем проверить попарную совместимость. Пропуск хотя бы одного транзитивного компонента сводит на нет всю проверку.
Чек-лист: что подготовить перед аудитом лицензий
- Полный список прямых зависимостей с версиями (package.json, requirements.txt, pom.xml или аналог).
- Дерево транзитивных зависимостей — инструменты npm ls, pip-tree, mvn dependency:tree.
- Тексты лицензий каждого компонента (файл LICENSE или NOTICE в репозитории).
- Описание архитектуры продукта: статическая или динамическая линковка, SaaS или desktop, открытый или закрытый дистрибутив.
- Коммерческая модель: продажа лицензии, подписка, open core — определяет применимые ограничения.
Для автоматизации используются специализированные инструменты: FOSSA, Black Duck (Synopsys), TLDR Legal, OSS Review Toolkit. Они сканируют репозиторий и формируют отчёт о лицензионных конфликтах. Тем не менее автоматический сканер не заменяет юридический анализ: он указывает на проблему, но не определяет правовые последствия и способы их устранения.
Отдельного внимания заслуживает ситуация, когда компания одновременно использует open source и сама публикует свой код. В этом случае необходимо убедиться, что входящие лицензии совместимы с выбранной исходящей лицензией. Частая ошибка — публикация кода под MIT, в котором присутствуют GPL-зависимости: такое распространение нарушает условия GPL.
Материалы по теме: депонирование авторского произведения как дополнительный инструмент фиксации прав на программный код, а также авторские права на иллюстрации — смежная практика в части охраны цифровых активов.
Если правообладатель направил претензию или потребовал раскрыть исходный код, важно быстро оценить позицию и выбрать стратегию. MARQA проведёт правовой анализ ситуации, оценит обоснованность требований и подготовит ответ на претензию либо план замены проблемного компонента.
Стратегии снижения open source рисков для разных типов бизнеса
Выбор стратегии управления open source рисками зависит от типа бизнеса, стадии продукта и ресурсов команды. Три основных подхода — превентивный аудит, политика допустимых лицензий и коммерческое лицензирование — применяются с разной интенсивностью в зависимости от масштаба.
| Тип бизнеса | Ключевой риск | Рекомендуемый инструмент | Ориентировочные затраты |
|---|---|---|---|
| ИП / стартап, MVP | GPL-компонент в закрытом коде | Политика допустимых лицензий (whitelist) | Юридический консалтинг от 15 000 руб. |
| ООО, коммерческий SaaS | AGPL в сетевом продукте | Аудит зависимостей + замена компонентов | Аудит от 40 000 руб. |
| Группа компаний, enterprise | Транзитивные зависимости, M&A-риски | Автоматизированный SAST + юридическое сопровождение | Комплексный аудит от 150 000 руб. |
Для стартапа на стадии MVP достаточно составить whitelist — список разрешённых лицензий (MIT, BSD-2, BSD-3, Apache 2.0, ISC). Любой компонент, не входящий в список, требует отдельного анализа перед подключением. Это простейший контроль, который занимает несколько часов, но закрывает большинство типичных рисков.
Для коммерческого SaaS-продукта критична регулярность: аудит лицензий следует проводить перед каждым мажорным релизом и при добавлении новых зависимостей. Многие правообладатели меняют лицензию при выходе новой версии библиотеки — обновление зависимости без повторной проверки лицензии создаёт новый риск.
Для крупных компаний и групп, проходящих M&A-сделки, open source является стандартным предметом юридического due diligence. Покупатель проверяет лицензионную чистоту кода — наличие GPL-компонента в ключевом продукте может стать блокирующим условием или снизить оценку актива. Подробнее о защите авторских прав в цифровых проектах — в нашем обзоре практики по авторским правам.
Существует и превентивная мера — коммерческое лицензирование. Ряд правообладателей GPL-проектов предлагает коммерческую лицензию за вознаграждение: она снимает условие copyleft и позволяет включать компонент в закрытый продукт. Это называется dual licensing. Затраты на коммерческую лицензию, как правило, значительно ниже потенциальной компенсации по статье 1301 ГК РФ.
Уральская IT-компания (зима 2025 года), готовившаяся к привлечению инвестиций от фонда, обратилась за аудитом интеллектуальной собственности. В ходе анализа выявлено 4 AGPL-компонента в ядре SaaS-платформы, генерировавшей свыше 40 миллионов рублей годовой выручки. Инвестор уже включил вопрос о лицензиях в перечень условий сделки.
MARQA подготовила план замены компонентов с временными рамками, разработала лицензионную политику и сопроводила переговоры с инвестором. Сделка состоялась в плановые сроки — инвестор получил подтверждение лицензионной чистоты продукта.
Разобрали типичные нарушения по видам лицензий — с примерами последствий и способами устранения. Подходит для разработчиков и продукт-менеджеров.
Напишите «open source» в Telegram @nk_vitvet или WhatsApp — пришлём сразу.
Главный вывод этого материала: open source — не зона без права. Исключительное право автора охраняется статьёй 1270 ГК РФ независимо от способа публикации кода. Коммерческое использование компонента без соблюдения условий лицензии — нарушение, которое влечёт компенсацию до 5 миллионов рублей и обязанность раскрыть исходный код продукта. Превентивный аудит обходится в десятки раз дешевле, чем устранение последствий претензии.
MARQA специализируется на юридическом сопровождении IT-проектов: аудит лицензий open source компонентов, разработка лицензионной политики компании, подготовка ответов на претензии правообладателей и сопровождение при M&A-проверках интеллектуальной собственности. Дополнительно: защита бренда через Мадридскую систему для компаний, выходящих на международные рынки.
open source
под ключ.
Выявим проблемные компоненты, оценим риски и подготовим план устранения нарушений. Первая консультация — бесплатно, ответ в течение 2 часов.
+7 (983) 510-38-76 · Пн–Пт 9:00–20:00, Сб 10:00–15:00
- Лицензии и франшизы — лицензионные договоры, коммерческая концессия, сублицензии
- IP-аудит при M&A — проверка лицензионной чистоты ИС перед сделкой
- Споры — ППС, СИП — оспаривание претензий и защита в суде по ИС
Использование open source библиотеки в коммерческом продукте допустимо только в соответствии с условиями конкретной лицензии: лицензии MIT, BSD и Apache 2.0 разрешают коммерческое использование при сохранении уведомления об авторстве, тогда как лицензии GPL и AGPL требуют раскрыть весь исходный код производного продукта. Применение GPL-компонента в закрытом коммерческом ПО без соблюдения этого условия нарушает исключительное право автора по статье 1270 ГК РФ и влечёт компенсацию от 10 000 до 5 миллионов рублей.
Лицензионное заражение — это механизм лицензий с условием copyleft (GPL, LGPL, AGPL, MPL), при котором производное произведение обязано распространяться на тех же условиях, что и исходный компонент. Если в коммерческий продукт включён хотя бы один GPL-компонент, весь продукт юридически становится обязанным к публикации под GPL. На практике это означает принудительное раскрытие исходного кода и потерю конкурентного преимущества.
Нарушение условий open source лицензии в России квалифицируется как нарушение исключительного права автора по статье 1270 ГК РФ. Правообладатель вправе требовать компенсацию по статье 1301 ГК РФ: от 10 000 до 5 миллионов рублей либо двукратную стоимость права использования. Суд при определении суммы учитывает характер нарушения, выручку нарушителя и степень вины. Уголовная ответственность наступает при ущербе свыше 100 000 рублей по статье 146 УК РФ.
Проверку совместимости open source лицензий следует проводить в три шага: сначала составить реестр всех сторонних компонентов с указанием их лицензий, затем проверить каждую лицензию на наличие условия copyleft и ограничений на коммерческое использование, после чего оценить совместимость пар лицензий — например, Apache 2.0 несовместима с GPLv2. Для автоматизации используются инструменты FOSSA, Black Duck или TLDR Legal. При любых сомнениях — юридический аудит компонентов до выхода продукта на рынок.
Депонирование программного кода в Роспатенте или у аккредитованного депозитария фиксирует факт существования произведения на конкретную дату и помогает доказать приоритет при споре об авторстве, однако не защищает от претензий правообладателей open source компонентов. Если в задепонированный код включён GPL-компонент без соблюдения условий лицензии, это само по себе является нарушением исключительного права. Депонирование и аудит лицензий — самостоятельные и взаимодополняющие инструменты правовой защиты.