Как защитить исходный код: что нужно сделать разработчику до выхода продукта на рынок

Содержание

Законодательство РФ для защиты прав на исходный код

Фиксация прав на программный код и почему это важно делать до вывода продукта на рынок

Как защищать исходный код разработчику

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

Показательный пример есть в российской судебной практике. Дело № А56-21040/2015, где компания «Дата Матрикс» обнаружила, что принадлежащий ей программный код используется в другом продукте, и потребовала запретить его использование. Компьютерно-техническая экспертиза установила, что программа ответчика была создана на основе исходного текста программы истца: в ней использовалось не менее 88% чужого кода, а вероятность случайного совпадения эксперты оценили как крайне низкую. Суд признал нарушение исключительного права, а Суд по интеллектуальным правам оставил решение в силе. Дело дошло до Верховного суда, который не нашел оснований для пересмотра результата.

Такие споры показывают, почему о защите исходного кода лучше задуматься еще в процессе разработки. Чем раньше зафиксированы конкретная версия кода, дата ее существования и правообладатель, тем проще выстроить доказательственную базу при конфликте с бывшим сотрудником, подрядчиком или другой компанией.

Законодательство РФ для защиты прав на исходный код

Российское законодательство охраняет исходный код авторским правом. Согласно статье 1261 Гражданского Кодекса Российской Федерации (далее, ГК РФ), программы для электронно-вычислительный машин (далее ЭВМ) охраняются так же, как литературные произведения. Под защиту подпадают программы, выраженные в любой форме и на любом языке, включая исходный текст и объектный код, а также подготовительные материалы, созданные в процессе разработки. 

При этом авторское право не единственный способ защиты ИТ-разработок. Если программное решение имеет технический характер, отдельные его элементы могут охраняться патентным правом. Например, техническое решение, реализуемое с помощью программного обеспечения, при соблюдении условий патентоспособности может получить охрану как изобретение. Если разработка связана с устройством, в отдельных случаях возможна охрана в качестве полезной модели. Саму программу для ЭВМ как таковую запатентовать в качестве изобретения или полезной модели нельзя.

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

Но автоматическое возникновение права не означает автоматического разрешения будущего спора в пользу правообладателя. Если два человека или две компании заявят права на один и тот же код, суду потребуется установить, кому принадлежит исключительное право, какая программа появилась раньше и использовался ли ее код при создании другого продукта.

Причем одинаковые функции программ сами по себе еще не доказывают копирование. Суд по интеллектуальным правам указывает, что при подобных спорах исследуется именно исходный код. В судебной практике доказательством заимствования становились значительные совпадения программного текста и даже одинаковые ошибки, перенесенные из одной программы в другую: дело № А56-21040/2015 и № А40-161684/2018. В них истец утверждал, что программа ответчика является переработкой его продукта. Но проведенная судебная экспертиза не выявила заимствований в исходном коде, стилистике, комментариях или подходах к программированию. Суд подчеркнул, что сходство целей и функций программ не доказывает их тождественности. Поскольку истец не представил доказательств нарушения прав, а выводы судов должны быть основаны только на материалах дела, кассационная жалоба была отклонена.

Отдельное внимание требуется, если над продуктом работает команда. По статье 1295 ГК РФ исключительное право на служебное произведение по общему правилу принадлежит работодателю, если иное не предусмотрено договором. Но недостаточно просто иметь трудовой договор с программистом. В случае спора важно подтвердить, что создание конкретного кода действительно входило в его трудовые обязанности. Поэтому компаниям необходимо оформлять технические задания, должностные обязанности, передачу результатов работы и другие документы, позволяющие восстановить историю создания продукта. При этом если работодатель в течение трех лет не начнет использование служебного произведения, не передаст исключительное право другому лицу или не сохранит его в тайне, исключительное право возвращается автору.

Фиксация прав на программный код и почему это важно делать до вывода продукта на рынок

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

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

История изменений в Git может быть частью такой доказательственной базы, но полагаться только на нее рискованно. Git создавался прежде всего как система управления версиями. Он позволяет сохранять изменения, видеть историю разработки и организовывать совместную работу, но сам по себе не устанавливает авторское право и не разрешает юридический спор о том, кому принадлежит программа.

Это особенно хорошо видно на практике. В одном из российских споров по делу № А45-26234/2022 подрядчик разместил исходный код разработанного мобильного приложения Boom Boom в GitHub, хотя договор не предусматривал такого способа хранения. После приемки работ исключительное право на приложение принадлежало заказчику. Суды признали размещение кода на стороннем сервисе незаконным использованием программы и взыскали в пользу правообладателя более 2,6 млн рублей компенсации.

Еще до первого публичного релиза полезно зафиксировать права на стабильную версию исходного кода. Если разработка продолжается и код существенно меняется, фиксировать рекомендуется и последующие версии. Так формируется хронология развития продукта: при споре можно показать не только файл с актуальной версией, но и то, каким был объект на конкретный момент времени.

Особенно это важно для стартапов и компаний, которые привлекают внешних разработчиков. Еще до начала работ стоит определить в договоре, кому принадлежат исключительные права на результат, какие материалы подрядчик обязан передать, где разрешено хранить код и может ли он использовать созданные решения в других проектах.

Как защищать исходный код разработчику

На практике защита кода работает лучше всего не как одно действие, а как несколько взаимодополняющих мер.

Во-первых, необходимо ограничить технический доступ к репозиториям. Доступ следует предоставлять только тем сотрудникам и подрядчикам, которым он действительно нужен, а после завершения сотрудничества своевременно отзывать. Для значимых проектов имеет смысл вести журнал действий и контролировать выгрузку данных.

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

В-третьих, до релиза стоит отдельно зафиксировать права на сам результат разработки. Для этого можно использовать депонирование в n’RIS.

Депонирование

Депонирование позволяет зафиксировать существование конкретного файла на определенный момент времени. В n’RIS цифровой экземпляр помещается в зашифрованную защищенную ячейку, фиксируются содержимое, дата и время загрузки. После процедуры пользователь получает свидетельство о депонировании с цифровой подписью КриптоПро и штампом даты и времени.

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

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

SAVECODE

Если депонирование подходит для разовой фиксации программы или ее значимой версии, SAVECODE рассчитан именно на работу с программным кодом и регулярными изменениями продукта.

Через сервис можно фиксировать код мобильных и веб-приложений, серверных сервисов, библиотек, SDK, прошивок и других программных компонентов, а также связанную документацию и отдельные элементы продукта. Информация о фиксации записывается в блокчейн инфраструктуру РЦИС.РФ. Файлы хранятся в зашифрованной форме, а для особо конфиденциальных объектов можно фиксировать хеш файла без передачи самого исходника.

Это особенно удобно для продукта, который постоянно развивается. Вместо попытки один раз зафиксировать «готовую программу» команда может сохранять юридически значимую хронологию ее ключевых версий. Для корпоративных сценариев SAVECODE предусматривает в том числе депонирование через API из GitLab, GitHub и других Git систем.

Защита исходного кода начинается еще до выхода продукта на рынок. Пока разработка находится внутри команды, важно определить принадлежность прав, ограничить доступ к материалам и зафиксировать ключевые версии программы. Депонирование n’RIS и SAVECODE помогают заранее сформировать доказательственную базу, чтобы при возникновении спора подтвердить, какой код и на какую дату уже существовал у автора или правообладателя.