Стоимость переноса прав на софт: ключевые факторы

Правовой режим перехода кода при этом остается неопределенным.

Для коммерческой сделки это создает несколько независимых рисков:

• договор отчуждения может быть признан незаключенным из-за несогласованного вознаграждения;
• покупатель может получить исходный код без полного объема прав на его использование;
• стоимость нематериального актива будет завышена или занижена;
• в состав передаваемого продукта попадут компоненты с ограниченной лицензией;
• зарегистрированное право не перейдет к приобретателю без государственной регистрации сделки.

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

Правовая природа сделки: отчуждение, лицензия и разработка

Исключительное право на программу для ЭВМ можно передать полностью или предоставить в ограниченном объеме. Это разные конструкции.

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

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

• на определенной территории;
• в течение установленного срока;
• определенными способами;
• с ограничением по числу пользователей, экземпляров или серверов;
• с исключительностью или без нее.

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

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

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

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

Безвозмездное отчуждение между коммерческими организациями нельзя использовать как универсальный способ снизить цену сделки. Договор должен содержать возмездное условие. Это не означает, что цена обязана совпадать с рыночной стоимостью. Стороны могут договориться о другой сумме. Но сумма или порядок ее определения должны быть зафиксированы.

Три подхода по ФСО №11

Оценка прав на ПО строится по трем классическим подходам:

1. доходному;

2. затратному;

3. сравнительному.

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

Доходный подход

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

В расчет могут попадать:

• выручка от продажи лицензий;
• платежи за подписку;
• доход от SaaS-модели;
• роялти;
• экономия затрат при внутреннем использовании;
• доход от интеграции ПО в более крупный продукт;
• остаточная стоимость после периода прогнозирования.

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

Доходный подход рационален, если у программы есть финансовая история или обоснованный план монетизации. Он применим к:

• корпоративным платформам;
• специализированным системам автоматизации;
• программам с действующей клиентской базой;
• продуктам с регулярной подписной выручкой;
• middleware и API-продуктам, встроенным в бизнес-процессы.

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

При доходном подходе отдельно анализируются:

• churn;
• ARPU;
• срок удержания клиента;
• стоимость привлечения;
• валовая маржа;
• доля инфраструктурных расходов;
• объем обязательной поддержки;
• зависимость от одного канала продаж;
• доля выручки от крупных клиентов;
• срок экономически полезного использования.

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

Затратный подход

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

Рассматриваются:

• трудозатраты на разработку;
• проектирование архитектуры;
• создание backend и frontend-компонентов;
• тестирование;
• DevOps;
• подготовка документации;
• управление проектом;
• исправление дефектов;
• перенос данных;
• создание средств развертывания;
• расходы на лицензии и инфраструктуру.

Расчет может идти от стоимости воспроизводства или замещения.

Стоимость воспроизводства отвечает на вопрос: сколько будет стоить создать максимально похожий продукт с аналогичной структурой.

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

Для оценки старого desktop-софта это различие принципиально. Программа может быть написана на устаревшем стеке, использовать монолитную архитектуру и не иметь CI/CD. Воспроизведение такого решения будет дорогим, но не обязательно рациональным. Замещение может потребовать другой технологии, новой модели хранения данных и иной схемы развертывания.

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

При расчете затрат нужно отделять:

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

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

Сравнительный подход

Сравнительный подход использует сведения о сопоставимых рыночных сделках. Сравниваются не названия продуктов, а параметры передаваемого права и экономику объекта.

В анализе могут учитываться:

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

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

Нельзя сопоставлять:

• бессрочную передачу исключительного права с годовой лицензией;
• готовый SaaS-бизнес с исходным кодом без клиентской базы;
• платформу с активной выручкой и внутреннюю утилиту;
• продукт с зарегистрированными правами и код с невыясненным авторством;
• сделку по приобретению компании и договор отчуждения ПО.

Сравнительный подход полезен как контрольный. Он позволяет увидеть, насколько результат доходного или затратного расчета соответствует рынку. Но при отсутствии качественных аналогов он не должен использоваться механически.

Как проверить ключевые факторы стоимости

Стоимость прав на софт формируется из нескольких групп параметров. Удобно разделять их на четыре слоя: право, технология, экономика и эксплуатация.

Правовой слой

Юридическая чистота определяет, получает ли покупатель актив вообще. Если правообладатель не может подтвердить цепочку перехода прав, расчет стоимости теряет практический смысл.

Проверяются:

• авторы и разработчики;
• трудовые договоры;
• договоры с подрядчиками;
• акты приема-передачи;
• условия об отчуждении прав;
• использование open source;
• права на графику, шрифты и документацию;
• наличие залога или иных обременений;
• судебные споры;
• регистрация программы в Роспатенте;
• соответствие фактического состава продукта заявленному.

Регистрация в Роспатенте не создает авторское право. Авторское право на программу возникает в силу факта создания. Но если программа зарегистрирована, договор об отчуждении исключительного права подлежит государственной регистрации. Без нее переход зарегистрированного права признается несостоявшимся.

