Приемка исключительных прав на ПО: правила проверки договора с разработчиком

За публикацию кода без согласия правообладателя.

Передача прав на исходный код в договоре — не формальность для юридического архива. Это контроль над build pipeline, roadmap, vendor lock-in, безопасностью и стоимостью сопровождения. Если договор собран плохо, заказчик получает работающий бинарь, но не получает управляемый актив. Для enterprise-системы это дефект архитектуры, а не только юридический риск.

Юридическая ловушка: почему передача прав не всегда означает контроль над кодом

В договорах на разработку ПО часто смешивают три разных объекта:

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

Для архитектурного комитета это разные уровни контроля.

Экземпляр дает возможность пользоваться. Лицензия дает ограниченное право использования. Исключительное право дает возможность распоряжаться: модифицировать, отчуждать, передавать, запрещать использование другим лицам. Если в договоре написано «передать программу», но не описан объем прав, состав артефактов и момент перехода, система остается зависимой от исполнителя.

Критичный элемент — исходный код. Без него невозможны:

• независимая модификация;
• security review;
• миграция на другой стек;
• устранение дефектов без исходного подрядчика;
• нормальный CI/CD;
• аудит сторонних компонентов;
• восстановление продукта после конфликта с vendor.

При этом отсутствие отдельной строки «исполнитель передает исходный код» не означает, что разработчик может оставить код у себя. Если отчуждается исключительное право на ПО, приобретателю должен быть передан код, необходимый для реализации права на модификацию. Это следует из логики подп. 9 п. 2 ст. 1270 ГК РФ: модификация программы относится к способам использования.

Обратная конструкция опаснее. Если договор прямо запрещает передачу исходного кода, суд может увидеть не отчуждение исключительного права, а лицензионную модель. То есть заказчик платит как за актив, но получает режим использования.

Если код нельзя собрать, проверить и изменить без исполнителя, исключительное право остается бумажным объектом.

Для приемки договора нужно разделить формулировки по слоям.

Юридический текст должен совпадать с технической поставкой. Формула «права переданы» без передачи репозитория, документации и инструкций сборки не закрывает риск.

Момент перехода прав: зарегистрированное ПО и обычная разработка

Момент перехода прав нельзя оставлять «по умолчанию». Он влияет на право размещать код, подписывать лицензии, передавать продукт другим подрядчикам, запускать коммерческую эксплуатацию.

Есть два режима.

Первый — программа зарегистрирована в Роспатенте. Тогда переход исключительного права по договору отчуждения происходит не в момент подписания акта и не в момент оплаты. Он происходит в момент государственной регистрации отчуждения. Это п. 4 ст. 1234 ГК РФ.

Второй — программа не зарегистрирована. Тогда стороны могут сами зафиксировать момент перехода прав. Обычно выбирают один из вариантов:

• с даты подписания акта приема-передачи прав на ПО;
• с даты полной оплаты;
• с даты передачи исходного кода и технической документации;
• с даты подписания финального акта работ;
• поэтапно — по каждому sprint increment, модулю или релизу.

Для enterprise-разработки поэтапная модель чаще устойчивее. Причина простая: проект может длиться 6–18 месяцев. За это время появляется код, документация, инфраструктурные шаблоны, тесты, интеграции. Если права переходят только в финале, весь промежуточный результат находится в подвешенном состоянии. При конфликте заказчик получает репозиторий с неизвестным правовым статусом.

Рабочая модель:

1. В договоре указывается, что права на каждый созданный компонент переходят после подписания акта по этапу.

2. Для каждого этапа есть перечень артефактов: код, тесты, документация, конфиги, схемы данных.

3. Оплата привязана к передаче артефактов, а не только к демонстрации UI.

4. Для зарегистрированного ПО отдельно прописывается обязанность сторон выполнить действия для регистрации отчуждения.

5. До регистрации отчуждения для зарегистрированной программы фиксируется временный режим использования, чтобы эксплуатация не зависела от формальной задержки.

Нельзя писать, что права на зарегистрированное в Роспатенте ПО переходят сразу по акту, если отчуждение не зарегистрировано. Акт может подтвердить передачу артефактов. Но не заменит государственную регистрацию перехода исключительного права.

