Договор
разработки ПО
с передачей прав

Договор разработки ПО — это соглашение, по которому исполнитель создаёт программное обеспечение, сайт, мобильное приложение, SaaS-сервис, модуль или иной IT-продукт для заказчика.

В договоре важно закрепить не только сроки и оплату, но и техническое задание, порядок приёмки, передачу исходного кода, исключительных прав, документации и доступов.

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

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

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

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

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

Также важно прописать конфиденциальность, open-source компоненты, ответственность за нарушение сроков, гарантии оригинальности, порядок расторжения и передачу доступов.

Да. Техническое задание помогает определить, что именно должен разработать исполнитель и по каким критериям заказчик будет принимать результат.

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

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

Лучше отдельно прописать формат передачи, сроки, состав материалов и акт приёма-передачи, чтобы потом не спорить, что именно было передано.

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

Если момент перехода прав не определён, стороны могут по-разному трактовать, кто и когда стал правообладателем.

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

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

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

В договоре стоит обязать разработчика раскрывать список open-source компонентов и гарантировать, что их использование не нарушает права заказчика и третьих лиц.

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

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

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

Если критерии не прописаны, спор часто сводится к субъективной оценке: исполнитель считает работу выполненной, а заказчик — непригодной.

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

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

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

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

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

Иначе может возникнуть риск, что часть кода создана третьими лицами, а права на неё заказчику не переданы.

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

Лучше не использовать один шаблон без правок: он может не закрыть ключевые риски именно вашего проекта.

Стоимость зависит от сложности проекта, количества сторон, модели разработки, наличия ТЗ, необходимости проверить права, open-source компоненты, этапы, оплату и передачу исходного кода.

После короткого брифа можно определить, нужен простой договор, расширенный IT-договор или полный комплект документов: договор, ТЗ, акты, NDA и соглашение о передаче прав.

Нужно описание проекта, сведения о заказчике и исполнителе, модель разработки, сроки, стоимость, порядок оплаты, ТЗ или хотя бы описание функционала.

Также желательно подготовить информацию о команде, используемых библиотеках, репозиториях, доступах, передаваемых материалах и том, кому должны принадлежать права после завершения работ.