Простой

11 мин

1

Код с пометкой «открытая лицензия» можно принять за что-то бесхозное — бери и используй. Такое ощущение регулярно приводит компании к судам, штрафам и принудительному раскрытию исходников. Разбираемся, как устроены права на открытый исходный код и какие правила в его отношении нельзя нарушать. 

Что такое Open Source

В основе открытого исходного кода лежит не благородная идея, а юридический механизм. Автор кода сохраняет авторские права в полном объёме. Но доступ к коду не закрывают, вместо этого автор выдаёт публичную лицензию — договор, разрешающий использовать код на определённых условиях. Нарушил условие — нарушил авторское право.

Open source лицензия не передаёт права на код, а разрешает пользоваться им в заданных рамках. Именно поэтому нельзя просто «взять GPL-библиотеку» и включить в проприетарный (закрытый коммерческий) продукт без последствий.

Похожие механизмы в авторском праве есть в целом — взять хотя бы открытые лицензии Creative Commons, на которых держится половина свободного интернета. 

Как это работает в США

В американском праве авторские права на программный код закреплены в разделе 17 Кодекса США (Copyright Act). Статья 106 этого закона даёт правообладателю исключительные права: 

• воспроизводить,

• создавать производные произведения,

• распространять копии. 

Без лицензии любое из этих действий с чужим произведением, в том числе кодом, незаконно.

Прецедентом, после которого авторские права стали полноценно распространяться и на программистов, можно назвать дело Jacobsen v. Katzer (2008). Роберт Якобсен разработал ПО для управления моделями поездов и распространял его под открытой лицензией Artistic License 1.0. Компания Katzer/Kamind взяла его код и встроила в свой продукт, не соблюдая условия лицензии (не указала авторство). 

Сначала суд решил, что это просто нарушение договора неисключительной лицензии, оно не несет непоправимого вреда и не наказывается строго. Апелляционный суд это решение отменил и признал, что условия open source лицензий — это полноценные обязательства авторского права, а не просто контрактные договорённости. Это решение открыло для open source разработчиков все инструменты Закона об авторском праве: запреты, компенсации, судебные издержки.

Как это работает в России

В российском праве программы для ЭВМ охраняются как произведения литературы — авторским правом по статье 1261 ГК РФ. Автор получает исключительное право, может разрешать или запрещать любое использование своего кода.

С 2014 года существует статья 1286.1 ГК РФ об открытой лицензии. Это такой «договор присоединения» — его условия доступны публично, в нем указано, какие действия его «подписывают» и другие детали. Согласие с лицензионным соглашением — классический пример. 

Нарушение условий соглашения аннулирует лицензию — и с этого момента использование кода становится нарушением авторских прав. Это означает полную ответственность по статье 1301 ГК РФ. 

Open Source vs. Общественное достояние

Нередко открытый код путают с общественным достоянием (Public Domain). Это принципиально разные вещи.

Так как программы для ЭВМ защищены авторским правом, эти права действуют всю жизнь автора и еще 70 лет после. Причем это сразу касается не только страны происхождения автора, но и всех участников Бернской конвенции. 

Код в общественном достоянии — редкость в современном ПО. SQLite, один из самых распространённых в мире движков баз данных, специально выложен авторами в публичное достояние через специальный механизм CC0. Но подавляющее большинство «бесплатного» кода — именно лицензированный open source с условиями.

В России статья 1233 ГК РФ позволяет правообладателю публично заявить о предоставлении безвозмездного права использования, но богатой судебной практики по этой части пока нет. 

Что нужно соблюдать в Open Source: разбираем кейсы

Open source проекты можно использовать свободно — но «свободно» не означает «без обязательств». У разных лицензий требования различаются. В них важно разобраться до того, как открытый исходный код попадет в продукт.

Все лицензии делятся на две большие группы:

1. Permissive («разрешительные») — MIT, Apache 2.0, BSD. Минимальные условия, которые в основном сводятся к указанию авторства;

