Материал

Как оформить права на ПО, если его писали подрядчики или фрилансеры

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

Короткий ответ

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

Почему оплаты разработки недостаточно

В IT-проектах часто считают: «мы заплатили разработчику — значит, продукт наш». На практике это слишком рискованная логика. Нужно смотреть конкретный договор: что именно заказано, какой результат должен быть передан, кому принадлежат права и что написано в акте.

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

Что должно быть в договоре с подрядчиком

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

  • Предмет договора. Что создается: модуль, программа, сайт, мобильное приложение, база данных, API, интеграция, доработка.
  • Техническое задание. Что именно должен сделать подрядчик, какие функции и материалы передаются.
  • Переход исключительных прав. Кому переходят права, в каком объеме и с какого момента.
  • Исходный код и документация. Передаются ли исходники, репозитории, инструкции, схемы, доступы.
  • Доработки и версии. Кому принадлежат новые модули, обновления и исправления.
  • Гарантии подрядчика. Что результат создан законно, не нарушает права третьих лиц и подрядчик вправе передать права.
  • Open-source и сторонние компоненты. Какие библиотеки используются и какие ограничения применяются.

Что должно быть в акте

Акт — не формальность. Именно он часто подтверждает, что конкретный результат был передан и принят. Чем подробнее акт, тем проще потом объяснить, что именно получила компания.

В акте желательно указывать:

  • название результата;
  • версию продукта или модуля;
  • ссылку на репозиторий или архив;
  • состав переданных материалов;
  • связь с техническим заданием;
  • переход прав, если он связан с приемкой результата;
  • дату передачи и приемки.

Что делать, если продукт уже написан давно

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

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

Что делать, если подрядчик исчез

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

Чек-лист документов

  • Договор с разработчиком или подрядчиком.
  • Техническое задание или описание результата.
  • Акты приемки с конкретным описанием переданного результата.
  • Условия о переходе исключительных прав.
  • Подтверждение оплаты.
  • Сведения о передаче исходного кода, документации и доступов.
  • Документы по доработкам, версиям и отдельным модулям.
  • Перечень open-source и сторонних компонентов.
  • Соглашения с командой, если разработка была смешанной.

Какие услуги связаны с темой

Практический вывод: права на ПО нужно оформлять не «в целом», а по конкретным результатам: код, модули, база данных, интерфейс, документация, исходники и доработки. Чем точнее документы, тем меньше рисков в реестрах, сделках и спорах.

Хотите применить это к вашей ситуации?

Напишите нам. Разберем вводные и подскажем, какие документы, правки или действия нужны именно вам.

ООО «Айти Комплаенс» · ИНН 7802974353 · ОГРН 1267800038604 · КПП 780201001
info@it-law.online · +7 (911) 964-25-85 · Работаем с IT-компаниями по всей России дистанционно.
Информация на сайте не является публичной офертой.