Что должно быть в акте

Акт приема передачи прав на ПО должен быть не пустым приложением на одну страницу. Для audit trail он должен связывать юридический переход с технической поставкой.

Минимальный состав:

• наименование программы и версии;
• идентификатор релиза;
• ссылка на commit hash или tag в репозитории;
• перечень переданных модулей;
• перечень переданных материалов: исходный код, тесты, документация, инструкции сборки;
• список сторонних компонентов;
• указание на переход исключительного права в согласованном объеме;
• дата и основание перехода;
• подтверждение отсутствия неразрешенных ограничений, включая copyleft-компоненты без согласия заказчика.

Лучше фиксировать не «передан архив с кодом», а конкретный repository state. Архив без истории коммитов хуже для расследования дефектов и IP-споров. История нужна для traceability: кто внес фрагмент, когда, в рамках какой задачи, под каким license header.

Риски открытых библиотек: как copyleft может раскрыть продукт

Open source не равен бесплатному активу без условий. Для корпоративной разработки критичен тип лицензии.

Разрешительные лицензии обычно дают широкие права при соблюдении условий уведомления. Copyleft-лицензии могут требовать раскрытия исходного кода производного продукта при распространении. Для заказного коммерческого ПО это не теоретическая проблема. Если исполнитель включил компонент с сильным copyleft в core-продукт, заказчик может получить обязанность раскрыть свой код.

Универсального перечня всех copyleft-лицензий, которые суды в любом случае признают нарушающими права заказчика, нет. Нужен анализ конкретной лицензии, способа интеграции и модели распространения продукта. Но в договоре можно снизить риск заранее.

Запрет должен быть технологически исполнимым. Не «исполнитель гарантирует чистоту кода», а набор конкретных обязанностей:

• не использовать компоненты с copyleft-лицензиями без письменного согласия заказчика;
• вести SBOM по каждому релизу;
• передавать список зависимостей с версиями и лицензиями;
• фиксировать способ подключения: static linking, dynamic linking, API, отдельный сервис;
• отделять open source-компоненты от proprietary-кода;
• не включать код из публичных репозиториев без проверки license file;
• удалять или заменять компонент при выявлении нарушения;
• возмещать убытки и расходы на remediation.

Для desktop-софта и on-premise-продуктов риск выше, чем для закрытой внутренней системы. Причина — распространение экземпляров. Но SaaS тоже не освобождает от анализа. Архитектура меняется. Сегодня модуль работает как внутренний сервис. Завтра он поставляется клиенту в виде self-hosted-инсталляции. Лицензионный профиль должен выдерживать оба режима, если roadmap это допускает.

Внутри технического задания стоит разделять product requirements и compliance requirements. Это относится к любым предметным сервисам: учет складских остатков, финансовые кабинеты, медицинские интерфейсы или справочники вроде продуктов для кето-меню. Предметная область меняется. Риск лицензий и прав на код остается тем же.

Open source без инвентаризации — это не ускорение разработки. Это неучтенный dependency graph в юридическом периметре продукта.

Цена ошибки: публикация кода на сторонних репозиториях

Разработчики часто используют GitHub, GitLab, Bitbucket, облачные CI, package registry, paste-сервисы. Для команды это обычная инфраструктура. Для правообладателя — контур передачи и воспроизведения кода.

Если исполнитель размещает исходный код заказчика на стороннем сервисе без согласия правообладателя, это может квалифицироваться как незаконное воспроизведение и доведение до всеобщего сведения. Прецедент с компенсацией 2 645 733 рубля 10 копеек показывает уровень риска.

Проблема не только в публичном репозитории. Риск возникает и при неверной настройке private-доступов:

• внешний подрядчик добавил личный аккаунт;
• repository visibility случайно стала public;
• CI-лог вывел секреты или фрагменты кода;
• fork остался у уволенного разработчика;
• пакет был опубликован в публичный registry;
• контейнерный image ушел в общий namespace;
• issue tracker содержит фрагменты исходников.

Для договора этого мало. Нужны правила инфраструктуры:

1. Репозиторий создается в организации заказчика или в согласованной организации исполнителя с последующей передачей ownership.

