Права на код и разработку: сотрудники, подрядчики, обновления и доработки
Код, дизайн, документация, базы данных, обновления и доработки могут создаваться разными людьми и по разным договорам. Пока продукт развивается внутри компании, разрывы в оформлении прав часто остаются незаметными; они проявляются при конфликте с разработчиком, передаче прав, лицензировании, привлечении инвестиций или продаже бизнеса. В этот момент нужно установить, кому принадлежат исключительные права на отдельные результаты и чем это подтверждается.
Когда обращаться
- Продукт уже используется или приносит выручку, но код, дизайн, документацию и другие результаты создавали сотрудники и подрядчики по разным документам.
- Продукт регулярно обновляется, а права на новые версии и доработки отдельно не проверялись.
- Возник или ожидается конфликт с действующим либо бывшим разработчиком по поводу принадлежности или дальнейшего использования результатов работы.
- Планируются лицензирование, партнёрство, инвестиции, продажа бизнеса или другая сделка, для которой нужно подтвердить права на продукт.
- Нужно восстановить цепочку прав на уже существующий продукт и определить, какие документы или результаты требуют дополнительного оформления.
Как работаем
Пожар:
Когда права оспаривает сотрудник или подрядчик, продукт зависит от конкретного разработчика либо вопрос возник перед сделкой или инвестицией, поднимаем историю создания продукта: кто и на каком основании создавал отдельные результаты, какие документы оформлялись и как они использовались компанией. Это показывает, какие права уже можно подтвердить и где остаются разрывы.
Профилактика:
Для текущей разработки заранее разделяем оформление результатов сотрудников и подрядчиков, фиксируем передачу новых версий и доработок и определяем комплект документов, который должен сохраняться по каждому типу результата.
Что получает бизнес
- Карта прав на продукт: какие исключительные права принадлежат компании и какими документами это подтверждается.
- Перечень разрывов в правах на существующий код, дизайн, документацию, базы данных и доработки и способы их устранения.
- Возможность подтвердить права на продукт перед инвестором, покупателем, партнёром или лицензиатом.
- Порядок оформления новых результатов разработки, который не зависит от того, какой сотрудник или подрядчик участвовал в конкретной версии продукта.
Что важно закрепить
- Что именно создано: код, дизайн, документация, базы данных, интерфейсы, контент, обновления и доработки.
- Для сотрудников — входило ли создание соответствующего результата в трудовые обязанности, как результат передавался работодателю и использовался компанией.
- Для подрядчиков — что предусматривал договор, какие результаты переданы и приняты и кому по его условиям принадлежат исключительные права.
- Для смешанной разработки — как связать результаты сотрудников и разных подрядчиков в подтверждаемую цепочку прав на продукт.
Типовые ошибки
- Считать, что сам факт трудовых отношений автоматически делает любой созданный сотрудником результат служебным произведением.
- Проверять только первоначальную разработку и не учитывать последующие обновления и доработки продукта.
- Считать наличие договора с подрядчиком достаточным подтверждением прав, не проверяя его предмет, условия о правах и документы по фактически переданным результатам.
- Смешивать результаты сотрудников и нескольких подрядчиков, не сохраняя связь между конкретным результатом, его автором, договором и подтверждением передачи или использования.
Смотрите также
Аудит сайта по персональным данным и 152-ФЗ
Платформа / маркетплейс услуг: оферта, ответственность, платежи, споры и модерация
Утечка и незаконное распространение контента из приложения
Пользовательское соглашение для приложения: подписки, списания и возвраты
Контрафакт и персонажи: претензия правообладателя и ответственность продавца
Товарный знак для бизнеса: регистрация, претензии, лицензия и неиспользование
Претензия за использование фото: компенсация, лицензии и доказательства