2. Copyleft («копилефт») — GPL, LGPL, AGPL. Более жёсткие условия, требуют открыть производный код при распространении.

MIT и Apache: только укажи автора

MIT — одна из самых популярных лицензий в мире. Обычно её единственное значимое условие — сохранить оригинальное уведомление об авторских правах и текст самой лицензии при распространении кода (в исходном или переработанном виде). Не нужно открывать собственный код, не нужно делиться внесенными изменениями (патчами). Можно встроить MIT-библиотеку в проприетарный продукт и продавать его — при условии, что где-то в документации или интерфейсе есть упоминание об источнике.

Apache 2.0 добавляет к этому ещё одно требование. Если код модифицирован, нужно это явно указать. При этом Apache 2.0 содержит встроенную патентную лицензию, что делает её удобнее MIT для корпоративного использования.

На практике нарушения MIT/Apache — почти всегда небрежность, а не злой умысел: 

• разработчик забыл вложить файл LICENSE;

• файл потерялся при упаковке дистрибутива (такое тоже бывает). 

Серьезных судебных дел здесь нет, потому что правообладателям редко есть смысл судиться за указание авторства без финансового ущерба. Проанализировали 3 503 корпоративных репозитория и нашли 36 884 нарушений лицензий — большинство именно в «мягких» лицензиях вроде MIT и Apache. В большинстве случаев это не ведёт к суду автоматически, а создаёт правовой риск, который нарастает с масштабированием продукта. Сильно полагаться на MIT — одна из типичных ошибок «патентных нигилистов». 

GPL: если взял — открой или не распространяй

GPL (GNU General Public License) работает иначе. Если вы включаете GPL-код в свой проект, то весь производный продукт должен распространяться под той же лицензией — с открытым исходным кодом. На GPL распространялся Linux — и сначала такое распространение вообще вызывало споры о конституционности.

Важно, что требование срабатывает именно при «распространении третьим лицам». Это значит, что внутреннее использование GPL-кода без передачи продукта вовне ничего не значит. Компания может использовать GPL-инструменты для внутренней инфраструктуры и ничего не открывать — лицензионные обязательства возникают только при дистрибуции.

В России компоненты кода под такой «закрывающей лицензии» могут стать проблемой при регистрации ПО. 

Есть несколько типов GPL, и это отдельная проблема совместимости лицензий.

Кейс: VMware

В 2015 году разработчик ядра Linux Кристоф Хельвиг при поддержке организации Software Freedom Conservancy (SFC) подал иск против VMware в немецкий суд. Суть претензии — гипервизор VMware ESXi содержал GPL-код из ядра Linux, но VMware распространяла его в составе проприетарного продукта, не открывая исходники. По позиции истца, vmkernel — производное произведение от Linux, а значит должно распространяться под GPL.

VMware настаивала на том, что спорный компонент vmklinux взаимодействует с проприетарным ядром через специальный API и не составляет с ним единое целое.

Суд первой инстанции в Гамбурге отклонил иск — Хельвиг не смог идентифицировать конкретные строки кода, авторские права на которые ему принадлежат. Апелляция подтвердила отказ в 2019 году. Но главный вопрос — «является ли vmkernel производным произведением от Linux» — суд так и не рассмотрел по существу.

Однако после нескольких лет судов VMware убрала спорные компоненты из новых версий продукта. 

Дело показало, что показать нарушение GPL в суде технически сложно — нужно точно установить, какие именно строки кода были скопированы и кому принадлежат права на них.

Кейс: Orange (Франция)

Это дело стало, возможно, самым финансово значимым прецедентом по GPL в истории. Французская компания Entr'ouvert разработала библиотеку аутентификации Lasso под GPL v2. Крупнейший французский телеком Orange использовал эту библиотеку в государственном портале «Mon Service Public», внёс изменения в код, но не опубликовал ни исходники с изменениями, ни уведомление о том, что GPL-код вообще используется.