2. Личные аккаунты не должны быть владельцами критичных репозиториев.

3. Все внешние сервисы перечисляются в приложении к договору.

4. Публикация кода, артефактов сборки, контейнеров и пакетов допускается только с письменного согласия заказчика.

5. Fork policy задается явно.

6. Доступы удаляются при завершении этапа или договора.

7. Secrets не хранятся в репозитории.

8. Логи CI/CD не должны содержать исходный код, токены и private keys.

9. Backups и mirrors включаются в периметр контроля.

10. Исполнитель подтверждает удаление локальных копий после передачи, если договор не сохраняет ему право хранения.

Для k8s-инфраструктуры отдельно фиксируются Helm charts, manifests, operators и values-файлы. В них часто содержится не бизнес-логика, но содержатся детали архитектуры. Иногда — endpoint internal-сервисов, topology, параметры доступа. Это тоже коммерчески значимая информация.

Принадлежность прав на исходный код: договор заказа, подряд и служебные блоки

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

Если договор прямо направлен на создание программы по заказу, применяется логика ст. 1296 ГК РФ: права могут принадлежать заказчику, если договором не предусмотрено иное. Но если работы не имели целью создание ПО, может включиться ст. 1297 ГК РФ: права остаются у подрядчика, если иное не закреплено. Типичный риск — внедрение, настройка, интеграция, консалтинг, в рамках которых подрядчик пишет скрипты, коннекторы, middleware, миграции данных.

Для архитектуры это критично. Самый ценный код не всегда в основном приложении. Иногда value лежит в:

• ETL-скриптах;
• адаптерах к ERP;
• middleware для legacy-систем;
• Terraform-модулях;
• SQL-процедурах;
• генераторах отчетов;
• migration scripts;
• кастомных плагинах;
• test harness;
• мониторинговых exporters.

Если договор называется «оказание услуг по внедрению», но внутри создан код, принадлежность прав на исходный код должна быть описана отдельно. Иначе заказчик получает рабочую инсталляцию, но не получает право свободно переносить и модифицировать интеграционные блоки.

Отдельный контур — pre-existing components исполнителя. У разработчика могут быть собственные библиотеки, шаблоны, SDK, boilerplate, admin-панели. Их не всегда рационально отчуждать заказчику полностью. Но тогда договор должен разделять:

• код, созданный специально для заказчика;
• ранее существующие компоненты исполнителя;
• open source-компоненты;
• сторонние коммерческие библиотеки;
• настройки и конфигурации заказчика;
• производные доработки pre-existing components.

Если этого разделения нет, конфликт предсказуем. Заказчик считает, что оплатил все. Исполнитель считает, что передал только кастомизацию.

Когда разработчик теряет право использовать созданные блоки

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

Это нужно формулировать точно. Не через общую фразу «исполнитель вправе использовать накопленный опыт». Опыт и навыки не равны коду. Архитектурный паттерн не равен конкретной реализации. Алгоритмический подход не равен файлам репозитория.

Рабочее разграничение:

Фраза «исполнитель вправе использовать типовые решения» слабая. Типовые решения нужно идентифицировать. Иначе под этот термин может попасть половина репозитория.

Для заказчика приемлемы два режима:

• полное отчуждение всего созданного кода без права повторного использования исполнителем;
• гибридная модель: заказчику передаются исключительные права на кастомный код, а исполнитель сохраняет права на заранее описанные framework-компоненты и предоставляет заказчику бессрочную лицензию на их использование.

Второй вариант дешевле и реалистичнее для продуктовых студий. Но он должен быть прозрачен. Иначе это скрытый vendor lock-in.

Договорная конструкция: минимальный набор положений

Передача прав на исходный код в договоре должна быть описана не одним пунктом, а связкой условий. Иначе отдельные положения будут конфликтовать.

Базовый набор:

1. Предмет договора. Создание конкретного ПО или доработка существующего продукта. С описанием модулей, интеграций и deliverables.

2. Режим прав. Отчуждение исключительного права в полном объеме или иной режим. Без двусмысленности между лицензией и отчуждением.

