Самая дорогая ошибка в разработке обычно обнаруживается не на релизе, а позже — когда компания не может подтвердить, кому принадлежат исходный код, дизайн, документация и права на использованные компоненты. Сам факт оплаты работ не всегда означает переход исключительных прав: значение имеют статус исполнителя, условия договора и фактический порядок создания результата.
В российском праве программа для ЭВМ охраняется как объект авторского права с момента создания кода, без обязательной регистрации. Но бизнесу недостаточно формального возникновения права. Нужна понятная цепочка перехода прав: от каждого автора или подрядчика к компании, которая выпускает продукт, привлекает инвестиции, продаёт лицензии или предоставляет сервис клиентам.
Правовая архитектура начинается до первой задачи в трекере
До начала работ стоит определить, кто заказывает продукт, кто принимает решения по функционалу и какие результаты должны быть созданы. Формулировок вроде «сайт», «приложение» или «платформа» для договора обычно недостаточно. В техническом задании или другом приложении лучше обозначить состав продукта: серверную и клиентскую части, мобильные приложения, API, базу данных, личный кабинет, дизайн-макеты, административную панель, документацию, тесты и инфраструктурные конфигурации.
Важно сразу отделить собственную разработку от внешних элементов. В продукте могут использоваться библиотеки с открытым исходным кодом, шрифты, иконки, стоковые изображения, SDK, сервисы аналитики и облачная инфраструктура. По каждому такому объекту должны быть понятны источник, лицензия и допустимый способ использования.
Кому принадлежат права на код
Штатные сотрудники
Код, созданный работником в пределах трудовых обязанностей или по конкретному заданию работодателя, может признаваться служебным произведением. Как правило, исключительное право в такой ситуации принадлежит работодателю, если договором не установлено иное. Однако полагаться только на общее правило рискованно: должностная инструкция разработчика, трудовой договор, постановка задач и порядок передачи результатов должны подтверждать связь работы с трудовой функцией.
Обычно компания закрепляет в документах обязанность создавать результаты интеллектуальной деятельности для работодателя, условия конфиденциальности, порядок уведомления о создании результата, а также передачу репозиториев, ключей, документации и иных материалов при увольнении.
Подрядчики, студии и фрилансеры
В договоре с независимым исполнителем нужно прямо определить судьбу исключительных прав. Он должен предусматривать либо отчуждение исключительного права, либо лицензию с чётко обозначенным объёмом полномочий. Если компании необходимо дорабатывать продукт, продавать его, передавать партнёрам и защищать от копирования, обычно требуется передача исключительного права в полном объёме либо широкая исключительная лицензия — с учётом модели конкретного проекта.
Фразы «результат принадлежит заказчику» может быть недостаточно. Лучше перечислить передаваемые объекты и способы использования, определить момент перехода права, вознаграждение за распоряжение правом и обязанность исполнителя передать исходники. Отдельно стоит получить гарантии, что исполнитель не нарушил права третьих лиц и вправе передать созданный результат.
Что предусмотреть в договоре на разработку
Договор не заменяет техническое задание, но должен связать разработку, приёмку и интеллектуальные права в одну понятную систему. Для проектов с несколькими этапами удобны спецификации, задания на спринты или приложения с версиями: они помогают подтвердить, что именно было заказано и принято.
- Предмет и состав работ: функциональные требования, платформы, интеграции, ограничения и ожидаемые результаты.
- Сроки и этапы: контрольные точки, зависимость сроков от действий заказчика, порядок изменения требований.
- Приёмка: критерии тестирования, срок для мотивированных замечаний, формат актов и порядок исправления дефектов.
- Права на результаты: перечень объектов, момент перехода, территория, срок и цена передачи права или лицензии.
- Исходный код и доступы: репозитории, история изменений, ключи, домены, аккаунты в магазинах приложений и облачных сервисах.
- Конфиденциальность: защита бизнес-логики, данных, документации, планов релиза и учётных данных.
- Гарантии и ответственность: пределы гарантий, порядок устранения ошибок и последствия нарушения прав третьих лиц.
Электронную приёмку тоже нужно согласовать заранее. Подтверждением могут служить сообщения через определённый корпоративный сервис, письма с согласованных адресов или действия в системе управления проектами — если договор признаёт юридическое значение таких действий и позволяет установить отправителя.
Открытый код: не «бесплатный», а лицензируемый
Open source-компоненты часто сокращают сроки разработки, но не становятся собственностью компании только потому, что размещены в публичном репозитории. Условия их использования определяет конкретная лицензия. Обязанности могут варьироваться от сохранения уведомлений об авторстве до предоставления исходного кода производного продукта при его распространении.
Особого внимания требуют компоненты с copyleft-условиями, если продукт распространяется среди клиентов, поставляется on-premise или встраивается в оборудование. Нельзя механически переносить требования одной лицензии на другую: значение имеют точная версия компонента, способ интеграции и модель поставки продукта.
Полезный рабочий инструмент — реестр компонентов. В нём указывают название и версию библиотеки, источник, лицензию, назначение, ответственного сотрудника и выполненные обязательства по уведомлениям. Такой реестр нужен не только перед аудитом или сделкой: он помогает быстрее реагировать на уязвимости и запросы клиентов о составе ПО.
Данные, интерфейсы и материалы пользователей
Если продукт обрабатывает персональные данные, юридическая работа не ограничивается публикацией политики конфиденциальности. Необходимо определить роли участников обработки, цели и состав данных, правовые основания, сроки хранения, меры защиты, порядок работы с обращениями субъектов и условия привлечения подрядчиков, которым предоставляется доступ к информации.
Отдельные правила требуются для пользовательского контента. В пользовательском соглашении обычно фиксируют, какую неисключительную лицензию пользователь предоставляет сервису для технического размещения, отображения, модерации и резервного копирования материалов. Объём такой лицензии не должен быть шире, чем того требует функция сервиса и заявленная бизнес-модель.
Интеграции по API следует проверять не только по технической документации, но и по договорным условиям поставщика: лимитам запросов, запретам на отдельные способы использования данных, правилам кэширования, требованиям к атрибуции, основаниям для блокировки доступа и распределению ответственности при сбоях.
Доказательства создания и контроль релиза
В споре важны не декларации о разработке, а документы и цифровые следы: договоры, акты, постановки задач, коммиты, журналы доступа, переписка о согласовании макетов, счета и результаты тестирования. Репозиторий разумно размещать в аккаунте компании, а не в личном профиле разработчика. Доступы к доменам, облаку, системам рассылок, аналитике и публикации мобильных приложений также должны учитываться и контролироваться организацией.
Перед релизом стоит пройти короткий юридический чек-лист: подтверждены ли права на код и дизайн, проверены ли сторонние компоненты, оформлены ли документы по данным, опубликованы ли пользовательские условия, назначены ли владельцы критически важных аккаунтов, подготовлен ли порядок реакции на претензии. Такой контроль не исключает споры, но позволяет выявить риски до запуска, когда корректировка архитектуры и договоров обычно обходится дешевле.
Если продукт создаётся для нескольких компаний
Совместная разработка учредителями, интегратором и заказчиком без отдельного соглашения нередко становится причиной конфликта при масштабировании проекта. Лучше заранее определить владельца исключительных прав, режим использования результата каждой стороной, порядок финансирования доработок, право на публикацию кейса, доступ к исходному коду после прекращения сотрудничества и судьбу результатов, созданных после разделения проекта.
Например, интегратор может создать универсальный модуль, а заказчик — оплатить его адаптацию под собственные процессы. В договоре можно разграничить права на базовую платформу и кастомизацию. Без этого сторонам сложнее доказать, что допустимо повторно использовать в других проектах, а что осталось уникальным результатом конкретного заказа.
Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию. Формулировки договора и обязательные требования зависят от юрисдикции, модели распространения ПО, состава участников и фактического процесса разработки.