Одно слово — две несовместимые процедуры
«Депонировать код» говорят про два разных сценария, и путаница начинается с этого. В одном копия сдаётся на хранение, чтобы потом доказать: на такую-то дату этот код существовал и находился у вас. В другом копия сдаётся, чтобы заказчик мог её забрать, когда разработчик перестал отвечать. Первое — про право, второе — про непрерывность работы.
Состав пакета, договор с хранителем и условия выдачи у них разные. Подмена одного другим обнаруживается ровно в тот момент, когда бумага понадобилась: свидетельство о депонировании не открывает доступ к коду, а договор эскроу сам по себе не доказывает, что автор — вы.
Путь первый: зафиксировать авторство
Правовая рамка здесь простая: программа для ЭВМ охраняется как литературное произведение — так устроена часть четвёртая Гражданского кодекса, действующая с 2008 года. Исключительное право на программу возникает в момент её создания — регистрировать его, чтобы оно появилось, не нужно. Проблема не в праве, а в доказывании: в споре придётся показать, что код был у вас раньше, чем у оппонента. Депонирование создаёт эту точку во времени. Хранитель принимает копию, фиксирует дату приёма и выдаёт свидетельство, которое дальше живёт как доказательство.
Рядом стоит государственная регистрация программы для ЭВМ в Роспатенте: это уже не частное хранение, а запись в государственном реестре. Требования к документам строже, срок дольше, зато и вес в споре другой. Процедуры не исключают друг друга — регистрация фиксирует факт в реестре, депонирование удобно для промежуточных версий между регистрациями.
Путь первый обычно нужен, когда:
- •Код — основной актив компании, а не вспомогательный инструмент,
- •Есть риск спора с бывшим сотрудником, соучредителем или подрядчиком,
- •Готовится сделка, и покупатель будет проверять происхождение кода,
- •Принадлежность прав придётся подтверждать документами — например, при заявке в реестр отечественного ПО.
Путь второй: обеспечить доступ (эскроу)
Здесь заказчик боится не потери прав, а остановки системы. Код разработчика лежит у независимого хранителя, а в договоре перечислены события, при которых копия выдаётся заказчику: разработчик прекратил поддержку, ликвидирован, не устранил критичную неисправность в согласованный срок. Пока события не наступили, заказчик кода не видит — и это устраивает обе стороны, потому что разработчик не отдаёт актив просто так.
Ценность такого хранения определяется не фактом сдачи архива, а его содержимым. Депонированный код без сборочных скриптов, описания окружения и зависимостей — это набор файлов, из которого работающую систему никто не соберёт. Проверять комплектность нужно при закладке, а не в день, когда система встала.
Сравнение по существу
| Вопрос | Фиксация авторства | Эскроу для доступа |
|---|---|---|
| Кто инициатор | правообладатель кода | заказчик системы |
| Чего боятся | что права оспорят | что подрядчик исчезнет |
| Что на выходе | свидетельство с датой приёма | договор хранения и перечень событий выдачи |
| Когда пригодится | в суде и при проверке перед сделкой | когда система встала, а разработчика нет |
| Кто видит код | только хранитель | хранитель; заказчик — при наступлении события |
| Что обязательно в пакете | исходники версии и описание | исходники, сборка, окружение, инструкция |
| Когда обновлять | при существенных изменениях | при каждом релизе, иначе копия мертва |
Как выбрать путь
- •Код пишете вы или ваши сотрудники, и он ваш актив — путь первый, фиксация авторства.
- •Систему пишет подрядчик, а её остановка бьёт по производству или продажам — путь второй, эскроу.
- •Продукт продаёте или лицензируете, и покупатели проверяют чистоту прав — путь первый, заранее, а не в момент сделки.
- •Заказная разработка вашего продукта, который вы потом продаёте, — оба пути: сверить по договору, что права ваши, и держать копию у хранителя.
- •Прошивка и схемотехника у стороннего разработчика — путь второй, но с обязательным перечнем: исходники прошивки, проектные файлы платы, среда сборки.
Чего депонирование не закрывает
Обе процедуры работают после события. Они не мешают разработчику выгрузить репозиторий перед увольнением и не возвращают ушедшую копию — они дают основание для претензий. Само копирование останавливают другие меры: разграничение доступа, журналирование выгрузок и детект аномальной активности. Как это устроено для небольшой компании без своего отдела безопасности — DLP для среднего бизнеса. Если код пишут удалённые разработчики и подрядчики, к этому добавляется контроль самих доступов к репозиторию — контроль удалённых сотрудников.
Отдельный сценарий — расследование, когда копия уже ушла. Здесь помогает не свидетельство хранителя, а сохранённые следы: кто и когда обращался к репозиторию, что выгружал, куда. Разбор такого случая — как отследить, кто слил базу.
Что собрать до похода к хранителю
- •Исходный код нужной версии с указанием, из какой ветки и какого коммита она собрана,
- •Сборочные скрипты и описание окружения: версии инструментов, зависимости, порядок сборки,
- •Для аппаратных проектов — проектные файлы платы, файлы прошивки и описание процедуры прошивания,
- •Инструкцию по развёртыванию и перечень внешних сервисов, без которых система не поднимется,
- •Перечень сторонних библиотек и их лицензий: чужой код в пакете нужно уметь объяснить,
- •Регламент обновления копии — кто, когда и по какому поводу закладывает новую версию.
Как мы передаём код и права
Мы исходим из того, что исходный код и права на него принадлежат заказчику, а закреплены они договором, а не подразумеваются: что именно передаётся при сдаче работы, перечислено на странице что мы делаем и что остаётся у вас. Депонирование и эскроу отдельной услугой мы не оформляем — договор с хранителем заказчик заключает сам. Перечень выше собран из того же, что мы отдаём при сдаче работы: исходники, среда сборки, описание развёртывания. Если этот комплект у вас на руках, закладка копии к хранителю становится формальностью, а не отдельным проектом.
Частые вопросы
Депонирование даёт исключительное право на код?
Нет. Исключительное право возникает в момент создания программы и не зависит от регистрации. Депонирование не создаёт право, а фиксирует дату: на такой-то день эта версия кода была передана на хранение именно вами. В споре это доказательство, а не сам титул.
Чем депонирование отличается от государственной регистрации программы для ЭВМ?
Депонирование — частное хранение копии с выдачей свидетельства хранителя. Государственная регистрация — запись в реестре Роспатента со своим свидетельством. Требования к комплекту документов у регистрации строже, зато и вес у неё выше. Процедуры не исключают друг друга.
Код писал подрядчик — что депонировать?
Сначала прочитать договор. Если его предметом было создание программы, исключительное право по умолчанию у заказчика — закон отдаёт его вам, пока в договоре не написано иное, и отдельный договор об отчуждении не требуется. Если же код возник попутно при подряде или НИОКР, где его создание прямо не предусматривалось, право по умолчанию остаётся у подрядчика; то же и с авторским заказом у физического лица — там переход права прописывают отдельно. Депонировать имеет смысл ту версию, права на которую по договору ваши, и закладывать её вместе со сборкой и окружением.
Как часто обновлять депонированную копию?
Привязать обновление к релизам, а не к календарю. Для эскроу это критично: копия годовой давности не собирается и не разворачивается, а значит страховка не сработает в тот единственный момент, когда понадобится.
Депонирование защитит от утечки кода?
Нет, оно работает после события. Уходящему разработчику депонирование не мешает скопировать репозиторий — этим занимаются контроль доступа и детект аномальных выгрузок. Депонирование даёт основание для претензий, когда копия уже ушла.