Депонирование исходного кода: как защитить покупателя ПО
Продвинутое3 минРедакция Innovialabs
Коротко
Escrow исходного кода — это договор, по которому код хранится у независимого агента и передаётся покупателю, если разработчик перестаёт выполнять обязательства. Он полезен для критичного ПО, но только при регулярной проверке депозита.
Что такое escrow исходного кода
Source code escrow — трёхсторонний договор между разработчиком (лицензиаром), покупателем (лицензиатом) и независимым escrow-агентом. Разработчик передаёт агенту исходный код, документацию и инструкции по сборке. Покупатель не видит код, пока не наступит заранее оговорённое событие — условие выдачи (release trigger). Тогда агент передаёт депозит покупателю, и тот может сам поддерживать систему.
Escrow решает конкретную проблему: вы купили лицензию на ПО, от которого зависит бизнес, но код принадлежит поставщику. Если поставщик исчезнет, без кода вы не сможете исправить ошибку или перенести систему.
Как устроен договор
Типичная схема:
- Стороны подписывают договор с агентом и описывают состав депозита.
- Разработчик загружает первый депозит и обновляет его по графику — например, после каждого релиза.
- Агент хранит материалы и при необходимости проверяет их.
- При наступлении условия покупатель подаёт заявку, разработчик может её оспорить в установленный срок.
- Если спора нет или он решён в пользу покупателя, агент выдаёт депозит.
Важно, что выданный код обычно можно использовать только для поддержки и сопровождения купленной системы, а не для перепродажи. Это фиксируется в договоре.
Типичные условия выдачи
- Банкротство или ликвидация разработчика.
- Прекращение поддержки продукта или отказ от обязательств по SLA.
- Существенное нарушение договора о поддержке, не устранённое в оговорённый срок.
- Смена владельца, после которой продукт перестаёт развиваться.
Формулировки должны быть проверяемыми. «Поставщик плохо работает» — спорное условие. «Критичная ошибка не исправлена в течение N дней после уведомления» — понятное.
Проверка депозита — главная часть
Самая частая проблема escrow — депозит, который нельзя использовать: устаревший код, нет зависимостей, нет инструкции по сборке. Поэтому договор должен предусматривать верификацию:
| Уровень проверки | Что проверяется |
|---|---|
| Базовая | Файлы читаются, не повреждены, есть опись |
| Полнота | Есть весь код, скрипты сборки, схемы БД, документация |
| Сборка | Агент или эксперт собирает проект по инструкции |
| Функциональная | Собранная система запускается и работает как в продакшене |
Чем глубже проверка, тем она дороже, но только сборка и запуск реально доказывают, что депозит пригоден.
Что включить в депозит
- исходный код всех компонентов, включая внутренние библиотеки;
- скрипты сборки и деплоя, конфигурации CI/CD;
- список сторонних зависимостей и их версий;
- схемы баз данных и миграции;
- инструкцию по развёртыванию с нуля;
- ключевую архитектурную документацию.
Секреты и пароли продакшена в депозит не кладут — вместо этого описывают, как их сгенерировать заново.
Когда escrow оправдан, а когда нет
Оправдан, если:
- система критична для операций и её простой дорого обходится;
- поставщик небольшой или молодой;
- замена системы займёт много времени;
- вы не владеете кодом по договору.
Не нужен, если:
- код по договору и так передаётся вам (например, при заказной разработке с переходом прав);
- продукт легко заменить аналогом;
- это SaaS, где сам по себе код без инфраструктуры и данных мало что даёт — здесь важнее договорённости о выгрузке данных и плане продолжения работы.
Частые ошибки
- Подписать договор и ни разу не обновить депозит.
- Не проводить проверку сборки.
- Размытые условия выдачи, которые легко оспорить.
- Не учесть, что команде понадобятся люди, способные поддерживать этот код.