Когда заказчик говорит «код должен быть наш», он имеет в виду три разные вещи сразу: юридическое право на программу, физический доступ к исходникам и возможность позвать другую команду, которая продолжит работу. Договор умеет выдать любую одну из трёх и не выдать остальные — причём совершенно законно и без злого умысла. Именно поэтому проверять надо не наличие фразы про исключительное право, а все три пункта по отдельности.
Хорошая новость в том, что базовое правило закона на стороне заказчика. Если создание программы было предметом договора, исключительное право по умолчанию возникает у заказчика. Плохая — в том, что это правило диспозитивное: одна строчка в договоре разворачивает его в обратную сторону, и такая строчка встречается часто.
Ниже — логика статей 1296 и 1297 ГК РФ на примерах, разбор того, что подрядчик делает попутно и законно оставляет себе, список компонентов, которые нельзя передать в принципе, расчёт лицензии против отчуждения на три года и шесть проверок, по которым видно, перешло право на самом деле или только на бумаге. Мы инженерное бюро, а не юридическая фирма: в конце собран список вопросов, с которыми идут к юристу по вашей редакции договора.
Три объекта, которые прячутся за словом «код»
Разделение выглядит занудным ровно до момента расставания с подрядчиком. Дальше выясняется, что каждый объект теряется отдельно и восстанавливается по-разному.
| Объект | Что это на практике | Что нельзя без него |
|---|---|---|
| Исключительное право | Юридическая возможность использовать программу, изменять её и разрешать это другим | Нельзя нанять другую команду и легально передать ей код на доработку |
| Экземпляр исходников | Репозиторий целиком: код, миграции базы, конфигурации, скрипты сборки и развёртывания | Нельзя собрать и развернуть систему — право есть, а объекта права на руках нет |
| Возможность продолжить | Документация, описание обменов, отсутствие скрытых зависимостей от инфраструктуры подрядчика | Нельзя войти в проект новой командой за разумные деньги: разбор обойдётся дороже переписывания |
Третья строка — самая обидная, потому что формально к ней не придраться. Право передано, архив с кодом отдан, а система не запускается, потому что обращается к лицензионному серверу подрядчика или собирается только на его сборочной машине. Юридически всё исполнено. Практически вы получили набор файлов. Что именно требовать в перечне передаваемого, разобрано отдельно в материале про передачу доступов при завершении проекта.
Вторая строка теряется тише всех. Репозиторий формально передан, но в нём нет миграций базы, файлов конфигурации для боевого окружения и скриптов сборки — они жили в отдельном приватном проекте подрядчика, о существовании которого заказчик не знал. Это не саботаж, а обычная гигиена разработки: секреты и конфигурации специально держат отдельно от кода. Вопрос только в том, передаются ли они вместе с кодом и перечислены ли в описи. Проверяется это одним действием — попыткой развернуть систему на чистом сервере силами человека, который её не писал.
Статьи 1296 и 1297: кому право по умолчанию
Различие между двумя нормами держится на одном вопросе: было ли создание программы предметом договора. Если да — работает статья 1296 ГК РФ (произведения, созданные по заказу): исключительное право принадлежит заказчику, если договором не предусмотрено иное, а подрядчик вправе использовать результат для собственных нужд на условиях безвозмездной простой лицензии. Если программа появилась попутно при выполнении договора, который прямо её создания не предусматривал, работает статья 1297: право остаётся у подрядчика, а заказчик получает безвозмездную лицензию для тех целей, ради которых заключался договор.
| Ситуация | Что записано в предмете договора | Кому право по умолчанию | Что делать в договоре |
|---|---|---|---|
| Заказная система под ваш процесс | Разработка программы для приёма и разбора заявок | Заказчику (ст. 1296) | Ничего не менять, но проверить, что нет обратной оговорки мелким шрифтом |
| Внедрение готовой платформы с доработками | Внедрение и настройка платформы исполнителя | Подрядчику на ядро, заказчику — на доработки при правильной формулировке | Разделить в предмете ядро и доработки, на ядро оформить лицензию |
| Обследование, в ходе которого написали утилиту переноса данных | Обследование процессов и подготовка ТЗ | Подрядчику (ст. 1297) | Прямо указать утилиту в перечне передаваемых результатов |
| Поддержка, в ходе которой сделали новый отчёт | Техническая поддержка системы | Подрядчику (ст. 1297) | В договоре поддержки описать, что права на новые доработки переходят заказчику |
Фразы «исключительное право на результат сохраняется за исполнителем» достаточно, чтобы перевернуть правило статьи 1296 полностью. Она встречается в договорах не как ловушка, а как остаток чужого шаблона, и обычно спокойно вычёркивается на переговорах. Но обнаружить её надо до подписания: после подписания это уже не правка, а переуступка прав. Какие ещё формулировки в договоре работают, а какие стоят по традиции, разобрано в материале про существенные условия договора на внедрение.
Сравнение в две колонки. Левая — «Создание программы было предметом договора (ст. 1296)»: стрелка права идёт к блоку «Заказчик», у подрядчика подпись «простая лицензия для собственных нужд». Правая — «Программа создана попутно (ст. 1297)»: стрелка права идёт к блоку «Подрядчик», у заказчика подпись «безвозмездная лицензия для целей договора». Под обеими колонками общая полоса-предупреждение: «обе нормы диспозитивные — договор может установить обратное». Чертёжный стиль, подписи по-русски.
Есть и обратная сторона, о которой заказчики думают редко. Подрядчик за годы работы накапливает собственные наработки: библиотеку обмена с 1С, генератор печатных форм, каркас админки, набор коннекторов к телефонии. Он приносит их на ваш проект целиком, и именно поэтому проект стоит 2 400 000 ₽, а не 6 000 000 ₽. Требовать отчуждения этих наработок — значит требовать, чтобы подрядчик больше никогда их не использовал. Нормальный ответ на это требование — отказ или трёхкратная цена. Рабочая схема другая: на свои наработки подрядчик даёт бессрочную лицензию, на всё сделанное под вас — передаёт исключительное право, и оба перечня прилагаются к договору.
Что нельзя передать в принципе
Заметная часть любой рабочей системы написана не подрядчиком: открытые библиотеки, платные модули, ядро платформы, внешние сервисы. Это нормально и удешевляет проект. Тревожиться надо не из-за самого факта, а из-за того, что состав этой части обычно нигде не зафиксирован.
| Компонент | Что вы получаете | Что проверить до подписания |
|---|---|---|
| Открытые библиотеки | Право использовать на условиях их лицензии — оно у вас и так есть | Реестр библиотек с типом лицензии; отдельно — есть ли компоненты с copyleft-условиями вроде GPL |
| Платные модули и компоненты | Лицензию, оформленную на конкретное юрлицо | На чьё юрлицо оформлена лицензия и что происходит при её неоплате через год |
| Ядро платформы подрядчика | Лицензию на использование, обычно с ежемесячным платежом | Срок лицензии, условия расторжения и что остаётся работать, если платежи прекратятся |
| Внешние сервисы: модель, распознавание, телефония, карты | Ничего — это доступ по подписке на ваш аккаунт | Что аккаунты и ключи оформлены на вас, а не на подрядчика |
| Шрифты, иконки, изображения | Лицензию на конкретный способ использования | Что лицензия покрывает коммерческое использование и оформлена на вас |
Практический вывод один: реестр сторонних компонентов должен быть приложением к договору и обновляться при сдаче каждого этапа. Это одна таблица на страницу, и её отсутствие — гораздо более серьёзный признак, чем любая формулировка про исключительное право. Подрядчик, который не может за час назвать состав сторонних компонентов своей системы, не контролирует её и сам.
Отдельный вопрос к каждой платной строке реестра — что произойдёт, если платить перестанут. Ответы бывают разные: модуль продолжает работать, но без обновлений; модуль перестаёт работать в день окончания подписки; система остаётся рабочей, но без одной функции. Разница принципиальна для планирования бюджета эксплуатации, и узнавать её лучше до подписания договора, а не в момент, когда счёт пришёл, а деньги на него не заложены. То же касается внешних сервисов: ключ, выпущенный в аккаунте подрядчика, перестаёт работать в день расставания, даже если формально право на код у вас.
Карта системы из пяти горизонтальных слоёв снизу вверх: «Внешние сервисы (модель, распознавание, телефония)», «Открытые библиотеки», «Ядро платформы подрядчика», «Наработки подрядчика (библиотеки обмена, каркас админки)», «Код, написанный под вас». Справа от каждого слоя ярлык одного из трёх режимов: «не передаётся — доступ по вашей подписке», «лицензия компонента», «лицензия подрядчика», «бессрочная лицензия», «исключительное право переходит». Внизу подпись: «реестр компонентов — приложение к договору». Чертёжный стиль, подписи по-русски.
Лицензия или отчуждение: считаем на три года
Требование «только полное отчуждение» звучит уверенно и часто оказывается дорогим. Сравним два предложения под один и тот же процесс: приём заявок с разбором спецификаций и передачей заказа в 1С:УТ. Вариант А — внедрение на платформе подрядчика с лицензией на ядро. Вариант Б — заказная разработка с переходом исключительного права на всё.
Дальше начинается интересное. Разница в ежемесячных платежах — 10 000 ₽, разница на входе — 1 200 000 ₽. Значит, по деньгам вариант с лицензией остаётся выгоднее примерно десять лет. Никто не выбирает отчуждение ради экономии: за него платят, чтобы не зависеть от одного поставщика. Правильный вопрос звучит не «сколько дороже», а «что произойдёт, если подрядчик поднимет цену вдвое, уйдёт с рынка или мы просто захотим сменить команду».
График накопленных расходов, ось X — месяцы от 0 до 120, ось Y — рубли. Две линии: «Вариант А, лицензия» стартует с 1 200 000 ₽ и растёт на 35 000 ₽/мес; «Вариант Б, отчуждение» стартует с 2 400 000 ₽ и растёт на 25 000 ₽/мес. Отмечена вертикаль на 36-м месяце с подписями 2 460 000 ₽ и 3 300 000 ₽ и разницей 840 000 ₽. Отмечена точка пересечения линий на 120-м месяце с подписью «десять лет». Подписи по-русски.
Разумный компромисс встречается чаще, чем крайние варианты: лицензия на ядро платформы — бессрочная и неисключительная, с правом модификации, а исключительное право на всё написанное под ваш процесс переходит вам. Тогда при расставании с подрядчиком вы теряете обновления ядра, но не теряете работающую систему и накопленные доработки. Как это соотносится с выбором между готовым продуктом и разработкой с нуля, мы разбирали в материале про готовое SaaS-решение или заказную разработку.
В самой лицензии смотреть надо на пять параметров, и все пять должны быть в тексте, а не подразумеваться. Срок — бессрочная или привязанная к договору поддержки. Территория и способы использования — достаточно ли их для вашего сценария. Право модификации — есть или нет. Право привлекать третьих лиц к доработке. И условие о том, что происходит при расторжении договора: остаётся ли лицензия действующей. Пятый пункт самый важный и самый часто пропущенный: лицензия, которая прекращается вместе с договором поддержки, экономикой из расчёта выше не описывается вообще — вы платите не за использование, а за право продолжать пользоваться, пока платите.
Право на переработку: код ваш, а менять нельзя
Это самая частая техническая ошибка в разделе о правах, и она почти всегда непреднамеренная. В договоре написано, что заказчику передаётся право использования программы, — и на этом всё. Использовать можно, дорабатывать нельзя: переработка произведения — отдельное правомочие, и если оно не названо, лицензия его не покрывает.
Любое изменение исходного кода: исправление ошибки, добавление поля, новый отчёт, адаптация под изменившийся API маркетплейса. С точки зрения права это создание производного произведения, и делать это можно только тому, у кого есть соответствующее правомочие. Для заказчика, получившего лицензию без права переработки, это означает, что любая доработка возможна только руками правообладателя.
На практике в раздел о правах должны попасть три вещи помимо самой передачи. Первая — право модифицировать и перерабатывать, включая создание производных версий. Вторая — право привлекать к доработке третьих лиц, иначе право у вас есть, а поручить его реализацию некому. Третья — подтверждение, что подрядчик урегулировал отношения со своими сотрудниками и субподрядчиками: код пишут люди, у штатных сотрудников это служебное произведение с правами у работодателя, а у привлечённых по гражданско-правовому договору цепочка может оборваться. Проверять её вам не нужно — достаточно заверения подрядчика в договоре, а последствия его недостоверности оценит юрист.
Шесть проверок: право перешло или только записано
Проверки проводятся на сдаче этапа, а не через год. Пять из шести делает ваш ИТ-специалист или внешний инженер за один рабочий день.
- 1Перечень результатов в акте. В акте по этапу перечислены конкретные результаты, права на которые переходят, а не общая фраза «результаты работ». Как устроен такой перечень, разобрано в материале про акт выполненных работ.
- 2Полнота репозитория. В нём должны быть не только исходники, но и миграции базы, конфигурации окружений, скрипты сборки и развёртывания. Репозиторий без миграций и скриптов — это текст, а не система.
- 3Сборка чужими руками. Человек, не участвовавший в проекте, разворачивает систему на чистом сервере по переданной инструкции. Каждое место, где он застрял, — это скрытая зависимость от людей подрядчика.
- 4Реестр сторонних компонентов. Таблица с типом лицензии по каждому компоненту, актуальная на дату сдачи. Отдельно проверяется, нет ли компонентов с copyleft-условиями там, где это критично.
- 5Отсутствие обращений к инфраструктуре подрядчика. Система не должна ходить за лицензией, ключом активации или конфигурацией на внешний адрес, который вам не принадлежит. Проверяется журналом сетевых обращений за сутки работы.
- 6Заверения о правах. В договоре есть подтверждение подрядчика, что права его сотрудников и субподрядчиков урегулированы и передача не нарушает прав третьих лиц. Формулировку и её последствия проверяет юрист.
Схема-чек-лист из шести блоков в две колонки. Пять блоков помечены ярлыком «инженер, 1 рабочий день»: «Перечень результатов в акте», «Полнота репозитория: код, миграции, конфиги, скрипты», «Сборка чужими руками на чистом сервере», «Реестр сторонних компонентов с лицензиями», «Журнал сетевых обращений: нет вызовов инфраструктуры подрядчика». Шестой блок помечен ярлыком «юрист»: «Заверения о правах сотрудников и субподрядчиков». Под схемой подпись: «проверяется на сдаче этапа, а не через год». Чертёжный стиль, подписи по-русски.
Что спросить у юриста по вашей редакции
Инженер отвечает за то, что вы физически можете собрать и доработать систему. Всё остальное в этой теме — право, и вопросы к юристу лучше нести списком, а не с просьбой «посмотрите договор целиком».
- Что у нас в предмете договора и какая норма из-за этого применяется по умолчанию — 1296 или 1297.
- Нет ли в тексте оговорки, сохраняющей исключительное право за исполнителем, и не спрятана ли она в разделе про конфиденциальность или про результаты интеллектуальной деятельности.
- Названы ли отдельно право на переработку и право привлекать к доработке третьих лиц — или только «право использования».
- Как оформлены наработки подрядчика: лицензия бессрочная и неисключительная или срочная с привязкой к договору поддержки.
- Требуется ли государственная регистрация перехода права, если программа зарегистрирована в Роспатенте, и кто её делает.
- Что произойдёт с правами при досрочном расторжении договора на середине этапа: переходит ли право на уже созданную часть и оплаченный результат.
Право на код без экземпляра и без возможности его собрать — это документ, а не система. Проверять надо все три вещи.
Когда права на код вам не нужны
Требование полного отчуждения имеет цену — деньгами, сроками и иногда отказом нормального подрядчика от проекта. В четырёх случаях эта цена не окупается, и честнее обойтись лицензией.
- Вы покупаете подписку на готовый сервис. Права на код здесь не обсуждаются в принципе: вы платите за доступ. Значение имеет другое — выгрузка ваших данных в открытом формате и срок, за который её обязаны предоставить.
- Типовая коробка с настройкой. Если доработок нет или они сводятся к конфигурации, отчуждать нечего. Проверять надо условия лицензии и порядок обновлений, а не право собственности на ядро.
- Вспомогательная автоматизация до 300 000 ₽. Скрипт выгрузки или отчёт, который через два года всё равно перепишут. Переписать его заново дешевле, чем вести переговоры об отчуждении и платить наценку за него.
- Система, которую вы не собираетесь развивать. Если задача решена и трогать её никто не планирует, важнее не право, а работоспособность: доступы, резервные копии и понятный порядок восстановления. Что должно быть в этом наборе, разобрано в статье про передачу системы в эксплуатацию.
И честное ограничение всего материала. Право на код не защищает от главного риска — от того, что систему невозможно поддерживать. Мы видели проекты с безупречным разделом о правах, где новая команда оценивала вход в чужой код дороже, чем разработку заново. Юридическая часть закрывает вопрос «можно ли», а инженерная — «за сколько». Второй вопрос дороже, и решается он документацией, тестами и понятной архитектурой, а не формулировками в договоре.
