---
title: "Кому принадлежит код: права на программы в заказной разработке и внедрении"
url: "https://kzsaleshub.com/prava-na-po-zakaznaya-razrabotka/"
type: "knowledge_article"
category: "Право"
language: "ru"
source: "KZSalesHub"
published: "2026-10-23"
last_updated: "2026-10-18"
---

# Кому принадлежит код: права на программы в заказной разработке и внедрении

В заказной разработке права на код не переходят к заказчику автоматически только потому, что он заплатил. Их распределяет договор: отчуждение исключительных прав, исключительная или неисключительная лицензия, или смешанная модель, где заказчик получает права на созданное под него, а подрядчик сохраняет свои библиотеки и платформу. Отдельно нужно описать открытый код, исходные тексты, документацию и использование ИИ-ассистентов.

## Почему это важно обеим сторонам

Заказчик платит за систему, на которой будет держаться его бизнес годами. Ему нужно право дорабатывать её с другим подрядчиком, передавать в группу компаний, переносить в другое облако. Подрядчик же строит бизнес на повторном использовании наработок: если он отдаёт исключительные права на всё, включая собственные модули, то следующий проект придётся писать с нуля или нарушать договор.

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

## Три базовые модели

| Модель | Что получает заказчик | Что остаётся у подрядчика | Когда подходит |
| --- | --- | --- | --- |
| Отчуждение исключительного права | Полные права на результат, включая право запрещать использование другим | Ничего по этому результату | Уникальная разработка, ключевой актив заказчика |
| Исключительная лицензия | Право использования, которое подрядчик не выдаёт другим | Само право, ограниченное лицензией | Когда подрядчик хочет сохранить право, но не конкурировать с клиентом |
| Неисключительная лицензия | Право использовать в оговорённых пределах | Право использовать и продавать другим | Типовые решения, платформы, коробочное ПО с доработками |

На практике чаще всего работает смешанная модель: заказчик получает исключительные права на то, что создано специально для него, а на встроенные библиотеки, платформу и инструменты подрядчика — неисключительную бессрочную лицензию, достаточную для использования и доработки системы.

## Что обязательно прописать

- **Что входит в результат.** Исходный код, исполняемые файлы, база данных, документация, дизайн, тестовые сценарии, конфигурации инфраструктуры.
- **Наработки подрядчика.** Перечень заранее существующих библиотек и модулей, которые остаются у подрядчика, и условия лицензии на них.
- **Момент перехода прав.** С подписанием акта, с оплатой этапа или по завершении проекта. Связь с оплатой защищает подрядчика.
- **Передача исходного кода.** Где, в каком виде, с какой документацией и как подтверждается полнота.
- **Территория и срок.** Для лицензий — обязательно.
- **Право на доработку и передачу третьим лицам.** Может ли заказчик привлечь другого подрядчика и передать систему в группу компаний.
- **Гарантии.** Подрядчик гарантирует, что результат не нарушает прав третьих лиц, и отвечает за претензии.

## Открытый код

Почти любая современная система содержит компоненты с открытым кодом. Это нормально, но их лицензии накладывают условия. Разрешительные лицензии (MIT, Apache 2.0, BSD) требуют в основном сохранения уведомлений. «Копилефт»-лицензии (семейство GPL) могут требовать раскрытия исходного кода производной работы при распространении. Для заказчика важно, чтобы подрядчик вёл перечень компонентов и их лицензий и не включал компоненты, условия которых несовместимы с планами заказчика — например, с продажей системы как продукта.

## ИИ-ассистенты в разработке

Разработчики всё чаще пишут код с помощью ИИ-ассистентов. Правовой статус такого кода и условия сервисов различаются, поэтому разумно договориться заранее: допускается ли использование ассистентов, какие сервисы разрешены, можно ли передавать в них код и данные заказчика, кто проверяет результат и кто отвечает, если сгенерированный фрагмент окажется похож на чужой код. Простое правило для договора: подрядчик отвечает за весь переданный результат так же, как если бы написал его сам.

## Внедрение коробочных систем

При внедрении CRM, ERP или облачных сервисов права на саму платформу остаются у вендора — заказчик получает подписку или лицензию. Предмет обсуждения с интегратором — права на конфигурации, скрипты, интеграции и отчёты, созданные при внедрении. Часто их отдают заказчику полностью, а модули, которые интегратор использует у многих клиентов, — по неисключительной лицензии.

## Пример

Банк заказал у интегратора мобильное приложение. Договор передавал «все права на результат работ». Через два года банк сменил подрядчика и выяснил, что приложение построено на внутреннем фреймворке интегратора, исходники которого не передавались. Новый подрядчик не мог собрать проект. Спор закончился выкупом лицензии на фреймворк. Перечень наработок подрядчика и условие о бессрочной лицензии на них в исходном договоре стоили бы одного абзаца.

## Чек-лист перед подписанием

| Вопрос | Ответ должен быть в договоре |
| --- | --- |
| Что именно передаётся? | Перечень результатов, включая исходный код и документацию |
| Что остаётся у подрядчика? | Перечень наработок и лицензия на них |
| Когда переходят права? | Привязка к акту или оплате |
| Можно ли дорабатывать с другим подрядчиком? | Да, с явным правом на модификацию |
| Какой открытый код использован? | Обязанность вести перечень компонентов и лицензий |
| Используются ли ИИ-ассистенты? | Правила использования и ответственность |

Материал не является юридической консультацией. Для конкретного договора привлекайте юриста, знакомого с законодательством вашей страны и сферой ИТ.

## Эскроу исходного кода

Когда заказчик получает лишь лицензию, а исходный код остаётся у поставщика, риск — поставщик уходит с рынка или прекращает поддержку. Решение — депонирование исходного кода у независимой стороны: код и документация регулярно передаются на хранение и выдаются заказчику при оговорённых событиях (банкротство, прекращение поддержки). Для критичных систем это разумный компромисс между интересами сторон.

## Как обсуждать права на переговорах

Права на код — частая точка конфликта на финальном этапе сделки. Помогает заранее подготовить позицию: что для вас как подрядчика принципиально (собственная платформа и библиотеки), чем можно уступить (специфические доработки) и что предложить взамен (бессрочная лицензия, эскроу, право доработки другим подрядчиком). Заказчику важна не формула «все права наши», а уверенность, что систему можно развивать без вас. Если закрыть этот страх, вопрос прав обычно решается быстро.

### Что забрать с собой

- Права на код распределяет договор, а не факт оплаты.
- Смешанная модель защищает интересы обеих сторон.
- Перечислите наработки подрядчика и дайте на них бессрочную лицензию.
- Ведите перечень открытых компонентов и их лицензий.
- Договоритесь о правилах использования ИИ-ассистентов.

**Достаточно ли фразы «все права принадлежат заказчику»?**

Нет. Без перечня результатов, наработок подрядчика и порядка передачи исходного кода она порождает споры.

**Может ли подрядчик продать похожее решение другим?**

Да, если заказчик получил неисключительную лицензию или права только на свои специфические части. Если нужна защита — исключительные права или ограничения в договоре.

**Кто отвечает за нарушение чужих прав в коде?**

Обычно подрядчик, если это прописано в гарантиях. Пропишите это явно.

---
Источник: https://kzsaleshub.com/prava-na-po-zakaznaya-razrabotka/