Апелляционный суд Парижа 14 февраля 2024 года признал Orange виновной. Итоговые выплаты составили около 860 000 евро:

• 500 000 евро — за нарушение авторских прав;

• 150 000 евро — моральный ущерб;

• 150 000 евро — возврат незаконно сэкономленных расходов на разработку;

• 60 000 евро — судебные издержки.

Судебный процесс небольшой компании-разработчика и гиганта телекоммуникаций занял 13 лет. 

LGPL: библиотека отдельно, ваш код — ваш

LGPL (Lesser GPL) создавалась специально для библиотек, которые должны работать совместно с проприетарным кодом. Главное отличие от GPL в том, что если вы просто подключаете библиотеку как внешний модуль к своему приложению, раскрывать исходники приложения не нужно. Обязательство возникает, только если вы модифицируете саму библиотеку и распространяете измененную версию.

Именно LGPL используется, например, в GNU C Library (glibc) — базовой библиотеке большинства Linux-систем. Если бы glibc распространялась под «сильным» GPL, любое коммерческое ПО для Linux стало бы юридически проблематичным.

Грань между «просто использую библиотеку» и «создаю производное произведение» в LGPL нередко размыта. Дело VMware косвенно касалось этой границы. VMware утверждала, что vmklinux — именно такой «прослоечный» модуль, аналогичный LGPL-логике, тогда как истец настаивал на полноценной интеграции.

AGPL: закрывает «облачную лазейку»

Как уже было сказано, у GPL есть существенный пробел — обязанность открыть исходники возникает только при распространении кода. Формально, если вы запускаете GPL-сервис в облаке и предоставляете к нему доступ через API или браузер, то технически вы ничего не «распространяете», и требование открыть код не срабатывает. Этой лазейкой пользовались крупные технологические компании, строя закрытые SaaS-продукты на базе открытого кода.

AGPL (Affero GPL) эту лазейку закрывает — обязательство открыть исходники возникает не только при дистрибуции, но и при предоставлении доступа к ПО через сеть. Компания, запустившая AGPL-сервис для пользователей, обязана опубликовать исходники.

Именно поэтому многие компании (MongoDB, Elastic) переходили с Apache сразу на AGPL или собственные лицензии — они не хотели, чтобы крупные облачные провайдеры бесплатно наживались на их коде.

Новые вызовы: AI и не только

Технологическое развитие создает новые поводы для споров. 

GitHub Copilot и ИИ-нарушитель

В 2022 году группа разработчиков подала коллективный иск против GitHub, Microsoft и OpenAI. Суть — Copilot обучался на миллиардах строк кода из GitHub-репозиториев, в том числе защищенных GPL, MIT и другими лицензиями. При генерации кода Copilot нередко воспроизводил фрагменты, идентичные оригиналу, но без указания авторства и без соблюдения условий лицензий.

Истцы ссылались в том числе на нарушение DMCA § 1202 — удаление уведомлений об авторских правах.

Федеральный суд в 2024 году отклонил требования чисто об авторском праве, так как истцы не представили конкретные фрагменты кода. Однако еще рассматривают требования о нарушении лицензий как контракта. Пока что дело продолжается в Апелляционном суде 9-го округа. 

ONLYOFFICE vs. Euro-Office

В марте 2026 года компания Ascensio System SIA (ONLYOFFICE) заявила о нарушениях AGPLv3 в проекте Euro-Office — совместном форке ONLYOFFICE от компаний Nextcloud и IONOS. Конфликт касается не только авторских прав, но и «дополнительных условий». ONLYOFFICE требовала сохранить свой брендинг и логотип, тогда как Euro-Office их убрала.

Euro-Office настаивает на том, что базовая лицензия AGPL не позволяет добавлять такие ограничения поверх стандартных условий. Показательно, что Брэдли М. Кун — один из авторов оригинального AGPL — публично поддержал позицию Euro-Office.

