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

Материал верно описывал закрытый перечень допустимых правообладателей доверенного ПО и типовые правовые ситуации, но подкреплял их вымышленной статистикой («каждый третий продукт», «десятки ситуаций») и ценами консалтинга. Разбираем требования к исключительным правам по существу, без придуманных цифр практики.

Главное: для статуса доверенного ПО права на продукт должны принадлежать Российской Федерации, субъекту РФ, муниципальному образованию, российской некоммерческой организации, гражданину РФ либо коммерческой организации под российским контролем — то есть той, где более 50% голосующих акций или долей принадлежат российским лицам. Наличие иностранного участника само по себе не препятствие: значение имеет фактический контроль, а не номинальная доля. Отдельно для разработчиков — государственных компаний действует правило: доля выручки от реализации ПО внутри своей группы лиц за прошлый год не должна превышать 30%.

Кто может быть правообладателем доверенного ПО

Перечень допустимых правообладателей закрытый: Российская Федерация, субъект РФ, муниципальное образование, российская некоммерческая организация под российским контролем, гражданин РФ, либо коммерческая организация под российским контролем. На практике большинство частных разработчиков подпадают именно под последний пункт. Российский контроль означает право прямо или косвенно распоряжаться более чем 50% голосующих акций или долей уставного капитала — присутствие иностранного участника в структуре само по себе не блокирует статус, если он не контролирует более половины голосов.

На практике проверка контроля не сводится к чтению процента доли в выписке ЕГРЮЛ. Корпоративный договор может предоставлять миноритарному иностранному участнику расширенные права вето по ключевым решениям — и такая конструкция способна создавать признаки фактического контроля даже при формальной доле ниже 50%. Именно поэтому анализ голосующих прав и корпоративных соглашений важнее простого подсчёта процентов в структуре собственности.

Что стоит проверить в цепочке передачи прав

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

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

Правило 30% выручки для компаний с госучастием

Отдельное требование касается разработчиков — государственных корпораций, государственных компаний, публично-правовых компаний, организаций с государственным участием свыше 50% и организаций из той же группы лиц. Для них доля выручки от реализации ПО внутри собственной группы лиц за последний завершённый календарный год не должна превышать 30%. Правило направлено против ситуации, когда формально коммерческий продукт госкомпании фактически продаётся только аффилированным структурам, не выходя на открытый рынок.

Ситуации, которые чаще всего требуют внимания

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

Когда проверка прав особенно важна

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

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

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: требования постановления №1937 к правообладанию.
• Реестр российского программного обеспечения, Минцифры России: базовые требования к правообладателям продукции.