tgoop.com/aglegal/526
Last Update:
Главные ошибки в оформлении разработок. Часть 3
В первом и втором постах нашей серии мы рассказывали про ошибки, связанные с оформлением отношений с работниками, вовлеченными в разработку ПО и баз данных. Сегодня же мы сконцентрируемся на другой теме – оформление внутренней документации, фиксирующей факт разработки.
С одной стороны, пункт 4 статьи 1259 Гражданского кодекса РФ говорит: "Для возникновения, осуществления и защиты авторских прав не требуется регистрация произведения или соблюдение каких-либо иных формальностей". Регистрация программ и баз данных в Роспатенте и Реестре российского ПО Минцифры существует, но является добровольной. Отсутствие регистрации не означает, что программного продукта не существует или что он не охраняется законом. Исходя из этого многие компании (особенно небольшие стартапы) ограничиваются оформлением трудовых или гражданско-правовых договоров с разработчиками, а ход разработки фиксируют исключительно в системах типа Trello или Jira. И в таком стиле ведения дел нет противоречия с законодательством об интеллектуальной собственности, это правда.
Проблемы возникнут в ситуации, когда внезапно потребуется доказать, что продукт был разработан в определенный период времени (раньше конкурента, например). Или продемонстрировать документально, на каком основании компания стала правообладателем ПО. В таких ситуациях просто трудовых договоров или договоров ГПХ с разработчиками будет недостаточно, потому что потребуется показать именно наличие проекта по разработке строго определенного ПО, с определенным набором функциональных характеристик и технологическим стеком.
В отсутствие регистраций программы или базы данных решение – это выпуск внутренних документов, фиксирующих начало и окончание разработки. Приказ о начале разработки с техническим заданием и закрывающий документ (акт, отчет, приказ) покажут, когда, кем и какое было разработано ПО. При этом такой документооборот вполне можно комбинировать с гибким подходом к разработке, когда в ТЗ указываются только верхнеуровневые требования, а их детализация делегируется ответственному сотруднику.
#ОшибкиВоформленииРазработок