Это отдельный процедурный риск. Подписание договора и передача репозитория не заменяют государственную регистрацию, если она требуется для конкретного объекта.

Технологический слой

Технический аудит должен отвечать на вопрос: что именно передается и насколько этот объект пригоден к дальнейшей эксплуатации.

Минимальный состав анализа:

• архитектурная схема;
• языки программирования и версии runtime;
• список сервисов;
• структура базы данных;
• API;
• схема авторизации;
• механизм обновлений;
• процесс сборки;
• CI/CD pipeline;
• deployment manifests;
• конфигурация k8s, если она используется;
• мониторинг и logging;
• резервное копирование;
• тестовое покрытие;
• документация;
• список известных дефектов;
• перечень зависимостей.

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

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

Отдельно анализируется vendor lock-in. Если программа работает только на конкретной cloud-платформе, зависит от закрытого API или требует лицензии одного поставщика, покупатель получает не полностью автономный актив. Часть экономической ценности фактически принадлежит внешней инфраструктуре.

Экономический слой

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

Анализируются:

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

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

Desktop-программа, рассчитанная на конкретную версию Windows, может быстро потерять ценность при изменении системных API. Внутренняя система на стабильном стеке может сохранять полезность дольше, если ее база данных, интеграции и бизнес-правила продолжают работать.

Для мобильных решений и веб-сервисов срок полезного использования дополнительно связан с:

• изменениями App Store и Google Play;
• требованиями к privacy;
• версиями SDK;
• протоколами авторизации;
• поддержкой устройств;
• изменениями cloud API;
• требованиями к сертификации.

Эксплуатационный слой

Покупатель приобретает не только возможность открыть исходный код. Он получает будущие расходы.

В эксплуатационную оценку включаются:

• команда сопровождения;
• on-call;
• исправление критических дефектов;
• security patching;
• обновление зависимостей;
• миграции базы данных;
• поддержка пользователей;
• инфраструктурные расходы;
• SLA;
• обучение новой команды;
• восстановление отсутствующей документации.

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

Факторы, которые повышают и снижают стоимость

Влияние параметров нельзя сводить к простому списку. Один и тот же признак может иметь разный эффект в зависимости от модели эксплуатации.

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

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

Ошибки в договорах разработки

На практике основная проблема появляется в смешанных договорах. Заказчик оплачивает разработку, а затем считает, что автоматически получил исключительные права. Исполнитель считает, что передал только результат работ или право использования. Обе позиции могут не совпасть с текстом договора.

Типовые дефекты:

1. Общая цена без выделения вознаграждения за права.

Указывается сумма проекта, но не определено, какая ее часть относится к отчуждению исключительного права.

2. Ссылка на передачу прав без описания объекта.

В договоре нет версии программы, перечня модулей, репозитория, документации и зависимостей.

3. Передача только бинарных файлов.

Заказчик получает исполняемую сборку, но не получает исходный код, build pipeline и инструкции развертывания.

4. Неопределенный момент перехода права.

Неясно, происходит ли переход после оплаты, подписания акта, передачи исходников или государственной регистрации.

5. Отсутствие регулирования pre-existing code.

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

6. Игнорирование open source.

В составе продукта есть компоненты с copyleft-лицензией или обязанностями по раскрытию производного кода.

7. Смешение прав и поддержки.

Передача права, гарантийное исправление дефектов и дальнейшее сопровождение включены в одну формулировку.

8. Нет гарантий о правах третьих лиц.

Правообладатель не подтверждает отсутствие претензий авторов, бывших сотрудников и подрядчиков.

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

Как разделить цену разработки и цену прав

Практический договор обычно разделяет минимум четыре блока:

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

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

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

Процедура оценки и состав материалов

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

Обычно в него входят:

• договоры разработки;
• акты приема-передачи;
• документы о регистрации программы;
• сведения об авторах;
• исходный код;
• техническое задание;
• архитектурная документация;
• пользовательская документация;
• сведения о клиентах и выручке;
• данные о лицензиях;
• список сторонних компонентов;
• договоры поддержки;
• информация о затратах на инфраструктуру;
• сведения о судебных спорах и обременениях;
• roadmap и планы развития.

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

Также нужно определить границы объекта:

• входит ли мобильное приложение;
• входят ли серверные компоненты;
• передается ли административная панель;
• входят ли базы данных;
• передаются ли домены;
• включены ли модели машинного обучения;
• передаются ли ключи и сертификаты;
• входят ли скрипты миграции;
• остается ли у продавца право использовать универсальные библиотеки.

Если объект описан слишком широко, стороны получают разные представления о том, что именно было куплено. Если слишком узко — покупатель получает право на код, который невозможно развернуть без недостающих сервисов.

Актуальность отчета и регистрационные действия

