Право на софт при покупке бизнеса: due diligence прав на ПО — чек-лист
Обычно всё начинается невинно: собственник показывает цифры, улыбается, обещает «вот тут вообще золотая жила», а вы киваете и уже мысленно выбираете стул в новом кабинете. И только потом, ближе к ночи, когда в переписке всплывает фраза «а софт-то наш, самописный», в голове тихо щёлкает тумблер. Потому что «право на софт» в сделке это не про красоту формулировок, а про то, сможете ли вы завтра законно пользоваться тем, за что платите сегодня.
Я видела истории, где бизнес внешне был бодрый: сайт работает, CRM крутится, склад шевелится, интеграции шлют уведомления в Telegram. А внутри выяснялось: доступы на разработчика-фрилансера, лицензии на «коммерцию» оформлены на бывшего бухгалтера, а часть модулей вообще собрана из того, что «мы где-то скачали и поставили». Пара таких находок, и сделка превращается в квест с неприятными призами: от блокировки сервисов до требований правообладателей. Поэтому проверка лицензии ПО и прав на разработку это тот редкий случай, когда занудство экономит деньги.
После этого текста у вас будет рабочий маршрут: что запросить у продавца, где чаще всего прячутся проблемы, как понять, что права на ПО реально переходят, и как автоматизировать сбор бумажек и подтверждений через Make.com, чтобы не тонуть в чатах и папках «Документы_финал_точно2». По ходу аккуратно разберём и странные поисковые запросы, которые встречаются в сети вроде «скачать рут права на софт» или «софт без рут прав на андроид», чтобы сразу отделить легальную реальность бизнеса от всего, что пахнет обходами и серыми практиками.
Пошаговый гайд: как проверить право на софт перед покупкой
Шаг 1. Собираем карту всего ПО, без стыда и приукрашиваний
Первое, что делаем: просим полный перечень программ и сервисов, без которых компания встанет. Это не только «большие штуки» вроде 1С, CRM или ERP, но и почта, облака, телефония, таск-трекеры, аналитика, виджеты на сайте, плагины, платёжные модули, приложения для курьеров, кассовые драйверы. Зачем: вы покупаете бизнес-процесс, а он часто держится на конкретных подписках и лицензиях, которые могут быть не передаваемыми. Типичная ошибка здесь простая: смотреть только на сервер и «самопис», забывая, что половина работы живёт в SaaS и маркетплейс-плагинах, а без них всё рассыпается за сутки. Проверяем, что всё работает: открываем реальные аккаунты, смотрим активные подписки, сверяем домены, номера договоров, даты оплаты и кто указан владельцем. И сразу фиксируем, где ПО стороннее, где собственная разработка, где доработка чужого решения, потому что юридически это три разные песни.
Отдельно про запросы уровня «софт рут права на андроид», «софт без рут прав на андроид» и даже «софт на стандофф без рут прав» или «софт на стандофф 2 без рут прав». В бизнес-проверке это обычно всплывает не как цель, а как красный флажок: если внутри компании кто-то предлагает «поставить софт без лицензий» или «скачать рут права на софт», это не про оптимизацию, а про риск. В сделке держитесь легальной стороны: лицензии, договоры, исходники, акты, передача прав. Любые обходы ограничений не ваша экономия, а ваша будущая головная боль.
Шаг 2. Делаем проверку лицензии ПО: что куплено, на кого и на каких условиях
Дальше начинается любимое: проверка лицензии ПО. Вам нужно понять, какие права на использование у компании есть сейчас и смогут ли они «переехать» к вам. Запрашиваем лицензионные договоры, счета, акты, письма от вендоров, скриншоты из личных кабинетов, ключи, серийники, сведения о тарифах и лимитах. Зачем: в лицензиях часто спрятаны ограничения по числу пользователей, филиалам, территории, способу использования, сроку, запрет на передачу третьим лицам. Типичная ошибка: думать, что «мы же оплатили подписку» равно «мы всем владеем». Проверяем, что всё работает: сверяем фактическое использование с условиями лицензии, смотрим, не нарушены ли лимиты, и кто юридически указан лицензиатом. Отсюда же растут запросы вроде «проверка лицензии по номеру» и «проверка лицензии по номеру автомобиля» из другой сферы, но логика похожа: ищем идентификатор и подтверждение статуса. Только для ПО «номер» это, как правило, номер договора, аккаунт, заказ, лицензия в кабинете, а не магическая кнопка «проверить всё».
Мини-кейс: покупатель берёт интернет-магазин, сделку планируют закрыть за 10 дней. На созвоне выясняется, что платформа рассылок и CRM оплачены с личной карты бывшего маркетолога, а доступы у неё в почте на домене, который уже не продлили. За два вечера через Make.com настроили сбор подтверждений: письма от вендоров с чеками автоматически складывались в облачную папку, а из темы письма вытягивался срок действия подписки и попадал в таблицу. Эффект был скучный, но приятный: продавец перестал «искать документы», а покупатель увидел, где нужна переоформлялка, ещё до подписания основного договора.
Шаг 3. Разбираем «самопис» и исходники: кто автор и кому принадлежат исключительные права
Если в бизнесе есть собственные разработки, вопрос «право на софт» становится прямым и жёстким: у кого исключительные права, и оформлены ли они документами. Запрашиваем договоры с разработчиками (штат, ГПХ, подряд), техзадания, акты сдачи-приёмки, условия об отчуждении или лицензии, служебные задания, положения о служебных произведениях, локальные акты, если есть. Зачем: без правильной цепочки прав вы покупаете не продукт, а надежду. Типичная ошибка: верить фразе «делал наш программист, значит наше». В РФ права у автора возникают автоматически, а вот у компании они появляются только при корректном оформлении. Проверяем, что всё работает: смотрим, что договор прямо закрывает вопрос исключительных прав, что акты подписаны, что нет «дырок» по старым подрядчикам и что исходники реально существуют и передаются, а не лежат на ноутбуке «у Пети».
Ещё одна важная часть: библиотеки с открытым исходным кодом и чужие компоненты. Это не зло, это нормально, но их лицензии могут требовать раскрытия исходников или ограничивать коммерческое использование. Тут часто ломаются сроки: юристы читают договоры, технарь молчит, и никто не хочет признаться, что проект собирался «на коленке». Ускоряет жизнь простая практика: попросить выгрузку зависимостей и список сторонних компонентов, а затем проверить их лицензии. И да, если вы вдруг видите в переписках обсуждения вроде «софт на стандофф тг рут права», это не про интеллектуальную собственность, а про странные способы что-то обойти. В due diligence такое фиксируют как комплаенс-риск и повод задавать дополнительные вопросы.
Шаг 4. Проверяем договоры с поставщиками и подрядчиками: поддержка, обновления, ответственность
Когда список ПО и права на разработку собраны, смотрим договорную «обвязку»: хостинг, облака, техподдержка, интеграторы, обслуживающие компании, подрядчики на доработки. Зачем: даже если право использовать софт у вас будет, без поддержки он может деградировать за пару месяцев, а иногда и за пару дней после смены владельца. Типичная ошибка: подписывать сделку, не понимая, что критичный подрядчик работает «по дружбе» и может исчезнуть вместе с прежним собственником. Проверяем, что всё работает: сверяем контакты, SLA, сроки реакции, условия расторжения, порядок передачи доступов, наличие NDA и пунктов про конфиденциальность, особенно если подрядчик имел доступ к базам клиентов и внутренним данным.
Здесь же уместно думать про автоматизацию рутины. Make.com можно использовать как сборщик: вытягивать договоры и счета из почты (Яндекс 360, Gmail), сортировать по поставщикам, ставить напоминания о продлении, и отправлять уведомления в Telegram ответственным, чтобы не случилось «ой, домен сгорел». Никакой магии, просто дисциплина, которая переживает смену собственника. Если вы любите держать всё под рукой, то такой сценарий превращает хаос в аккуратную папку и понятный календарь.
Шаг 5. Сверяем соответствие требованиям по данным и безопасности: не только права, но и риски
Юридическая чистота софта бессмысленна, если он дырявый как сито и тащит персональные данные в неизвестном направлении. Смотрим, какие данные обрабатываются, где хранятся, кто имеет доступ, как устроены резервные копии, как обновляется ПО, ведётся ли журналирование, есть ли регламент реагирования на инциденты. Зачем: смена владельца часто запускает «переезд» инфраструктуры, и именно в этот момент всплывают уязвимости и забытые учётки. Типичная ошибка: проверять безопасность «на глаз», по принципу «у нас же антивирус стоит». Проверяем, что всё работает: просим отчёты о патчах и обновлениях, результаты сканирований, историю инцидентов, проверяем, что доступы привязаны к корпоративным аккаунтам, а не к личным телефонам бывших сотрудников.
Мини-кейс: покупали небольшую службу доставки, и всё выглядело нормально, пока не выяснилось, что резервные копии делаются раз в месяц вручную, а пароль от админки сайта одинаковый для всех. Сделку не отменили, но цену и условия перехода пересобрали: заложили время на приведение в порядок, прописали обязанность продавца передать доступы и сменить их до закрытия. Make.com тут пригодился неожиданно: настроили регулярные напоминания о проверке бэкапов и отчёт о статусе в общий чат, чтобы не надеяться на память «само как-нибудь».
Шаг 6. Оформляем передачу прав и доступов так, чтобы бизнес не умер на второй день
Финальный технически-юридический шаг: готовим план передачи. Это отдельная история: что переоформляется, что переносится, где нужна новая лицензия, а где достаточно смены реквизитов, кто и когда отдаёт доступы, как фиксируется передача исходников, документации и ключей. Зачем: даже идеально проверенное ПО можно потерять из-за банальной задержки, когда продавец «завтра пришлёт», а завтра уехал в отпуск. Типичная ошибка: думать, что достаточно пункта «права переходят» в договоре купли-продажи доли или бизнеса. Проверяем, что всё работает: делаем тестовый вход в критичные системы на корпоративные аккаунты покупателя, получаем подтверждения от вендоров о переоформлении, фиксируем акт передачи носителей и доступов, а по самопису прямо перечисляем, что именно передано (репозитории, базы, документация, сборки).
И да, рядом с темой «купить лицензию ПО» часто в поиске болтаются странные соседи: «купить оружие по лицензии», «купить пистолет по лицензии», «можно ли купить патроны по лицензии». Это просто шум популярности слова «лицензия». В вашей сделке лицензии должны быть про ПО и про законное право использования, без серых «купить ключ подешевле» и без попыток «обойти» ограничения. Такая экономия обычно заканчивается переплатой, только уже в другом месте.
Подводные камни: где чаще всего всё ломается
Самая частая поломка это «не та сторона договора». Лицензии оформлены на ИП владельца, на аффилированную компанию, на сотрудника, на подрядчика, на кого угодно, только не на юридическое лицо, которое вы покупаете. На бумаге это выглядит мелочью, а в реальности вы можете остаться без поддержки и легального использования, особенно если вендор строгий или сервис зарубежный. Поэтому проверка лицензии по номеру договора и по данным аккаунта должна заканчиваться ответом на главный вопрос: кто имеет право использовать софт после сделки, и нужно ли согласие правообладателя на передачу.
Вторая болевая точка это самопис без документальной цепочки. Часто есть репозиторий, есть код, даже есть «всё работает», но нет актов, нет условий об отчуждении исключительных прав, нет нормального описания результатов работ. А потом на горизонте появляется бывший разработчик с обидой и юристом, и переговоры внезапно становятся громкими. Лечится это не героизмом, а спокойной ревизией договоров и корректным оформлением, иногда ещё до закрытия сделки. Времени занимает меньше, чем один судебный спор, и нервов тоже меньше, если честно.
Третья проблема это доступы и зависимости: домены, почта, облака, ключи API, кассы, телефония, аккаунты в маркетплейсах. Их редко считают «ПО», но именно они держат выручку. Люди теряют недели на восстановление, потому что «всё было в телефоне у директора», а директор уже не директор. Если хотите жить спокойно, просите не только договоры, но и понятный реестр доступов, где видно, что завязано на личные номера, и что нужно перевязать до смены собственника. Тут автоматизация через Make.com хороша хотя бы как способ собрать всё в одну систему: уведомления, сроки, статусы, документы, чтобы не играть в детектива по всем чатам.
Кому реально стоит оформлять и защищать интеллектуальную собственность заранее
Если бизнес живёт на софте, бренде, базе клиентов, методиках, дизайне, контенте, то оформление прав это не «для красоты», а для скорости сделок и спокойствия. Когда права на разработки, договоры с авторами, лицензии и документы по товарным знакам лежат в порядке, due diligence проходит быстрее и дешевле, а у покупателя меньше поводов торговаться и ставить условия. Особенно это чувствуется, когда компания растёт и меняет подрядчиков: бумажный хвост без системы превращается в снежный ком, который однажды прилетит вам в сделке.
В работе ценны форматы, где вам не читают лекцию, а помогают собрать цепочку прав, привести договоры в порядок и подготовить пакет для инвестора или покупателя. Иногда полезнее короткая проверка и список правок, чем месяцы «общих консультаций». Если вам важны новости и практика по теме, подпишитесь на наш Telegram-канал и отдельно на Телеграмм канал Патентного бюро Лирейт”, там регулярно всплывают ситуации из реальных сделок и разборы ошибок, которые лучше делать чужими руками, а не своими.
Регистрация товарного знака часто помогает не только в спорах, но и в переговорах о цене: когда бренд защищён, актив выглядит понятнее. А если нужен более широкий контур, то полезно посмотреть Юридическая защита интеллектуальной собственности и материалы про Монополия на бренд, чтобы не держать весь риск в голове у одного юриста или владельца.
FAQ
Вопрос: Что в сделке важнее: право на софт или доступы к сервисам?
Ответ: Важны оба слоя. Право на софт отвечает за законность использования и отсутствие претензий, а доступы определяют, сможете ли вы реально продолжить работу на следующий день. Идеальный вариант это когда право оформлено документами, а доступы уже переведены на корпоративные аккаунты и передаются по акту.
Вопрос: Как понять, что проверка лицензии ПО проведена нормально, а не «для галочки»?
Ответ: Когда по каждой критичной программе вы можете ответить: кто правообладатель, кто лицензиат, на какой срок и на каких условиях вы используете, можно ли передать лицензию при смене владельца, и где лежит подтверждение оплаты/активации. Проверка лицензии по номеру договора или заказа полезна только вместе с условиями лицензии и данными аккаунта.
Вопрос: Если продавец говорит «всё легально», но документов мало, что делать?
Ответ: Просить восстановить цепочку: письма от вендоров, счета, акты, доступ в личные кабинеты, договоры с разработчиками, акты сдачи работ, выгрузку репозиториев. Если документы невозможно собрать, это риск, который обычно отражают в цене, условиях сделки и перечне обязательств продавца до закрытия.
Вопрос: Можно ли «просто купить лицензию ПО» после покупки и не заморачиваться due diligence?
Ответ: Иногда да, если софт типовой и легко заменяемый, а данные можно безопасно перенести. Но если ПО вшито в процессы, интеграции и хранит историю, то «потом купим» превращается в простой бизнеса и непредсказуемые расходы. Лучше заранее понять, что именно придётся купить заново и сколько времени это займёт.
Вопрос: Что означает, если сотрудники обсуждают «софт без рут прав на андроид» или «софт на стендофф без рут прав» в корпоративных чатах?
Ответ: В контексте покупки бизнеса это повод насторожиться: такие фразы часто связаны с обходом ограничений и нелегальным использованием ПО в потребительских сценариях. Для коммерческой компании это комплаенс-риск и сигнал проверить, нет ли привычки использовать сомнительные инструменты, которые могут принести претензии и проблемы с безопасностью.
Вопрос: Правда ли, что до 30% сделок имеют скрытые юридические риски по правам на ПО?
Ответ: Да, встречается оценка, что до 30% сделок содержат скрытые юридические риски, связанные с правами на ПО, и это может приводить к финансовым потерям. Источник: biztotal.ru. На практике цифра для конкретной сделки зависит от зрелости компании и того, насколько она привыкла оформлять отношения с разработчиками и вендорами.
Вопрос: Чем может помочь Make.com при due diligence прав на ПО?
Ответ: Он помогает навести порядок в документах и сроках: автоматически собирать счета и договоры из почты и облаков, раскладывать по поставщикам, ставить напоминания о продлениях, отправлять уведомления в Telegram. Это не заменяет юриста и технический аудит, но хорошо убирает хаос, из-за которого вобще-то и теряются недели.