Интеллектуальная собственность в договорах на разработку ПО
Продвинутое3 минРедакция Innovialabs
Коротко
В договоре нужно явно указать, какие права на созданный код переходят к заказчику и когда, что остаётся у подрядчика как ранее созданный код, как учитываются open-source компоненты и по какому праву решаются споры.
Короткий ответ
Сам факт оплаты не всегда означает, что код ваш. Права определяет договор, поэтому в нём должны быть явно описаны: что передаётся, в каком объёме, с какого момента, что подрядчик оставляет себе, как используются сторонние компоненты и по какому праву разрешаются споры. Ниже — ключевые пункты. Финальный текст договора стоит согласовать с юристом, знающим применимое право.
Передача прав
Есть два основных варианта:
- Отчуждение (assignment) — исключительные права на результат переходят к заказчику полностью. Подрядчик больше не может использовать этот код.
- Лицензия — заказчик получает право использовать код, а права остаются у подрядчика. Лицензия может быть исключительной или неисключительной, ограниченной по сроку, территории и способам использования.
Что важно прописать:
- Момент перехода прав — после подписания акта, после полной оплаты или поэтапно.
- Объём — исходный код, дизайн, документация, базы данных, тексты.
- Способы использования — изменение, распространение, продажа, сублицензирование.
- Передача исходников — в каком виде и куда (репозиторий заказчика).
Ранее созданный код (pre-existing IP)
У студий и фрилансеров есть свои библиотеки, шаблоны и внутренние инструменты, которые они используют во всех проектах. Передать их вам целиком они обычно не могут и не хотят.
Нормальная практика:
- подрядчик перечисляет такие компоненты в приложении к договору;
- права на них остаются у подрядчика;
- заказчик получает бессрочную неисключительную лицензию на их использование в составе продукта.
Без этого пункта возможна ситуация, когда вы не можете передать продукт другой команде или продать компанию без согласия бывшего подрядчика.
Сторонние и open-source компоненты
Практически любой проект использует open-source библиотеки. Их лицензии различаются:
| Тип лицензии | Примеры | Что учитывать |
|---|---|---|
| Пермиссивные | MIT, Apache 2.0, BSD | Обычно нужно сохранить уведомления об авторстве |
| Копилефт | GPL, AGPL | Могут требовать открыть ваш код при распространении или сетевом использовании |
| Коммерческие | Платные SDK, шрифты, темы | Нужна купленная лицензия, часто на имя заказчика |
В договоре полезно закрепить, что подрядчик ведёт список используемых компонентов и не применяет копилефт или платные решения без согласования.
Обратная лицензия (license back)
Иногда подрядчик хочет сохранить право использовать общие наработки из вашего проекта или показывать его в портфолио. Это можно разрешить, но с границами:
- без вашей бизнес-логики, данных и уникальных алгоритмов;
- портфолио — только с вашего согласия или в оговорённом объёме;
- с учётом соглашения о конфиденциальности.
Юрисдикция и применимое право
Если стороны в разных странах, укажите:
- применимое право — законы какой страны регулируют договор;
- порядок споров — суд конкретной страны или арбитраж;
- соответствие формы передачи прав требованиям вашего законодательства, чтобы она признавалась в вашей стране.
Частые ошибки
- Договор без единого слова об интеллектуальной собственности.
- Права переходят «после завершения проекта», а проект формально не завершён.
- Нет документов о передаче прав от сотрудников и субподрядчиков самого подрядчика.
- Репозиторий и аккаунты оформлены на подрядчика.