27 октября 2026 в 01:26
Авторские права на код в GitHub: что сохранить к релизу
Чтобы позднее найти версию кода из релиза или отправки заказчику, сохраните ID коммита, архив исходников и сведения о составе проекта. История GitHub поможет показать, как менялась программа, а архив позволит вернуться к выбранному состоянию. Подготовьте их до передачи, пока все материалы под рукой.
Содержание статьи
Что охраняется авторским правом на исходный код
По статье 1261 ГК РФ авторские права на программы для ЭВМ, включая исходный текст и объектный код, охраняются так же, как права на литературные произведения. Размещение проекта на GitHub помогает организовать разработку и сохранить её историю.
При этом в одном репозитории могут находиться собственные модули, работа коллег и сторонние библиотеки. Перед публикацией или передачей отметьте, какие части написали вы, а какие используются на других основаниях. Если проект заказной или служебный, соберите договор и документы по его созданию: имя владельца репозитория не объясняет все условия распоряжения кодом.
Что дают коммиты и подпись Verified в GitHub
Изменения файлов, обсуждения pull request и задачи помогают восстановить ход работы: что добавляли, кто участвовал и как согласовывали результат. Для выбранного релиза запишите полный ID коммита и оставьте относящиеся к нему обсуждения.
Если вы подписываете коммиты, сохраните и сведения о проверке подписи. В документации GitHub статус Verified означает успешную проверку подписи в предусмотренных сервисом условиях. GitHub поддерживает подписи GPG, SSH и S/MIME. Этот статус относится к происхождению изменения и проверке подписи; он не является правовым заключением о принадлежности всех частей программы.
Сохраните историю вместе с материалами проекта и документом о выбранном файле. Если понадобится обсудить вклад участников, последовательность изменений поможет объяснить его подробнее, чем один снимок экрана с названием репозитория.
Привяжите релиз к конкретному коммиту
Ветка main меняется по ходу работы. Если при передаче оставить только ссылку на неё, позже придётся выяснять, какой именно код получил заказчик. Запишите коммит той версии, которую отправляете.
Для выпуска запишите ID коммита, тег и название версии. В GitHub релизы основаны на тегах; дата создания тега и дата релиза могут различаться. К релизу можно добавить описание изменений и файлы для скачивания. Это помогает связать исходники с тем выпуском, который получил заказчик или пользователь. Подробнее – в справке GitHub о релизах.
| Что сохранить | Для чего |
|---|---|
| Адрес репозитория и полный ID коммита | Указать конкретное состояние кода, даже если рабочая ветка позже изменилась. |
| Тег, название версии и описание релиза | Понять, какой выпуск подготовлен и что в него входит. |
| Архив исходников и описание его состава | Сохранить файл, который можно открыть и сверить позднее. |
| Лицензии и список сторонних компонентов | Отличить свои материалы от кода, используемого на условиях других правообладателей. |
| Согласование передачи, договор и акт при наличии | Связать выбранную версию с договорённостями о результате и правах. |
Например, в заметке укажите версию v1.2.0, полный ID её коммита, дату передачи и имя файла project-v1.2.0-source.zip. Версия и название файла здесь условные.
Почему ZIP исходников не заменяет историю репозитория
GitHub позволяет скачать снимок ветки, тега или коммита. Такой ZIP содержит файлы выбранного состояния, но не всю историю разработки. Если она нужна, сохраните её отдельной копией репозитория. Это различие описано в инструкции по архивам исходного кода.
У ветки и тега может измениться привязка к коммиту. Для точного указания состояния используйте ID коммита. Сам скачанный архив тоже сохраните: настройки сжатия при повторной загрузке могут измениться, даже если содержимое исходных файлов осталось тем же.
Распакуйте архив и проверьте, попали ли в него исходники ваших модулей, нужная документация и сведения о зависимостях. Одного подходящего названия ZIP недостаточно. Для дополнительных материалов укажите, где они хранятся и входят ли в передачу.
Публичный репозиторий и лицензия: разные вопросы
GitHub поясняет, что публичный репозиторий можно просматривать и форкать по условиям платформы. При этом сама публичность не означает разрешения использовать код любым способом. Условия использования определяет в том числе лицензия. Отсутствие LICENSE не делает проект свободным от авторских прав. Подробности – в справке GitHub о лицензировании.
Выбирайте лицензию под свою задачу. Если вы хотите сохранить закрытую модель продукта, не добавляйте открытое разрешение только потому, что так оформлен чужой репозиторий. Для совместного проекта проверьте, вправе ли вы выдавать выбранные разрешения, и сохраните условия сторонних компонентов. Обсудить спорные пункты можно со специалистом до публикации.
Не открывайте закрытый репозиторий только ради подтверждения версии. Сначала определите, кому и какие материалы нужно передать. Для подготовки архива нет необходимости публиковать рабочие доступы и клиентские данные.
Как зафиксировать выбранную версию кода в PravoFile
При депонировании исходного кода в PravoFile вы фиксируете файл выбранной версии. Подготовьте архив, проверьте поддерживаемый формат, размер и условия тарифа, затем зарегистрируйтесь в PravoFile и загрузите файл. Сервис фиксирует дату регистрации, рассчитывает SHA-256 и выдаёт PDF-сертификат с QR-проверкой.
Положите сертификат рядом с тем архивом, который загрузили. В описании работы укажите версию и ID коммита, чтобы было понятно, к какому выпуску относится файл. Сведения о дате регистрации и проверке разобраны в статье о сертификате, хеше и QR-коде.
ID коммита и SHA-256 архива относятся к разным объектам. Не подменяйте один другим при сверке. Если позже пересобрать ZIP с теми же исходниками, побайтовое содержимое архива может отличаться и его хеш изменится. Для проверки сертификата нужен сохранённый загруженный файл.
Дата сертификата относится к регистрации файла в PravoFile. Историю написания кода сохраняйте в репозитории и документах проекта.
Нужно ли отдельно регистрировать программу в Роспатенте
Государственная регистрация программы для ЭВМ – отдельная процедура. Статья 1262 ГК РФ предусматривает её по желанию правообладателя. Публикация GitHub-релиза и сертификат PravoFile не являются свидетельством такой регистрации.
Если вам нужен именно государственный реестр, готовьте отдельную заявку с учётом своей ситуации. Для повседневной работы с версиями продолжайте сохранять исходники, историю изменений и сведения о передаче независимо от выбранной процедуры.
Проверка перед релизом или передачей заказчику
- Выбран конкретный коммит; его полный ID и название версии записаны.
- Архив открывается, его состав проверен, история разработки сохранена отдельно.
- Собственные модули и сторонние компоненты различимы; условия лицензий не потерялись.
- Из договора и согласования понятно, что именно передаётся и на каких условиях.
- Если файл депонирован, сохранены загруженный архив и относящийся к нему сертификат.
Начните с ближайшего выпуска: соберите его материалы и создайте аккаунт PravoFile, чтобы зафиксировать выбранный файл. На тарифе «Старт» первый месяц бесплатно, затем 490 ₽/месяц; включены три файла и 300 МБ. Актуальные условия доступны в разделе тарифов.
Первый месяц бесплатно
Зафиксируйте свою работу до публикации
Загрузите файл в PravoFile и получите сертификат с датой фиксации, хешем и QR-кодом для проверки.
Условия тарифа