Top.Mail.Ru
Колонки

Как понять, что ваш код украли, и можно ли этого избежать

Колонки
Евгений Царев
Евгений Царев

Управляющий RTM Group

Илья Голубев

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

Как понять, что ваш код украли, и можно ли этого избежать

По нашим оценкам, более 50% всех разработчиков программного обеспечения (ПО) не оформляют права на свою интеллектуальную собственность. Поэтому судебные разбирательства в этой сфере происходят все чаще: в 2020 году российские суды вынесли почти на 33% больше решений по спорам, связанных с ПО, чем в предыдущем 2019. Программисты судятся с бывшими работодателями, компании-разработчики спорят друг с другом из-за «заимствований».

Программный код — как песня

Что такое ПО с юридической точки зрения? Любой программный код — охраняемый объект авторского права, как музыкальные произведения или тексты. Юридический статус компьютерных программ закреплен Всемирной организацией интеллектуальной собственности (ВОИС) и Соглашением по торговым аспектам прав интеллектуальной собственности (ТРИПС).

Права на ПО появляются с момента его создания, и по желанию автора в России их можно зарегистрировать в Федеральной службе интеллектуальной собственности (Роспатент) — ст. 1262 Гражданского кодекса РФ. Это самый простой способ защитить свой код.

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

Как похищают код?

В этом году к нам обратились представители компании Mindbox — разработчика решений для автоматизации маркетинга. Компании понадобилась компьютерная экспертиза программного кода. Заказчик обнаружил, что другая компания заимствовала код калькулятора с сайта, принадлежащего Mindbox.

Как это обычно происходит? Код могут «увести» сотрудники, но есть и другой распространенный канал, можно сказать, «прямой плагиат». Сторонняя компания увидела, как ловко у вас на сайте работает какой-то инструмент, и недолго думая решила заимствовать ваш код. Это несложно сделать, учитывая, что значительная часть калькуляторов и других подобных модулей пишется на JavaScript и висит в открытом доступе.

Хочешь быстро стартовать в IT? Выбирай направление для обучения в каталоге курсов программирования.

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

В случае с Mindbox, например, мы провели экспертизу и получили практически полное совпадение между двумя фрагментами кода. Совпадения в коде составили 98,2% — с таким заключением можно смело идти в суд.

Как защитить ваш код? 

Процесс создания программного кода (для бизнес-задач или продажи) должен быть прозрачен, а все его стадии следует задокументировать.

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

Эти обязанности должны быть внесены в бизнес-процессы, разбиты на необходимые стадии. Результаты каждого блока тоже надо детально описать. Делать все это можно как в системах для постановки задач (в той же Trello) или любым другим удобным способом.

Также очень важно провести ревизию документов: какие уже есть, каких не хватает. Когда продукт будет готов, лучше всего сразу иметь под рукой полный комплект «бумажек».

Бумажный «конструктор» — на что обратить внимание 

Кто может быть автором? Помимо штатных сотрудников, это могут быть компании-подрядчики и фрилансеры. Как мы упомянули, для каждого нужно детально описать его деятельность и внести всю эту информацию в должностную инструкцию. На практике «присвоить» каждому сотруднику отдельный модуль не так просто. Ведь есть автор идеи, есть разработчик архитектуры, создатели кода и не только. Кому принадлежит итоговый программный продукт? С точки зрения права, автором будет только разработчик, непосредственно написавший код.

Детализация нужна на случай возникновения судебных споров: если что-то не входит в трудовые обязанности, то их результат — не служебное произведение, и все права на него принадлежат работнику. Если программист «унес» с собой какой-то элемент, создание которого не входило в его обязанности (тот же калькулятор), и вы заявите о плагиате, суд будет на стороне сотрудника.

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

  • Положение о служебных произведениях;
  • Служебное задание;
  • Акт.

Это не просто «скучные бумажки для юристов», их отсутствие или некорректное составление могут обернуться возникновением споров в дальнейшем, финансовыми и репутационными убытками. Как их составлять? Нет единой формы, все зависит от бизнес-процессов компании. Но помочь здесь может штатный или внешний юрист.

Первый из упомянутых документов (Положение) регулирует процесс создания служебных произведений, описывает постановку служебных заданий, условия и порядок подписания актов, описание объектов интеллектуальной собственности.

Служебное задание определяет конкретный объект: например, какой код должен написать разработчик. Без этого документа в спорной ситуации будет невозможно определить, какое ПО компания обязала сотрудника написать, и доказать, что были переданы исключительные права именно на этот код, а не на какой-то другой. Чтобы не сойти с ума и не утонуть в документах, удобно использовать Trello или другие подобные сервисы. Главное — иметь возможность построить прямую связь между поставленной задачей и результатом работы.

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

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

Важно знать, что права от разработчика как перешли к компании, так и могут вернуться обратно, если ПО не начали использовать в течение трех лет. Можно не только применять программу по прямому назначению (запустить интернет-магазин на основе написанного продукта, например), но также переделать ее, продать, сообщить автору, что произведение должно сохраняться в тайне, и так далее. Главное — оформить все документально.

Осторожно — фрилансеры 

По документам работа с фрилансерами и внешними компаниями мало чем отличается, но есть нюанс с передачей прав. Здесь потребуются:

  • Договор (подряда, авторского заказа, услуг) с описанием процедуры передачи прав,
  • Техническое задание (с детальным описанием будущего объекта),
  • Акт.

Факт оплаты должен быть документально подтвержден.

Важно прописывать техническое задание детально. Мы как-то столкнулись с такой ситуацией: внешний подрядчик разработал мобильное приложение по контракту более чем на 10 млн рублей. При этом в договоре объект был определен как «Мобильное приложение». Примерно через месяц после закрытия договора и оплаты в репозитории Google Play появилась фактически копия этого приложения (отличалась только цветовая гамма) от одного из внешних разработчиков. И он утверждал, что права на свою разработку никому не передавал. И по закону был прав.

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

Фото на обложке: Unsplash

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Программирование 2.0: как ИИ-ассистенты упрощают разработку
  2. 2 Как геймдев-стартапам сократить расходы и сроки за счет опенсорса
  3. 3 7 советов, которые помогут вендору грамотно организовать поддержку партнеров
  4. 4 Популярные технологии, документация и единый стиль кода. Что учесть при разработке MVP ИТ-проекта
  5. 5 Корпоративные коммуникации в 2024 году
FutureFood
Кто производит «альтернативную» еду
Карта