Кому принадлежит код: интеллектуальная собственность при разработке ПО

Кому принадлежит код: интеллектуальная собственность при разработке ПО

Короткий ответ: код принадлежит тому, кто это юридически оформил — а не тому, кто его написал или заплатил деньги. Именно здесь большинство стартапов делают дорогостоящие ошибки. Когда мы строили Pactum, я видел десятки случаев, когда компания привлекала инвестиции — и на due diligence выяснялось, что ключевой продукт формально принадлежит уволившемуся разработчику или офшорному подрядчику. Сделка срывалась.

Главные выводы:

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

---

Три сценария — три разных правовых режима

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

Советую распечатать эту таблицу и сверить с каждым действующим контрактом в вашей компании.

---

Служебное произведение: когда компания в безопасности

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

Но здесь кроется дьявол в деталях:

Что должно быть в документах:

• Трудовой договор с явным указанием, что разработка ПО входит в должностные обязанности
• Должностная инструкция или техническое задание, фиксирующее конкретные проекты
• Желательно — акт приёма-передачи результатов (особенно для ключевых модулей)

Если разработчик написал код «по личной инициативе», не в рамках служебного задания — права остаются у него, даже если он сделал это в рабочее время на корпоративном компьютере. Это серая зона, которую лучше исключить заранее.

---

Фрилансеры и подрядчики: самый частый источник проблем

Это самый распространённый сценарий в узбекистанском IT: компания нанимает разработчика через Telegram, платит на карту или через договор ГПХ, получает код — и считает, что теперь этот код её. Это не так.

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

Минимальный набор условий в договоре с фрилансером:

• Явное указание, что исключительное право на созданное ПО передаётся заказчику в полном объёме
• Момент передачи права (подписание акта, оплата — конкретно)
• Гарантия, что исполнитель не использовал чужой код без лицензии (open source — отдельный разговор)
• Запрет на использование кода для других клиентов

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

---

Open source и заимствованный код: скрытая мина

Отдельная история — open source библиотеки и компоненты. Разработчики используют их постоянно, и это нормально. Но у каждой лицензии свои условия: MIT позволяет почти всё, GPL требует открыть весь производный код, другие лицензии запрещают коммерческое использование.

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

Аналогично с AI-генерированным кодом: юридический статус кода, написанного при помощи Copilot, ChatGPT или аналогов, пока формируется в большинстве юрисдикций. Будьте готовы документировать, что именно и как создавалось.

---

Что сделать на этой неделе

• [ ] Проверить трудовые договоры разработчиков: есть ли там упоминание служебных произведений и должностных обязанностей?
• [ ] Запросить у HR список всех подрядчиков и фрилансеров за последние два года — и проверить их договоры
• [ ] Составить реестр open source зависимостей с лицензиями
• [ ] Добавить условие о передаче ИС в шаблон договора с любым внешним исполнителем
• [ ] Если есть незакрытые пробелы — подписать дополнительные соглашения до следующего раунда

---

FAQ

Если я плачу разработчику — разве код не мой автоматически?

Нет. Оплата услуг и передача исключительного права — разные юридические факты. Без соответствующего договорного условия права остаются у автора.

Разработчик уволился и говорит, что код его. Что делать?

Если трудовой договор и должностные обязанности были оформлены правильно, служебное произведение принадлежит компании. Если документов нет — спор придётся решать переговорами или в суде. Именно поэтому оформление важно до, а не после конфликта.

Нужно ли регистрировать авторское право на ПО?

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

Что если подрядчик находится в другой стране?

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

Может ли разработчик забрать свой код, если ему не заплатили?

Это зависит от договора и момента передачи прав. Грамотный договор разделяет обязательства по оплате и условия передачи ИС — чтобы неплатёж не давал автоматического права «отозвать» код из продукта.

---

*Эта статья носит общеинформационный характер и не является индивидуальной юридической консультацией. Конкретные решения зависят от деталей вашей ситуации и действующего законодательства на момент обращения.*

---

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