Как правильно проверять права на программное обеспечение

При приобретении ИТ-актива ответственный покупатель всегда проверяет, что он покупает. В первую очередь это касается программного обеспечения (ПО). Если речь идет об asset-deal, нужно убедиться, что права на ПО есть у продавца, а в случае покупки долей/акций — у компании — владельца ПО. Для этого проводится процедура юридической проверки прав на ПО (due diligence). Обычно ее делает внешний консультант.

Единых правил такой проверки не существует, но есть форматы, которые принято называть «рыночной практикой». Стандарты, глубина и подходы к due diligence ПО могут сильно отличаться в зависимости от консультанта. Проверить права на цифровой актив покупатель/инвестор может и внутренними силами, если в команде есть такая экспертиза. По объективным причинам это довольно редкая ситуация — юристов, которые умеют самостоятельно проверять права на ПО, пока еще крайне мало. Поэтому обычно такие задачи отдают на аутсорсинг.

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

Почему так происходит и можно ли этого избежать?

СТАНДАРТНЫЙ ПОДХОД К DUE DILIGENCE НЕ РАБОТАЕТ

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

Почему ПО — исключение из этого правила?

Из всех объектов гражданского оборота, «чистоту» прав на которые традиционно проверяют в рамках due diligence, ПО без преувеличения является самым сложным, потому что оно

• «невидимое»/неосязаемое и
• постоянно изменяется во времени.

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

Сложность идентификации1 ПО заключается в том, что не в любой ситуации и применительно не к любому ПО возможно просто сделать ссылку на какие-либо регистрационные реквизиты или «единицы измерения» вроде размера доли или номера в реестре. Даже если ПО зарегистрировано в Роспатенте, при наличии спора стороны будут судиться не за номера и названия, а за права на конкретные исходные тексты/их части, корреляция которых с присвоенными названиями далеко не всегда прослеживается. Если зарегистрированное ПО было впоследствии существенно переработано и исходные тексты доработок не попали в ФИПС как новые версии, в споре о правах на доработки ответчик столкнется с необходимостью доказывать права на все ПО в целом.

Можно возразить, что по ГК РФ для целей лицензионного оборота прав на ПО достаточно «указания на результат интеллектуальной деятельности», что на практике обычно реализуется через название ПО и описание его функционала. Но это эффективно и «безопасно», только если у сторон нет разногласий в отношении экземпляра ПО и его «границ». А именно с таких проблем и начинаются споры о принадлежности прав на ПО (в первую очередь споры о служебном режиме ПО и плагиате2). Когда истец приходит в суд и заявляет ответчику — «это мое», «я писал строки кода №№ 137–100500 в репозитории и могу это доказать», он в первую очередь имеет в виду конкретную часть ПО, которую готов показать и сравни... ✂