В современной цифровой экономике главный актив любой IT-компании, стартапа или бизнеса, заказавшего разработку софта, — это не серверы и не офисная мебель, а интеллектуальная собственность (ИС). Программный код, архитектура баз данных, дизайн интерфейсов (UI/UX) и алгоритмы представляют собой результаты интеллектуальной деятельности.
Огромная и, к сожалению, весьма распространенная ошибка заказчиков заключается в уверенности, что если они заплатили деньги разработчику-фрилансеру или IT-студии, то автоматически стали полноправными владельцами продукта. С юридической точки зрения это совершенно не так.
По умолчанию, согласно законодательству большинства стран (включая Гражданский кодекс РФ), первоначальным обладателем авторских прав всегда является физическое лицо — творец, чьим творческим трудом создано произведение.
Чтобы бизнес стал законным владельцем строк кода, требуется грамотно составленный договор с четко прописанной процедурой отчуждения или передачи исключительных прав.
Любая неточность в документах может привести к тому, что при попытке продать стартап инвестору (в ходе процедуры Due Diligence) выяснится, что код вам не принадлежит.
А разработчик может в любой момент запретить его использование или продать его вашим конкурентам.
Ниже представлен подробный чек-лист, который поможет провести аудит договора с разработчиком и защитить ваш главный цифровой актив.
1. Четкое определение предмета договора (Что именно передается?)
Самая частая ошибка в IT-контрактах — это размытый предмет договора. Формулировки вроде «Разработчик обязуется создать сайт» или «Исполнитель пишет программное обеспечение» не выдерживают никакой критики в суде.
Интеллектуальная собственность требует максимальной конкретизации.
В договоре должно быть предельно ясно описано, что именно создается и на что передаются права.
Это достигается за счет детального Технического задания (ТЗ), которое оформляется как неотъемлемое приложение к договору.
Что нужно проверить:
- Присутствует ли фраза о «создании результата интеллектуальной деятельности» (РИД) и «передаче (отчуждении) исключительных прав» на него заказчику.
- Есть ли ссылки на ТЗ, спецификации, макеты. Право передается не на абстрактную «идею приложения» (идеи не охраняются авторским правом), а на конкретный объективный результат: исходный код, объектный код, скрипты, графические элементы, тексты.
- Для сложных проектов полезно прописывать передачу прав на подготовительные материалы (архитектурные схемы, базы данных).
2. Разграничение авторства и исключительных прав
Фундаментальное правило авторского права гласит: личные неимущественные права (право авторства, право на имя, право на неприкосновенность произведения) неотчуждаемы.
Их нельзя купить или продать. Разработчик Вася всегда останется автором написанного им кода.
Вы покупаете исключительное (имущественное) право — то есть право использовать продукт любым законным способом: продавать, копировать, модифицировать, сдавать в аренду.
В договоре обязательно должно быть указано:
- Исключительное право передается Заказчику в полном объеме (договор об отчуждении исключительного права), а не предоставляется во временное пользование (лицензионный договор). Если вы случайно подпишете лицензию, у нее могут быть ограничения по территории, срокам и способам использования.
- Право на переработку: Вы должны иметь право вносить изменения в код без согласования с первоначальным разработчиком.
- Право на анонимность: Разработчик должен дать письменное согласие на использование продукта без обязательного указания его имени (чтобы вам не пришлось на каждой странице сайта писать «Разработано Иваном Ивановым»).
3. Вознаграждение за отчуждение прав
Передача интеллектуальной собственности по закону является возмездной. Если договор заключается между коммерческими организациями, безвозмездная передача прав может быть расценена как дарение, что прямо запрещено законом в отношениях между юрлицами (в РФ).
Многие компании просто пишут: «Стоимость разработки составляет 500 000 рублей». Этого недостаточно.
Суд может решить, что эти деньги уплачены только за часы работы (услуги), а за сами права никто не заплатил. Договор об отчуждении прав в части передачи РИД может быть признан незаключенным.
Как правильно: В договоре необходимо выделить вознаграждение за передачу исключительных прав.
Это можно сделать двумя путями: либо выделить точную сумму (например, «30% от общей суммы выплачивается за услуги по разработке.
А 70% — в качестве вознаграждения за отчуждение исключительных прав»), либо прописать, что вознаграждение за отчуждение прав уже включено в общую стоимость работ/услуг и дополнительно не оплачивается.
4. Использование Open Source, сторонних библиотек и нейросетей
Ни один современный программист не пишет проект с абсолютного нуля. В работе используются фреймворки, open-source библиотеки (с GitHub), инструменты генерации кода и нейросети (ChatGPT, GitHub Copilot).
Это создает гигантскую зону юридического риска.
Некоторые open-source лицензии (например, GPL) обладают «вирусным» эффектом: если вы вставите кусок кода под лицензией GPL в свой проприетарный коммерческий продукт, вы будете обязаны открыть исходный код всего вашего приложения. Для бизнеса это может стать катастрофой.
Отдельный вопрос касается контента и кода, сгенерированного ИИ. Юридический статус таких объектов до сих пор вызывает массу споров.
Судебная практика склоняется к тому, что ИИ не может быть автором, а значит, с чистой передачей прав на такой код могут возникнуть сложности.
Этот вопрос детально обсуждается в профессиональной среде: как обезопасить компанию при работе со сторонними ресурсами и кому де-юре принадлежат генеративные результаты — можно почитать источник, где разбираются кейсы с нейросетями и фрилансом.
Что зафиксировать в контракте:
- Разработчик обязан письменно согласовывать с заказчиком включение в проект любых компонентов со свободными лицензиями.
- Прямой запрет на использование лицензий с копилефт-эффектом (GPL и аналоги).
- Если используются сторонние платные компоненты (ассеты для игр, шрифты, фото), разработчик должен гарантировать, что приобрел соответствующие лицензии и имеет право передать их заказчику.
5. Момент перехода исключительных прав
Когда именно код становится вашей собственностью? Этот пункт вызывает больше всего споров при конфликтах.
Если момент не определен, разработчик может начать шантажировать заказчика, удерживая код.
В договоре необходимо установить точную веху. Обычно это происходит в один из двух моментов:
- В момент подписания Акта приема-передачи выполненных работ (или Акта приема-передачи прав).
- В момент 100% оплаты заказчиком выполненных работ.
Для заказчика выгоднее первый вариант (права переходят при подписании акта, даже если оплата задержалась). Для разработчика — второй.
Если проект реализуется по методологии Agile короткими спринтами, пропишите, что права переходят поэтапно — на каждый отдельный инкремент (часть кода) после оплаты или приемки соответствующего этапа.
6. Гарантии (Заверения об обстоятельствах) и ответственность (Indemnity)
Заказчик физически не может проверить каждую строчку переданного кода на предмет плагиата.
Что если разработчик фрилансер просто скопировал базу данных, принадлежащую его бывшему работодателю? Иск прилетит вам, как конечному выгодоприобретателю.
Поэтому раздел гарантий в договоре должен быть объемным и строгим. Разработчик должен гарантировать, что:
- Он является единственным автором созданного продукта (или имеет договоры с субподрядчиками, по которым права полностью очищены и переданы ему).
- В ходе разработки не были нарушены патенты, авторские права или коммерческие тайны третьих лиц.
- В продукте отсутствуют программные закладки, вредоносный код, скрытые бэкдоры.
В случае, если к заказчику поступят претензии или иски от третьих лиц относительно интеллектуальных прав, разработчик обязуется урегулировать эти претензии за свой счет.
А также возместить заказчику все понесенные убытки и судебные издержки (индемнити / возмещение потерь).
7. Процедура фактической передачи исходного кода и доступов
Передача прав на бумаге — это отлично. Но если у вас нет доступа к серверу или репозиторию, эти бумаги превращаются в бесполезную макулатуру.
Интеллектуальная собственность в IT неотделима от физического носителя или доступа к инфраструктуре.
В алгоритм приема-передачи обязательно должно быть включено:
- Передача всего исходного кода через репозитории (например, GitHub или GitLab), принадлежащие Заказчику.
- Фиксация хэш-сумм (коммитов) кода в Акте приема-передачи, чтобы точно идентифицировать ту версию программы, на которую передаются права.
- Передача администраторских доступов, паролей, ключей API.
- Передача технической документации (комментарии к коду, инструкции по деплою, архитектурная документация). Если код передан без документации, разобраться в нем новой команде будет стоить дороже, чем написать его заново.
Договор на разработку IT-решения — это не просто документ для бухгалтерии, а фундамент безопасности вашего цифрового бизнеса.
Простая скачанная из интернета «типовая форма» в 99% случаев не защитит ваши права на интеллектуальную собственность должным образом, так как не учитывает специфику работы с кодом, библиотеками и многоэтапной разработкой.
Проводя аудит договора или составляя его с нуля, обязательно пройдитесь по каждому пункту данного чек-листа.
Убедитесь, что предмет договора четко обозначен техническим заданием, права отчуждаются в полном объеме, вознаграждение за них явно выделено, а вопросы использования Open Source и ИИ-генерации урегулированы.
Только такой педантичный подход в юридических вопросах гарантирует вам, что разработанный софт будет принадлежать вам и только вам.
При этом становясь надежным и ликвидным активом вашей компании, готовым к масштабированию и защищенным от любых рейдерских и судебных нападок.