3. Вознаграждение за права. Для возмездного договора об отчуждении исключительного права условие о размере вознаграждения или порядке его определения является существенным. При его отсутствии договор считается незаключенным.

4. Момент перехода. Отдельно для незарегистрированного и зарегистрированного ПО. Для зарегистрированного — с учетом государственной регистрации отчуждения.

5. Состав передаваемых материалов. Исходный код, объектный код, документация, тесты, build scripts, deployment scripts, IaC, схемы БД, API specs.

6. Порядок передачи. Репозиторий, commit hash, tag, архив, registry, доступы, акт.

7. Open source policy. Запрет copyleft без согласия, SBOM, license notices, remediation.

8. Сторонние сервисы. Где разрешено хранить код. Кто владелец. Как закрывается доступ.

9. Pre-existing IP. Что принадлежало исполнителю до проекта. На каких условиях заказчик это использует.

10. Запрет повторного использования. Для кода, права на который перешли заказчику.

11. Гарантии авторства. Исполнитель подтверждает, что имеет права от сотрудников и субподрядчиков.

12. Ответственность. Нарушение IP, публикация кода, несанкционированное использование, copyleft-нарушения.

13. Приемка. Критерии технической и правовой приемки.

Отдельный риск — субподрядчики. Если код пишет не только сторона договора, исполнитель должен получить права от всех участников цепочки. Иначе заказчик получает claim от лица, которого он не видел в проекте. В договоре нужно запретить привлечение субподрядчиков без согласования либо обязать исполнителя обеспечить полный переход прав от них.

Техническая приемка как часть IP-приемки

Юридическая приемка без технической верификации не работает. Нужен минимальный audit pipeline.

Для каждого релиза:

• checkout из переданного репозитория;
• сборка по инструкции на чистой среде;
• запуск unit/integration tests;
• сверка версии с актом;
• проверка dependency list;
• license scan;
• secret scan;
• проверка container images;
• проверка ownership репозитория;
• проверка закрытия внешних доступов;
• экспорт документации и схем;
• фиксация hash артефактов.

Цель не в том, чтобы найти все дефекты. Цель — подтвердить управляемость актива. Если команда заказчика не может собрать продукт без исполнителя, приемка прав не завершена.

Для desktop-софта дополнительно проверяются:

• installer scripts;
• certificate signing process;
• auto-update mechanism;
• crash-reporting endpoints;
• embedded third-party DLL/libs;
• license notices в дистрибутиве.

Для серверного продукта:

• Dockerfile и base images;
• Helm charts;
• миграции БД;
• environment variables;
• observability-конфиги;
• runbook для rollback;
• backup/restore procedure.

Для мобильных решений:

• доступы к developer accounts;
• signing keys;
• bundle identifiers;
• push notification certificates;
• mobile SDK dependencies;
• privacy manifests, если применимо к платформе.

Если эти элементы остаются у исполнителя, заказчик не контролирует релизный контур.

Финальный контрольный список для приемки

Финальная проверка должна быть короткой. Без декоративных пунктов.

• В договоре прямо указано отчуждение исключительного права или иной выбранный режим.
• Вознаграждение за передачу прав определено либо задан порядок его расчета.
• Момент перехода прав привязан к акту, оплате, этапу или регистрации — без противоречий.
• Для зарегистрированного ПО учтена государственная регистрация отчуждения.
• Исходный код передается вместе с историей, tag/commit hash и инструкцией сборки.
• Акт приема передачи прав на ПО содержит перечень артефактов, а не только общую формулу.
• Open source-компоненты инвентаризированы. Copyleft без согласия заказчика запрещен.
• SBOM передается по каждому релизу.
• GitHub, GitLab, registry, CI/CD и cloud-сервисы согласованы в договоре.
• Публикация кода на сторонних ресурсах без согласия запрещена.
• Pre-existing components исполнителя выделены отдельно.
• Повторное использование кастомного кода исполнителем запрещено, если права переданы заказчику.
• Права от сотрудников и субподрядчиков исполнителя закрыты.
• Репозиторий, registry, домены, cloud accounts и developer accounts находятся под контролем заказчика.
• Продукт собирается на чистой среде без участия исполнителя.

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