Перед продажей лицензии на программный продукт кипрской компании нужно ответить на два вопроса: какие права есть у неё самой и какие права она вправе предоставить клиенту. Доступ к репозиторию, оплата разработки и регистрация домена подтверждают разные обстоятельства. Ни один из этих документов по отдельности не описывает всю цепочку прав.
Проверку удобно проводить перед первым крупным клиентом, привлечением инвестора или переносом разработки в другую компанию группы. Результатом должен стать перечень компонентов продукта, оснований использования и недостающих документов. Налоговый режим продукта не заменяет такую проверку.
Разберите продукт на компоненты
Сначала зафиксируйте версию продукта и состав поставки. Отдельно перечислите собственный код, библиотеки, интерфейс, графику, шрифты, документацию, базы данных, модели и иные материалы. Для каждого элемента найдите автора или поставщика, дату появления, договор и условия использования. Не записывайте всё одним пунктом «ПО компании».
Кипрское ведомство интеллектуальной собственности описывает защиту оригинальных компьютерных программ и подготовительного проектного материала как литературных произведений. Охрана программного выражения не означает монополию на любую лежащую в основе идею. Для названия, базы данных, дизайна и технического решения могут потребоваться отдельные оценки.
- Компонент и его версия: что именно войдёт в лицензируемый продукт.
- Происхождение: сотрудник, основатель, подрядчик, поставщик или открытый проект.
- Основание использования: применимая норма, договор передачи, лицензия или иной документ.
- Разрешённые действия: изменение, распространение, предоставление доступа, сублицензирование.
- Ограничения и действия до выпуска: согласие, уведомление, раскрытие материала или замена компонента.
Установите права на код сотрудников
Проверьте работодателя, должность, обязанности и задания разработчика на момент создания кода. Если команда работала до учреждения кипрской компании, нынешний трудовой договор не объясняет автоматически судьбу ранних версий. При переводе сотрудника между компаниями группы проверьте права на прежние результаты.
Статья 2(3) Директивы 2009/24/EC предусматривает для программы, созданной работником при исполнении обязанностей или указаний работодателя, исключительное осуществление имущественных прав работодателем, если договором не предусмотрено иное. Для конкретного разработчика нужно установить применимое право и содержание отношений, а не ориентироваться только на место регистрации компании.
В документах полезно согласовать описание создаваемых результатов, отчётность по заданиям, передачу материалов и доступов, перечень ранее созданных инструментов и порядок работы с чужим кодом. Для деятельности вне трудовых обязанностей потребуется отдельная оценка; не включайте в реестр продукта весь личный код сотрудника без разбора.
Проверьте заказную разработку по кипрским правилам
По статье 11(1) Закона № 59/1976 предусмотрен переход авторского права к заказчику заказного произведения или работодателю в установленных случаях, с оговоркой о соглашении сторон, исключающем или ограничивающем такой переход. Поэтому для кипрского проекта нельзя заранее считать, что права любого подрядчика всегда остаются у него, либо что один платёж решает вопрос для любой трансграничной разработки.
Прочитайте договор и техническое задание: кто выступил заказчиком, какой результат заказан, какое право применимо, не сохранены ли права за исполнителем, есть ли субподрядчики. Если контракт заключён с агентством, а код писали его сотрудники и сторонние специалисты, проверьте документы по всей цепочке. Обещание агентства передать права нужно сопоставить с тем, чем оно располагает.
По статье 12(5) того же закона письменная форма предусмотрена для уступки авторского права и исключительной лицензии. Статья 11 содержит отдельное правило перехода в силу закона. В конкретной сделке разграничьте такое основание и договорное оформление: не подменяйте анализ общей фразой в инвойсе.
Согласуйте результат, момент и объём договорной передачи, территорию, способы использования и судьбу промежуточных версий. Добавьте перечень исключённых наработок и прав на них, необходимых для эксплуатации продукта. Если переход связан с оплатой, определите, какие действия доступны до неё, и не обещайте клиенту более широкие права.
Найдите ранние разработки основателей
Отдельная папка нужна для кода до регистрации компании. Соберите ранние репозитории, задания, переписку, договоры и историю участников. Проверьте, не создавалась ли эта версия в рамках прежней работы основателя или по заказу другого клиента.
Если продукт переходит между компаниями группы, опишите точный состав передаваемых прав и обязательств, полномочия сторон и необходимые согласия. Общий владелец компаний не заменяет документы передачи. В реестре продукта укажите основание, по которому именно кипрская компания вправе выдавать лицензию.
Проверьте сторонние библиотеки и готовые материалы
Попросите техническую команду подготовить список зависимостей с версиями и лицензиями. Учитывайте не только прямые зависимости, но и включённые в сборку пакеты, изображения, шрифты, примеры кода и SDK. Для каждого случая сопоставьте условия с моделью продукта: внутреннее использование, установка у клиента, распространение копий или доступ как к сервису.
Требования открытых лицензий различаются. Некоторые условия касаются сохранения уведомлений, предоставления исходников или распространения изменений; применимость зависит от лицензии и способа использования. Например, AGPLv3 содержит специальное условие взаимодействия пользователей с изменённой программой через сеть. Из этого нельзя делать вывод, что любое использование открытого кода обязывает раскрыть весь продукт.
Для кода, подготовленного с помощью генеративного инструмента, сохраните сведения об инструменте, условиях использования и проверке результата. Факт добавления фрагмента сотрудником сам по себе не подтверждает исключительные права компании. Нужны проверка происхождения, лицензий и технических рисков; универсальный вывод о правообладателе здесь не предполагается.
Сопоставьте лицензию клиенту с реальными правами компании
Лицензия должна описывать продукт и разрешённый сценарий. Уточните пользователей и компании группы клиента, среду установки, территорию, срок, ограничения по объёму и право привлекать подрядчиков. Выясните, получает ли клиент только доступ к функции, копию программы, исходный код или право создавать изменения.
- Разделите существующую платформу и доработку по заданию клиента.
- Укажите сторонние компоненты и применимые к ним условия.
- Определите права на обновления и обязанность предоставлять поддержку отдельно.
- Проверьте обещания исключительности, передачи исходников и сублицензирования.
- Согласуйте подтверждения о правах, порядок реакции на претензию третьего лица и пределы ответственности.
Ограничения лицензии нужно проверять и на соответствие обязательным исключениям. Статья 8 Директивы 2009/24/EC не допускает договорные условия, противоречащие указанным в ней исключениям. Общий запрет на любые исследования или действия пользователя нельзя переносить из чужого шаблона без такой проверки.
Закройте пробелы до обещаний инвестору или клиенту
По результатам проверки разделите находки на три группы: документы подтверждают нужные права; требуется пояснение или дополнительный документ; компонент нельзя использовать в запланированной модели без изменения условий. Для каждого пробела назначьте ответственное лицо и действие: запрос, согласование, замена компонента либо ограничение обещаний клиенту.
Не переписывайте историю разработки задним числом. Отсутствующий документ лучше обозначить и оформить допустимое решение с соответствующей стороной. Сохраняйте подписанные версии, приложения, результаты приёмки, список компонентов и историю изменений. Техническое сканирование лицензий полезно сопоставить с договорами; оно само по себе не устанавливает все права.
Для юридической помощи IT-бизнесу подготовьте архитектуру продукта, договоры команды, цепочку заказчиков и список зависимостей. Taxers может согласовать объём проверки и подготовку недостающих условий. Разработка договоров должна опираться на установленную цепочку прав и выбранную модель лицензирования.
FAQ
Достаточно ли оплаты разработки для подтверждения всей цепочки прав?
Нет. При применении кипрского правила о заказном произведении проверяют факты заказа, стороны и возможное соглашение, ограничивающее переход. Для агентства, субподрядчиков и ранних версий требуется проверить всю цепочку и применимое право.
Нужна ли письменная форма для исключительной лицензии?
Статья 12(5) предусматривает письменную форму уступки авторского права и исключительной лицензии. Отдельное правило статьи 11 о переходе в силу закона не следует смешивать с договорным оформлением конкретной передачи.
Открытая библиотека требует раскрыть весь продукт?
Не автоматически. Обязанности зависят от лицензии, версии компонента и способа использования. Упомянутое условие AGPLv3 касается взаимодействия через сеть с изменённой программой; его нельзя переносить на любой открытый код.
