Российский ИТ-рынок наполнен современными продуктами, а компании стремятся привлечь инвестиции для развития. Основой этой сферы была и остается разработка ПО и его коммерциализация.
Представим, у одной амбициозной ИТ-компании есть прибыльное ПО. Инвесторы в восторге и вкладывают в нее деньги. Документы подписали. Крупную сделку — закрыли. Шампанское — открыли. Все счастливы.
Но позже оказалось, что ПО зарегистрировано в реестре на генерального директора как на физлицо. Само ПО не поставлено на баланс в компании, а налоговая уже стучится с проверкой, так как компания неправильно применяла льготы. Так еще и бывший разработчик затаил обиду на компанию и подал иск, что он является автором ПО и хочет компенсацию, так как служебные документы никак не оформлялись.
Ситуация неприятная. Чтобы избежать подобной и не вкладывать деньги в рисковый актив, необходимо проводить Due diligence ПО.
Вот его краткий план:
1. Провести проверку реестров Роспатента и Минцифры
Первым делом, что нужно сделать перед проверкой ПО — заглянуть в реестры (Роспатент и Минцифры).
Реестр Роспатента фиксирует исключительное право на ПО, а также указывает авторов (или их отсутствие в заявке). Это важная информация, так как мы убеждаемся в исключительных правах компании на ПО, а также определяем потенциальных разработчиков для следующего шага.
Реестр Минцифры (реестр отечественного ПО) также нужно проверить. Вступить в реестр Минцифры намного сложнее, так как там особенно тщательно проверяется экспертами тех.часть. Льготы реестра дают возможность не применять НДС при использовании ПО в договорах с клиентами, а это нужно для следующего шага проверки.
Также может быть такое, что ПО не включено в реестры в целом. Тогда особенно важно проверить ПО на «юридическую чистоту».
Но нужно помнить, что включение в реестр не дает еще гарантий, что нет скрытых недостатков, поэтому идем дальше.
2. Проверить внутреннюю документацию компании
Это самый важный шаг после проверки реестров. Исключительное право на любое ПО не может быть закреплено за компанией просто так— без договора или пакета документов по внутренней разработке.
Соответственно, нужно установить, как компания получила права на ПО: через внутреннюю или внешнюю разработку. И так как ПО является объектом авторских прав, то у этого объекта всегда будет автор и правообладатель.
В случае внешней разработки нужно затребовать у правообладателя договор и акт с подрядчиком, а в договоре проверить гарантии подрядчика перед компанией о выплате вознаграждений авторам. Здесь также нужно проверить условия приемки ПО и как она прошла: в каком формате прошла приемка, был ли фактически переданы все материалы, были ли скрытые недостатки, была ли выплачена стоимость работ и прочее. Это важно для того, чтобы минимизировать риски претензий от подрядчика и убедиться в передаче всех прав на ПО.
В случае внутренней разработки нужно проверить приказы директора о начале разработки, техническое и служебное задание, назначенных разработчиков и акты о вводе программы в эксплуатацию. А также узнать, было ли выплачено вознаграждение авторам.
И, конечно, при любом раскладе нужно проверить, как компания поставила на баланс само ПО. Проверить амортизацию и оставшийся срок полезного использования. Если ПО не было поставлено на баланс, значит ПО как нематериальный актив за компанией не закреплен.
3. Запросите договоры с клиентами по использованию ПО
В этой части нужно проверить, как компания коммерциализировала ПО.
Здесь важно узнать: какие договоры компания заключает с клиентами ? Есть ли сублицензирование? Применяются ли льготы по НДС и не попадает ли ПО под исключения?
Эти вопросы важны, чтобы определить, насколько правильно компания работает с клиентами, предоставлялось ли уже ПО по сублицензированию, как правильно применяются льготы (привет, налоговая).
4. Проверить тех.часть ПО
До этого пункта казалось все более менее понятно, но зачем проверять «внутренности» ПО?
Дело в том, что ПО — это сложный объект авторского права, который состоит из множества других объектов. Код в ПО написан не только самим разработчиком — почти всегда используются компоненты с open source лицензией (Permissive или Copyleft) или же применяются компоненты с коммерческой лицензией.
Сторонние компоненты, которые берутся, например, с Гитхаба, имеют разные лицензии. Некоторые из них, например, GPL-лицензии — это «red flag» для коммерциализации и регистрации в реестре отечественного ПО.
Также важно узнать, что за компания предоставляла отдельные компоненты. Возможно, это иностранные компании, которые ушли из РФ и подключились к пакету санкций. И здесь также возникнут проблемы, которые описаны выше.
В общем, вывод по тех.части такой: нужно по максимуму запросить информацию о тех.стеке ПО у правообладателя и проверить лицензии компонентов.
Что в итоге?
Все это — только вершина айсберга по теме проведения Due diligence ПО. Дьявол, как и всегда, кроется в деталях. Любая мелочь при недостаточной проверке может обернуться потенциальными убытками для инвесторов на миллионы рублей.
Если вам нужна детальная помощь при Due diligence ПО и в целом проведении проверки компании перед инвестициями — пишите нам
