В заказной разработке права на код не переходят к заказчику автоматически только потому, что он заплатил. Их распределяет договор: отчуждение исключительных прав, исключительная или неисключительная лицензия, или смешанная модель, где заказчик получает права на созданное под него, а подрядчик сохраняет свои библиотеки и платформу. Отдельно нужно описать открытый код, исходные тексты, документацию и использование ИИ-ассистентов.
Почему это важно обеим сторонам
Заказчик платит за систему, на которой будет держаться его бизнес годами. Ему нужно право дорабатывать её с другим подрядчиком, передавать в группу компаний, переносить в другое облако. Подрядчик же строит бизнес на повторном использовании наработок: если он отдаёт исключительные права на всё, включая собственные модули, то следующий проект придётся писать с нуля или нарушать договор.
Конфликт обычно проявляется поздно: при смене подрядчика, продаже бизнеса, проверке инвестора или выходе подрядчика с похожим продуктом на рынок. Тогда выясняется, что договор говорит «результат работ принадлежит заказчику», но не уточняет, что такое результат и что с исходным кодом.
Три базовые модели
| Модель | Что получает заказчик | Что остаётся у подрядчика | Когда подходит |
|---|---|---|---|
| Отчуждение исключительного права | Полные права на результат, включая право запрещать использование другим | Ничего по этому результату | Уникальная разработка, ключевой актив заказчика |
| Исключительная лицензия | Право использования, которое подрядчик не выдаёт другим | Само право, ограниченное лицензией | Когда подрядчик хочет сохранить право, но не конкурировать с клиентом |
| Неисключительная лицензия | Право использовать в оговорённых пределах | Право использовать и продавать другим | Типовые решения, платформы, коробочное ПО с доработками |
На практике чаще всего работает смешанная модель: заказчик получает исключительные права на то, что создано специально для него, а на встроенные библиотеки, платформу и инструменты подрядчика — неисключительную бессрочную лицензию, достаточную для использования и доработки системы.
Что обязательно прописать
- Что входит в результат. Исходный код, исполняемые файлы, база данных, документация, дизайн, тестовые сценарии, конфигурации инфраструктуры.
- Наработки подрядчика. Перечень заранее существующих библиотек и модулей, которые остаются у подрядчика, и условия лицензии на них.
- Момент перехода прав. С подписанием акта, с оплатой этапа или по завершении проекта. Связь с оплатой защищает подрядчика.
- Передача исходного кода. Где, в каком виде, с какой документацией и как подтверждается полнота.
- Территория и срок. Для лицензий — обязательно.
- Право на доработку и передачу третьим лицам. Может ли заказчик привлечь другого подрядчика и передать систему в группу компаний.
- Гарантии. Подрядчик гарантирует, что результат не нарушает прав третьих лиц, и отвечает за претензии.
Открытый код
Почти любая современная система содержит компоненты с открытым кодом. Это нормально, но их лицензии накладывают условия. Разрешительные лицензии (MIT, Apache 2.0, BSD) требуют в основном сохранения уведомлений. «Копилефт»-лицензии (семейство GPL) могут требовать раскрытия исходного кода производной работы при распространении. Для заказчика важно, чтобы подрядчик вёл перечень компонентов и их лицензий и не включал компоненты, условия которых несовместимы с планами заказчика — например, с продажей системы как продукта.
ИИ-ассистенты в разработке
Разработчики всё чаще пишут код с помощью ИИ-ассистентов. Правовой статус такого кода и условия сервисов различаются, поэтому разумно договориться заранее: допускается ли использование ассистентов, какие сервисы разрешены, можно ли передавать в них код и данные заказчика, кто проверяет результат и кто отвечает, если сгенерированный фрагмент окажется похож на чужой код. Простое правило для договора: подрядчик отвечает за весь переданный результат так же, как если бы написал его сам.
Внедрение коробочных систем
При внедрении CRM, ERP или облачных сервисов права на саму платформу остаются у вендора — заказчик получает подписку или лицензию. Предмет обсуждения с интегратором — права на конфигурации, скрипты, интеграции и отчёты, созданные при внедрении. Часто их отдают заказчику полностью, а модули, которые интегратор использует у многих клиентов, — по неисключительной лицензии.
Пример
Банк заказал у интегратора мобильное приложение. Договор передавал «все права на результат работ». Через два года банк сменил подрядчика и выяснил, что приложение построено на внутреннем фреймворке интегратора, исходники которого не передавались. Новый подрядчик не мог собрать проект. Спор закончился выкупом лицензии на фреймворк. Перечень наработок подрядчика и условие о бессрочной лицензии на них в исходном договоре стоили бы одного абзаца.
Чек-лист перед подписанием
| Вопрос | Ответ должен быть в договоре |
|---|---|
| Что именно передаётся? | Перечень результатов, включая исходный код и документацию |
| Что остаётся у подрядчика? | Перечень наработок и лицензия на них |
| Когда переходят права? | Привязка к акту или оплате |
| Можно ли дорабатывать с другим подрядчиком? | Да, с явным правом на модификацию |
| Какой открытый код использован? | Обязанность вести перечень компонентов и лицензий |
| Используются ли ИИ-ассистенты? | Правила использования и ответственность |
Эскроу исходного кода
Когда заказчик получает лишь лицензию, а исходный код остаётся у поставщика, риск — поставщик уходит с рынка или прекращает поддержку. Решение — депонирование исходного кода у независимой стороны: код и документация регулярно передаются на хранение и выдаются заказчику при оговорённых событиях (банкротство, прекращение поддержки). Для критичных систем это разумный компромисс между интересами сторон.
Как обсуждать права на переговорах
Права на код — частая точка конфликта на финальном этапе сделки. Помогает заранее подготовить позицию: что для вас как подрядчика принципиально (собственная платформа и библиотеки), чем можно уступить (специфические доработки) и что предложить взамен (бессрочная лицензия, эскроу, право доработки другим подрядчиком). Заказчику важна не формула «все права наши», а уверенность, что систему можно развивать без вас. Если закрыть этот страх, вопрос прав обычно решается быстро.
Что забрать с собой
- Права на код распределяет договор, а не факт оплаты.
- Смешанная модель защищает интересы обеих сторон.
- Перечислите наработки подрядчика и дайте на них бессрочную лицензию.
- Ведите перечень открытых компонентов и их лицензий.
- Договоритесь о правилах использования ИИ-ассистентов.
Достаточно ли фразы «все права принадлежат заказчику»?
Нет. Без перечня результатов, наработок подрядчика и порядка передачи исходного кода она порождает споры.
Может ли подрядчик продать похожее решение другим?
Да, если заказчик получил неисключительную лицензию или права только на свои специфические части. Если нужна защита — исключительные права или ограничения в договоре.
Кто отвечает за нарушение чужих прав в коде?
Обычно подрядчик, если это прописано в гарантиях. Пропишите это явно.