Договор авторского заказа в IT-отрасли
В 2026 году договор авторского заказа остаётся одним из самых опасных документов в арсенале IT-подрядчика и одновременно самым недооценённым. Парадокс в том, что именно эта конструкция, прописанная в Гражданском кодексе, по умолчанию оставляет исключительные права на программный код у разработчика, а не у заказчика. Если компания наняла фрилансера или студию по договору авторского заказа и забыла прямо указать переход прав, она рискует получить полностью оплаченный, работающий продукт - и не иметь юридической возможности им распоряжаться. Ниже - разбор ключевых особенностей, рисков и практических решений, актуальных для IT-сферы в 2026 году.
Ключевое отличие договора авторского заказа от договора подряда на создание ПО закреплено в статье 1288 ГК РФ. Если разработчик - физическое лицо, работающее по договору авторского заказа, исключительное право на созданный результат по общему правилу принадлежит самому разработчику. Заказчик получает лишь право использования произведения в объёме, предусмотренном договором, но не исключительное право как таковое.
Ситуация меняется, если исполнитель - компания или индивидуальный предприниматель, а отношения оформлены как договор подряда: тогда по статье 1296 ГК РФ исключительное право по умолчанию переходит заказчику . Наконец, если код написан штатным сотрудником в рамках трудовых обязанностей, права принадлежат работодателю в силу статьи 1295 ГК РФ.
Эта трёхуровневая система создаёт практическую проблему: одна и та же работа, выполненная разными субъектами по разным договорным конструкциям, приводит к принципиально разному распределению прав. В IT-отрасли, где разработка часто ведётся смешанными командами - штатные программисты, привлечённые фрилансеры, студии-подрядчики - отсутствие прямой формулировки о передаче исключительного права в каждом конкретном договоре означает, что часть кода может оказаться юридически «чужой» для заказчика.
Универсальное решение простое: в договоре авторского заказа необходимо прямо прописать переход исключительного права от разработчика к заказчику. Отсутствие такой формулировки - самая распространённая ошибка в IT-договорах . При этом недостаточно указать, что «заказчик приобретает все права на результат»: требуется чёткая идентификация передаваемого права (исключительное), момента перехода (подписание акта, полная оплата) и объёма использования.
Дополнительным инструментом защиты служат заверения об обстоятельствах по статье 431.2 ГК РФ. Разработчик письменно подтверждает, что код создан самостоятельно, использованные библиотеки и компоненты не нарушают прав третьих лиц, а в продукте отсутствует вредоносный код. Ответственность за недостоверность заверений наступает независимо от вины разработчика - заказчику достаточно доказать факт несоответствия. Верховный Суд подтвердил, что заверение может быть оформлено как разделом договора, так и отдельным приложением или даже деловым письмом.
Второй механизм - индемнификация по статье 406.1 ГК РФ. Она обязывает разработчика возместить заказчику расходы по претензиям третьих лиц, связанным с созданным ПО: судебные издержки, выплаченные компенсации, стоимость замены продукта . В сочетании с заверениями это создаёт финансовый щит: заверения фиксируют обещание, индемнификация обеспечивает его денежное исполнение.
Специфика IT-разработки в том, что результат редко имеет материальную форму, а его качество трудно оценить одномоментно. Суды рассматривают разработку ПО не как «творческий процесс на доверии», а как строго договорные отношения с высокими требованиями к предмету и документам. Размытое техническое задание - прямой путь к спору о незаключённости договора и переходу к правилам о неосновательном обогащении, где размер оплаты будет определяться экспертизой, а не соглашением сторон.
Практика показывает, что акт приёмки - наилучшее, но не единственное доказательство выполнения работ. Если акт отсутствует, подрядчик может доказать сдачу результата через доступ к продакшен-серверу, логи деплоя, закрытые баг-репорты, переписку о релизе и коммиты в репозитории. Однако заказчику, который планирует удерживать оплату или оспаривать качество, стоит помнить: отсутствие подписанного акта не блокирует взыскание, если исполнитель докажет фактическое использование результата.
В договоре стоит фиксировать контрольные точки: этапы, демонстрации, спринты, процедуры пользовательского тестирования (UAT). Чёткая привязка оплаты к конкретным артефактам снижает риск спора о том, что именно и когда было сдано.
Три специфических риска для IT-отрасли заслуживают отдельного упоминания:
- GPL-код в закрытом продукте. Использование компонентов под лицензией GPL обязывает открывать исходный код производного продукта. Если заказчик продаёт закрытое решение, правообладатель может предъявить иск напрямую заказчику, а не разработчику, который включил GPL-библиотеку . Заверения разработчика о перечне использованных библиотек и типов лицензий - минимальная страховка.
- Репозиторий с уволившимся разработчиком. Бывший сотрудник уходит с наработками к конкуренту, а новый наниматель не проверяет происхождение кода. Прежний работодатель подаёт иск к новой компании — и суд может встать на его сторону, если будет доказано, что код создавался в рамках трудовых обязанностей . Для заказчика, приобретающего ПО у студии, важно запрашивать подтверждение, что все разработчики состояли в трудовых отношениях с исполнителем и их права переданы студии.
- ИИ-генерация кода. Если модель обучена на охраняемых репозиториях без прозрачных лицензий, компания, включившая такой код в продукт, принимает на себя риски правообладателей обучающих данных. Претензия придёт к заказчику, а не к провайдеру ИИ. В договоре стоит запрашивать заверение, что при создании кода не использовались генеративные инструменты без проверки условий их сервиса.
Показательный кейс завершился в декабре 2025 года в Тамбовском областном суде. Системный администратор сахарного завода в 2013 году написал конфигурацию 1С для автоматизации weighing station, установил её на предприятии и забыл. В 2017 году обнаружил, что коллега с другого завода холдинга описывает эту систему как собственную разработку. Суд взыскал компенсацию, но важнее правовая логика: работодатель не смог доказать, что программа является служебным произведением, поскольку трудовой договор 2001 года истёк задолго до создания кода, а должностная инструкция не предусматривала разработку ПО.
Суд также указал на бремя доказывания: именно работодатель должен доказать, что произведение создано в пределах трудовых обязанностей, а не работник — обратное . Для IT-компаний это означает: если вы хотите получить права на код, созданный сотрудником, недостаточно факта использования офисного компьютера и лицензионной 1С. Нужны действующий трудовой договор с соответствующей функцией, должностная инструкция и формальное задание.
Для заказчиков, работающих с фрилансерами, вывод ещё жёстче: договор авторского заказа без прямой передачи прав оставляет вас с продуктом, который вы не можете ни продавать, ни модифицировать, ни защищать от претензий третьих лиц.
Перед подписанием договора авторского заказа в IT проверьте: указан ли предмет с конкретным техническим заданием или перечнем артефактов; прописан ли переход исключительного права в объёме, достаточном для коммерческого использования; включены ли заверения об обстоятельствах по статье 431.2 ГК РФ с перечнем библиотек и лицензий; предусмотрена ли индемнификация по статье 406.1 ГК РФ; зафиксированы ли контрольные точки и порядок приёмки. Если исполнитель — физическое лицо, отсутствие прямого указания на передачу исключительного права означает, что права остались у него. Это не формальность, а основание для последующих споров, которые в 2026 году стоят дороже, чем когда-либо: максимальная компенсация за одно нарушение авторских прав достигла 10 миллионов рублей.
Если после прочтения статьи у Вас остались вопросы - можете обратиться ко мне за консультацией по номеру телефона: +7 (924) 62-39-117. Буду рад Вам помочь!
