Мне попался интересный кейс, дошедший до верховного суда

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

🚨 Сделка на 500 млн рублей провалилась за 3 дня до подписания.

Причина? Не кризис и не конкуренция. А три простые ошибки с кодом и документами.

🔍 Что случилось на самом деле (реальный кейс из практики 2025 г.)

Стартап «******» разрабатывал ИИ для анализа медицинских снимков. Выглядел идеально:

- 15 клиентов из топ-клиник

- Рост выручки на 300% за год

- Код в закрытом GitHub, команда из 8 разработчиков

Инвесторы готовы были вложить 500 млн ₽. На финальной проверке (due diligence) юристы и технари нашли:

❌ Ошибка 1. «Чужой» код внутри продукта.

Разработчик 2 года назад скопировал кусок алгоритма из открытой библиотеки с лицензией GPL. Эта лицензия «заражает» весь проект: если используешь такой код — всё ПО должно стать открытым. Для коммерческого продукта это катастрофа. Инвесторы не смогли продать технологию без риска судебных исков.

❌ Ошибка 2. Код принадлежит не компании.

Главный модуль написал сотрудник, который уволился через 6 месяцев после старта. В трудовом договоре не было пункта о том, что всё, созданное на работе, принадлежит компании. По закону (ст. 1295 ГК РФ) такие работы считаются «служебными» — но только если это прямо прописано в договоре. Суд встал на сторону бывшего сотрудника. Компания осталась без ключевого алгоритма.

❌ Ошибка 3. Нет доказательств «чистоты» кода.

Когда инвесторы попросили показать историю изменений в коде (кто, когда и что писал), оказалось:

— 30% коммитов сделаны с личных аккаунтов на GitHub

— Нет подтверждения, что разработчики не использовали код с прошлых работ

— В логах — доступ к репозиторию из стран, где запрещена передача ИИ-технологий

Итог: сделка сорвана. Стартап потерял доверие инвесторов. Через полгода — банкротство.

⚠️ Почему это происходит чаще, чем кажется?

Сегодня 7 из 10 проваленных tech-сделок падают не из-за бизнес-модели, а из-за «грязного» кода и документов.

💡 Как не повторить чужие ошибки?

✅ Перед сделкой — «цифровой детектив»

Не просто посмотреть на код, а проверить:

— Кто реально писал каждую строчку (история коммитов в Git)

— Нет ли скрытых лицензий в зависимостях (инструменты: Snyk, FOSSA, Black Duck)

— Все ли разработчики подписали договоры с передачей прав

✅ Договоры — не формальность

В трудовых и ГПХ-договорах обязательно прописывайте:

«Все программы, алгоритмы, базы данных, созданные в период работы, принадлежат компании на праве собственности»

✅ Храните доказательства

— Скриншоты репозиториев с привязкой ко времени

— Подписанные акты сдачи-приёмки кода

— Отчёты сканеров лицензий (сохраняйте даже старые версии)

✅ Если код критичен — депонируйте его

Через нотариуса или специальные сервисы (например, кодовый эскроу). Это доказательство «чистоты» на момент сделки.

🎯 Главное

Код без документов = не актив, а бомба замедленного действия.

Инвесторы сегодня покупают не «как работает продукт», а «кто имеет право им распоряжаться».

Проверка прав на ПО — не бюрократия. Это страховка от обнуления бизнеса. Юрист и инженер должны работать в тесном контакте и содружестве. Тогда все будет хорошо.