Судебного решения пока что нет. Но дело поднимает ключевой вопрос — в какой мере правообладатель может кастомизировать «стандартную» open source лицензию, добавляя условия поверх нее. А также насколько эти условия обязательны.

Как дела в России

Россия — один из крупных потребителей открытого исходного кода. Есть оценки, что 90% и более сертифицированных отечественных средств защиты информации содержат компоненты с открытым кодом. При этом реальная правоприменительная практика по GPL в российских судах минимальна.

Как уже говорилось, российское право признаёт лицензии открытого кода полноценными договорами. GPL квалифицируют как договор присоединения. Нарушение условий аннулирует лицензию. В итоге нарушитель открытой лицензии в России может столкнуться не с иском за «нарушение договора», а с иском за незаконное использование объекта авторского права. Однако на практике такие вопросы обычно решают без суда. 

Кейс AlterOffice

В 2019 году нижегородская компания «Алми Партнёр» зарегистрировала в Реестре российского ПО продукт AlterOffice. Эксперты — включая специалистов НИИ «Восход» — установили, что продукт фактически клонировал LibreOffice, распространяемый под Mozilla Public License (MPL). MPL требует указывать оригинальное авторство компонентов и открывать изменения в заимствованных файлах.

Экспертный совет при Минкомсвязи исключил AlterOffice из Реестра в ноябре 2019 года. Компания оспорила решение в арбитраже — и Арбитражный суд Москвы в сентябре 2020 года встал на сторону «Алми Партнёр». Министерство не смогло доказать нарушение требований MPL в судебном процессе: 

• у ответчика был публичный репозиторий с исходным кодом;

• формальное соответствие требованиям лицензии оказалось достаточным аргументом. 

AlterOffice вернулся в Реестр, но в 2020 году компания прекратила продвижение продукта.

Постановление № 25-П (16.06.2022) КС РФ о «составном произведении» 

В 2022 году Конституционный суд рассмотрел дело, в котором открытый исходный код стал аргументом против разработчика, а не за него.

Программист Александр Мамичев создал ПО для управления учебным контентом на базе GPL v2-библиотек. Работодатель отказался платить вознаграждение, сославшись на то, что в коде использованы сторонние GPL-компоненты — а значит, Мамичев не является единственным правообладателем и его права ограничены. Апелляционный суд согласился с этим, квалифицировав ПО как «составное произведение» (п. 3 ст. 1260 ГК РФ). Это лишило разработчика обычной защиты.

Конституционный суд 16 июня 2022 года признал применявшуюся норму неконституционной. Позиция КС — отказать автору составного произведения в защите можно только при наличии реальных претензий от авторов исходных произведений. Исключительное право на производное ПО возникает с момента его создания, независимо от того, использован ли в нем открытый код. 

Почему GPL в России не судятся

Software Freedom Conservancy — главная организация по правоприменению GPL в мире — прямо указывает, что получает много сообщений о нарушениях из России, но не преследует их. Причины:

1. Правообладатели кода (как правило, иностранные НКО или физические лица) не имеют рычагов в российской юрисдикции после 2022 года;

2. Российские пользователи, обнаружившие нарушение, не являются стороной лицензии и не могут подать иск самостоятельно;

3. Государственные органы могут реагировать на обращения, но это исключение, а не правило.

В результате в России для защиты программы лучше полагаться на ее полноценную регистрацию и при возможности даже патентование.

Итоги

Open source — это не юридический вакуум, а сложная система договоров, работающих через авторское право. Более мягкие «разрешительные» лицензии (MIT, Apache) требуют только указать автора. «Закрытые» копилефт лицензии (GPL, AGPL) требуют открыть и производный кода при распространении. Нарушение любой из них превращает «бесплатную» библиотеку в источник правовых рисков.

В целом сейчас многие компании переходят на еще более жесткие варианты лицензирования открытого кода.