Покупая код в мешке: зачем нужна юридическая проверка ПО при M&A-сделке с IT-бизнесом

Софт — ключевой актив технологических бизнесов

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

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

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

Но в любом технологическом бизнесе есть ключевой актив, роль которого невозможно переоценить, — это программное обеспечение. Именно оно обеспечивает автоматизацию, оптимизацию и глобализацию бизнес-процессов, повышает эффективность решения различных задач. Сегодня ПО — важный драйвер роста стоимости различных IT-компаний. А ряд технологий на его основе (например, ИИ) являются мегатрендами, влияющими на глобальную экономику.

Право на код

Почему перед покупкой IT-компании следует проверить права на ПО?

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

К примеру, некоторые стартапы полагают, что раз их технические специалисты имеют свободный доступ к кодовой базе ПО, то у компании есть на него права: «Мы имеем доступ, а другие — нет. Значит, это наше». Но далеко не всегда это так. В некоторых IT-бизнесах ПО рассредоточено по нескольким аффилированным компаниям. При этом встречаются ситуации, когда права на отдельное ПО принадлежат не конкретной компании, а ее отдельным работникам или основателям проекта, но те об этом не знают. А для сделки M&A нужно найти права на все ПО и консолидировать их в приобретаемой компании. В этом может помочь юридическая проверка прав на ПО.

В чем заключается экономический смысл такой проверки?

Приобретатель IT-бизнеса пытается оценить его стоимость до сделки. Обычно такая оценка проводится параллельно или до юридической проверки приобретаемой компании. Оценщик не отвечает за наличие у объекта оценки (приобретаемой компании) прав на активы (в том числе на ПО). Он полагается на данные, полученные от заказчика оценки. А те обычно подтверждают, что права на ПО и другие ключевые активы, влияющие на стоимость, принадлежат оцениваемой компании.

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

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

Внимание на ПО

На чем сфокусироваться в ходе юридической проверки прав на ПО?

Юридическая проверка прав на ПО должна установить всех лиц, которым на данный момент принадлежат права в периметре сделки M&A. В идеале правообладателем всего ПО должна оказаться приобретаемая IT-компания. Проверка также может выявить риски утраты прав на ПО в будущем. Например, проверить, есть ли у третьих лиц (например, работников компании) основания требовать признания за ними авторских прав на ПО. Если такие основания есть, это может повлечь запрет коммерциализации ПО в будущем, а значит, изменить (уменьшить) прогнозные потоки, учтенные в финансовой модели приобретаемой компании, и, соответственно, ее оценку.

Также для покупателя IT-компании важно понимать, есть ли в составе монетизируемых программных продуктов токсичные компоненты (например, ПО, имеющее «недружественное» происхождение, в том числе так называемое open source ПО). Их использование повлечет невозможность работы в различных проектах, включая проекты с госучастием.

Указанные риски могут стать критичными и оказать существенное влияние на стоимость приобретаемой IT-компании.

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

Техническое задание

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

Часто программные продукты имеют сложную структуру, состоят из множества различных компонентов и подсистем. Некоторые продукты (например, так называемые супераппы) могут включать более сотни различных модулей с самостоятельным функционалом. При этом ПО постоянно изменяется во времени, появляются его обновления, исправляются ошибки в коде. В коммерческое ПО регулярно добавляется новый функционал, и тогда на его основе появляется новое (производное) ПО. К тому же ПО сложно идентифицировать на бумаге. В юридической и технической документации одно и то же ПО, как правило, описывается, по-разному.

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

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

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

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

Расставить приоритеты

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

Как можно оптимизировать процесс проверки ПО в условиях ограниченных ресурсов?

Если речь идет о проверке внутренних разработок IT-компании, а не приобретенного готового ПО, анализ прав на такой софт должен начинаться с установления всех его авторов. Если авторов окажется не слишком много (например, меньше 50-70 человек), то лучше сделать сплошную проверку документов по каждому из них в отношении созданного ими ПО.

Если их число существенно больше, сначала следует определить, какое ПО или его части наиболее критичны для приобретаемого бизнеса (конечно, делать это должны не юристы). Таким может быть ПО, реализующее ключевую функциональность программного продукта. Например, модули в IoT-решениях, отвечающие за интерпретацию данных, полученных с датчиков систем мониторинга окружающей среды. А функция перевода результата обработки данных в PDF-формат может считаться второстепенной и не образовывать критический компонент всего продукта. Также критерием материальности конкретного ПО для бизнеса может быть объем выручки, приходящейся на различные части программного продукта. Или размер затрат на восстановление аналогичного компонента в случае его утраты.

Затем следует установить круг авторов только критичных компонентов ПО. Если их общее число по-прежнему будет велико, следует выделить авторов с наиболее существенным вкладом в кодовую базу такого ПО (например, не менее 5% от всей кодовой базы). Здесь нет единой методики, бизнес-команда может установить свой порог материальности. И уже затем сделать сплошную проверку документов по всем значимым авторам, участвовавшим в создании критичных для бизнеса компонентов ПО.

Проверка отношений IT-компании с разработчиками, внесшими наибольший вклад в создание критичного для бизнеса ПО, должна являться первым приоритетом. Если у сторон есть время и ресурсы, фокус проверки желательно расширить.

Мнение редакции может не совпадать с точкой зрения автора