Кристально чисто

По данным ряда исследований, в последние два года сектор TMT продолжает оставаться лидером российского рынка по количеству сделок M&A, а с осени 2023 года спрос на активы технологических компаний со стороны как стратегических, так и финансовых инвесторов демонстрирует наиболее заметный рост. Ключевым IT-активом компании выступает программное обеспечение, и критически важно, чтобы инвестор был способен правильно его оценить. О юридических аспектах оценки ПО в контексте M&A-сделки и корректном проведении due diligence ПО до ее совершения рассказывает советник практики интеллектуальной собственности юридической компании ЭБР Кристина Мкртчян.

Выйти из полноэкранного режима

Развернуть на весь экран

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

Командная работа сохраняет деньги

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

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

Идеальный сценарий due diligence выглядит так: юристы и разработчики встречаются, обсуждают детали, и каждая сторона получает необходимую ясность. Юристы понимают, кто именно является автором (чтобы в список не попал, например, менеджер, но не оказался забытым DevOps-инженер), а команда компании-таргета предоставляет четкую картину архитектуры продукта: количество подсистем, независимых модулей и их взаимосвязей. Однако в реальности ожидать подобного уровня прозрачности сложно: анализ всех документов в рамках ограниченного бюджета сделки — задача почти невыполнимая.

Факты по пунктам

Бизнесу важно понимать: в случае с ПО невозможно полностью устранить все риски и получить абсолютно точную картину. Но этого и не требуется — достаточно достичь разумной степени достоверности. Если отказаться от формального подхода к due diligence и сосредоточиться на ключевых аспектах проверки, сделать это вполне реально при условии, что именно бизнес будет задавать вектор работы юристов и помогать им отделять действительно важное от второстепенного.

Любая проверка прав на ПО должна опираться на установление следующих фактических обстоятельств: сколько в продукте самостоятельных компонентов и как они связаны; кто является их авторами; в какие периоды они создавались.

Юристы не могут выяснить это самостоятельно, однако и полностью полагаться на ответы компании тоже рискованно. Задача юристов — приложить максимум усилий, чтобы совместно с владельцем ПО собрать максимально достоверную информацию. Для этого нужно запросить у компании нужную информацию. Рекомендуем использовать следующий чек-лист. В него должны входить: подробное описание архитектуры ПО (включая его схему и перечень структурных элементов), краткое описание функционала каждого из таких элементов, чтобы определить, является ли продукт составным; данные о периоде разработки MVP (здесь важно выявить ситуации, когда работа началась раньше, чем были оформлены отношения с автором); описание процесса разработки (постановка задач, хранение кода, используемая среда разработки и, если она является электронной, отражение этого факта в локальных актах); структура команды и процесс взаимодействия (это помогает верифицировать авторов и правообладателей. Также нужно запросить у компании-таргета перечень всех лиц, имевших доступ к среде разработки, с указанием их ФИО, должности, статуса (штатный сотрудник или внештатный разработчик), роли в проекте, даты приема/увольнения или начала/окончания работы по договору и объема вклада (например, количества коммитов в репозитории). Полезным будет и описание конкретного вклада каждого участника, включая тех, кто не имел прямого доступа к информационным системам.

Дополнительно стоит обратить внимание на ряд следующих моментов: непрерывность цепочки перехода исключительных прав на ПО — от авторов до текущего правообладателя; правомерность оформления отношений при создании обновлений и новых версий ПО, их модификации и адаптации; законность владения экземплярами ПО; наличие у компании правовых оснований распоряжаться исключительными правами на ПО; наличие так называемого side-ground IP – программ, разработанных в рамках сопутствующих услуг, но не охваченных договором (например, при техподдержке).

Налоговый контекст

Многие бизнес-заказчики воспринимают риски, описанные в консультационных отчетах, как теоретические. На деле же пренебрежение ими может привести к серьезным последствиям: запрету на использование ПО (фактически — его утрате), невозможности коммерциализации продукта или его критических компонентов, искам со стороны авторов, а также влиянию на финансовую модель и налоговые обязательства компании.

Зачастую тексты договоров о распоряжении исключительными правами на ПО содержат формулировки, характерные для заказной разработки: стороны обозначены как «заказчик» и «исполнитель (подрядчик)», в тексте присутствуют формулировки о «выполнении работ (оказании услуг) по разработке» и элементы технического задания. В отдельных случаях налоговые органы могут переквалифицировать такие документы в договоры на выполнение работ (оказание услуг) по разработке ПО и доначислить НДС.

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

Кроме того, в контексте санкций и положений налогового IT-маневра правообладание ПО и состав его компонентов напрямую влияют на возможность применения налоговых льгот. Например, использование в составе «запрещенных» компонентов не позволит применять нулевую ставку по НДС при лицензировании ПО, поскольку Минцифры не зарегистрирует такое ПО в Едином реестре российских программ для электронных вычислительных машин и баз данных.

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