Рыночная стоимость, определенная независимым оценщиком в официальном отчете, рекомендуется к использованию при совершении сделки в течение шести месяцев с даты составления отчета. Это не означает, что через шесть месяцев стоимость автоматически становится нулевой. Меняется период актуальности отчета как документа для сделки.

На стоимость за этот период могут повлиять:

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

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

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

1. идентифицировать зарегистрированный объект;

2. проверить совпадение объекта в реестре и фактического состава программы;

3. согласовать договор отчуждения;

4. зафиксировать вознаграждение;

5. оформить передачу исходных материалов;

6. подать документы на государственную регистрацию;

7. подтвердить переход права;

8. передать доступы, ключи и эксплуатационную документацию.

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

Как выбрать метод оценки

Оптимальный подход зависит от типа продукта.

Один метод редко дает достаточную картину. Доходный расчет может завысить стоимость из-за оптимистичного прогноза. Затратный — не учесть рыночный потенциал. Сравнительный — опереться на слабые аналоги.

Архитектурный комитет обычно рассматривает не одну цифру, а диапазон и причины отклонений. Для принятия решения нужны:

• базовый сценарий;
• консервативный сценарий;
• перечень корректировок;
• чувствительность к ключевым параметрам;
• оценка затрат после сделки;
• правовые условия, при которых расчет остается действительным.

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

Что снижает цену сильнее всего

Снижение стоимости часто связано не с отсутствием функций, а с невозможностью контролируемо использовать продукт после сделки.

Наиболее существенные негативные факторы:

• нет подтвержденной цепочки прав;
• исходный код не собирается из переданного репозитория;
• отсутствует документация;
• критические доступы находятся у бывшего подрядчика;
• применяются компоненты с неясными лицензиями;
• продукт зависит от закрытого API;
• нет тестов и процедуры rollback;
• база данных не имеет схемы миграции;
• известны нерешенные security issues;
• отсутствует план обновления зависимостей;
• лицензия на инфраструктурный компонент не передается;
• ключевая функциональность реализована вручную вне системы;
• реальная стоимость сопровождения не отражена в финансовой модели.

В такой ситуации покупатель платит не только за право, но и за восстановление управляемости. Если стоимость remediation не вычтена из цены, сделка выглядит дешевле только на этапе подписания.

Техническая проверка до определения цены

До финального отчета оценки полезно зафиксировать минимальный технический baseline:

• успешная сборка из чистого окружения;
• воспроизводимое развертывание;
• наличие dependency lock-файлов;
• описание переменных окружения;
• доступ к CI/CD;
• проверка backup и restore;
• запуск тестов;
• анализ уязвимостей;
• инвентаризация open source;
• проверка лицензий;
• описание внешних интеграций;
• подтверждение прав на домены, сертификаты и аккаунты;
• фиксация версии, которая входит в сделку.

Это не формальность. Без baseline невозможно понять, передается ли работающий продукт или набор разрозненных материалов.

Практическая модель расчета сделки

Для предварительного анализа стоимость прав можно рассматривать как результат нескольких корректировок:

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

Это не универсальная математическая формула и не заменяет отчет оценщика. Она нужна для декомпозиции переговоров.

Если продавец называет единую цену, следует разложить ее на компоненты:

1. стоимость самого исключительного права;

2. стоимость исходного кода и документации как состава передачи;

3. стоимость transition support;

4. стоимость исправления дефектов;

5. стоимость лицензий и инфраструктуры;

6. стоимость клиентских или операционных активов, если они передаются отдельно.

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

Итоговая проверка перед подписанием

Перед заключением договора отчуждения исключительного права на ПО нужно зафиксировать следующие позиции:

• объект сделки описан через конкретную программу, версию и состав компонентов;
• передавается именно исключительное право, а не ограниченная лицензия;
• сумма вознаграждения за отчуждение указана отдельно;
• порядок расчета вознаграждения определим без дополнительных договоренностей;
• подтверждена цепочка прав от авторов и подрядчиков;
• проверены open source-компоненты и их лицензии;
• определен состав исходного кода;
• передается техническая документация;
• описаны CI/CD, deployment и процедуры восстановления;
• проверены сторонние API и cloud-зависимости;
• учтен vendor lock-in;
• рассчитаны расходы на поддержку и модернизацию;
• определен срок экономически полезного использования;
• выбран и обоснован метод оценки;
• проверены сопоставимые сделки, если используется сравнительный подход;
• прогноз денежных потоков подтвержден операционными данными;
• учтен технический долг;
• проверены обременения и споры;
• установлена необходимость регистрации в Роспатенте;
• при наличии регистрации подготовлена процедура регистрации перехода;
• отчет оценщика не старше периода практической актуальности;
• переходные обязанности продавца вынесены в отдельный блок;
• акт передачи содержит полный перечень материалов, доступов и компонентов.

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

Если хотя бы один из этих слоев не подтвержден, итоговая сумма становится предположением. Для enterprise-сделки этого недостаточно. Аудит должен завершаться не только цифрой, но и перечнем условий, при которых право действительно можно использовать после передачи.