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

Мы уже отошли от хрупких CD-дисков, на которых можно было зафиксировать код. Сейчас разработка живёт в Git, при этом «передача результата» часто превращается в абстракцию. Мы почему-то не пришли к простым и ясным решениям, которые дают современные технологии.

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

Проблема: что мы передаем и что получаем?

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

И что у вас есть? Акт. В котором написано: «Результат работ передан». И всё.

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

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

Решение: три простых шага

Шаг 1. Создаем дамп репозитория

Вместо того чтобы копировать папку с файлами или, что еще хуже, просто «предоставить доступ» к репозиторию, нужно создать самодостаточный архив — bundle.

Git bundle — это файл, который содержит все необходимое для полного восстановления репозитория: объекты, ссылки на ветки, теги, всю историю изменений.

Как это сделать:

# Полный бэкап всего репозитория (все ветки, все теги)
git bundle create project.bundle --all

Эта команда создаст файл project.bundle, который содержит всё содержимое репозитория на текущий момент.

Преимущества bundle перед простой копией папки .git:

  • Это один файл, который легко передать, подписать, зафиксировать

  • Его можно клонировать как обычный репозиторий: git clone project.bundle restored-project

Шаг 2. Получаем контрольную сумму файла дампа

Bundle — это файл. Любой файл можно хешировать. Контрольная сумма (хеш) — это уникальный «отпечаток пальца» файла. Если в файле изменится хотя бы один байт, хеш станет совершенно другим.

Это ключевой момент: хеш позволяет жестко привязать акт к конкретной версии кода.

shasum -a 256 project.bundle

или

certutil -hashfile project.bundle SHA256

Вы получите строку вида: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

Почему именно SHA-256? MD5 и SHA-1 сегодня считаются устаревшими — для них возможны коллизии (разные файлы с одинаковым хешем). SHA-256 — современный стандарт, устойчивый к взлому .

Шаг 3. Фиксируем в документе

Теперь у вас есть:

  1. Файл project.bundle — код, который вы передаете

  2. Хеш этого файла — например, a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

Эту контрольную сумму нужно включить в текст акта или договора. Например:

«Результат работ передан в виде файла project.bundle, контрольная сумма (SHA-256) которого составляет: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e»

И затем подписать документ с электронной подписью.

Подписание может быть разным в зависимости от ваших возможностей. От использования системы ЭДО (электронный документооборот) для юридических лиц до подписания файла физическими лицами через Госуслуги с помощью сервиса Госключ. Главное, чтобы подпись была выдана через удостоверяющий центр (при самодельной подписи документ может быть не признан подписанным при споре). Хорошо, если она будет содержать штамп времени. Также удобно, если при подписании можно будет получить pdf файл со штампом визуализации электронной подписи.

Важно: подпись фиксирует не только сам факт передачи, но и содержимое документа, включая контрольную сумму.

Что это дает в случае спора?

1. Договор признан подписанным

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

2. Контрольная сумма доказывает неизменность кода

Суду или эксперту предоставляется файл project.bundle. Эксперт считает его хэш. * Если хэш совпадает с тем, что в Акте — файл тот самый. Его не меняли после подписания. * Если хэш не совпадает — файл был подменен, и доказательства не принимаются.

3. Дамп позволяет восстановить все

** Файл .bundle — это полноценный Git-репозиторий. Его можно развернуть командой:

# Восстановление репозитория из bundle
git clone project.bundle restored-project

После этого вы можете:

  • Посмотреть все коммиты, авторов, даты

  • Проверить наличие конкретных файлов или функций

  • Показать, что код был передан именно в таком виде

4. Исключается подмена «в процессе»

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

Bundle + хеш исключают этот риск. Файл фиксируется в момент передачи. Все, что было после, — уже не ваша ответственность.

Заключение

Три простых действия занимают буквально пару минут:

# 1. Создаем дамп
git bundle create project.bundle --all

# 2. Получаем хеш
sha256sum project.bundle

# 3. Вставляем хеш в акт и подписываем

При наличии ИИ-агентов такой процесс может стать рутиной и в процессе своей разработки. То есть выполняться регулярно и автоматически.

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