Сотрудник зарегистрировал программу на себя: как компании доказать право на код?
Фото: pixabay
Для технологической компании исходный код нередко является главным активом. Однако вопрос о том, кому он принадлежит, часто откладывают до инвестиционного раунда, продажи бизнеса или ухода ключевого разработчика. Именно тогда выясняется: программа находится в корпоративном репозитории и годами продается клиентам, но автор зарегистрировал ее на свое имя и утверждает, что создавал продукт самостоятельно.
Казахстанское законодательство позволяет работодателю владеть исключительными имущественными правами на служебное произведение. Но закон не устанавливает правила "все созданное работником принадлежит компании". Работодателю необходимо связать конкретный код, модуль или версию с трудовыми обязанностями автора либо с выданным ему служебным заданием.
Регистрация не решает спор автоматически
Авторское право возникает в момент создания произведения. Для его возникновения не требуется регистрация, депонирование или иное специальное оформление. Поэтому свидетельство о внесении сведений в Государственный реестр прав на объекты, охраняемые авторским правом, не следует воспринимать как патент на программу.
Свидетельство подтверждает внесение определенных сведений в Реестр. Оно может быть важным доказательством, однако само по себе не устанавливает окончательно, кто действительно создал код, являлась ли разработка служебной и кому принадлежит вся цепочка исключительных прав. Презумпция авторства относится к личности автора и может быть опровергнута другими доказательствами. При этом автор и правообладатель не всегда совпадают: автором является физическое лицо, а исключительными имущественными правами при наличии законного основания может владеть работодатель.
Действующие правила Реестра также исходят из необходимости подтверждать основание прав. Для компьютерной программы представляются реферат и исходный код; для служебного произведения – договор между автором и работодателем о принадлежности имущественных прав; для производного произведения – документ, подтверждающий право на переработку оригинала. Следовательно, реестр дополняет цепочку документов, а не заменяет ее.
Что является служебным произведением?
Статья 14 Закона РК "Об авторском праве и смежных правах" называет служебным произведение, созданное в порядке выполнения служебных обязанностей или служебного задания работодателя. Исключительные имущественные права на такой результат по общему правилу принадлежат работодателю, если договор с автором не предусматривает иное.
На практике требуется проверить пять обстоятельств:
- Существовали ли трудовые отношения в период создания соответствующей версии;
- Входило ли создание такого результата в трудовую функцию работника или выдавалось ли ему конкретное задание;
- Можно ли связать спорный файл, модуль или релиз именно с этой функцией или заданием;
- В чем состоял творческий вклад конкретного лица и других участников команды;
- Не установили ли стороны в договоре другой режим имущественных прав.
Рабочее время, служебный ноутбук, корпоративная почта, оплата серверов и размещение кода в репозитории компании усиливают позицию работодателя, но не являются самостоятельной заменой первых двух критериев. Сотрудник может написать личную программу на корпоративном устройстве, а компания может использовать созданный вне трудовой функции продукт по лицензии. Суд будет оценивать содержание отношений, а не только место хранения файлов.
Какие элементы продукта могут охраняться?
Для программы охрана распространяется на исходный текст и объектный код независимо от языка программирования и формы выражения. Отдельными объектами либо частями общей разработки при наличии творческого характера могут выступать интерфейс, графические элементы, документация, тексты, схемы, оригинальные тестовые материалы и база данных, если подбор или расположение материалов являются результатом творческого труда.
Но авторское право не монополизирует идею сервиса, бизнес-логику, математический метод, принцип работы, формат данных, факт или функцию как таковую. Два продукта могут решать одинаковую задачу и при этом иметь различный код. Поэтому утверждение о копировании нельзя строить только на похожем наборе экранов или функций: необходимо исследовать охраняемую форму выражения и точно определить сравниваемые версии.
Техническая помощь также не образует соавторства автоматически. Постановка бизнес-задачи, финансирование, управление проектом, тестирование по готовому сценарию или исправление опечаток сами по себе не делают человека автором. Нужен творческий вклад в форму произведения. В командной разработке важно заранее фиксировать, кто создавал архитектурные решения, код, дизайн, документацию и другие охраняемые элементы.
Что закрепить в трудовых документах компании?
Одна универсальная фраза о том, что "все права принадлежат работодателю", полезна, но недостаточна. Трудовой договор, должностная инструкция и внутреннее IP-положение должны работать вместе.
В них целесообразно:
○ описать трудовую функцию через виды создаваемых результатов, а не только через название должности;
○ определить, что служебные задания могут выдаваться в корпоративной системе управления проектами, электронной почте и иных утвержденных каналах;
○ перечислить результаты: исходный и объектный код, модули, обновления, базы данных, интерфейсы, документацию, схемы, тесты и материалы по внедрению;
○ установить обязанность вести разработку через корпоративные аккаунты, репозитории и инфраструктуру;
○ обязать работника указывать ранее созданные и сторонние компоненты до их включения в продукт;
○ предусмотреть фиксацию авторов, версий, заданий, приемки и релизов;
○ урегулировать использование open-source библиотек и AI-инструментов;
○ определить передачу кода, ключей, документации и доступов при изменении роли или прекращении работы;
○ отдельно подтвердить режим конфиденциальности и коммерческой тайны.
Договор не должен пытаться объявить служебным любой будущий результат человека независимо от его связи с работой. Такая чрезмерная формулировка не отменит необходимость доказать фактические обстоятельства создания.
Главным доказательством часто становится хронология
В споре редко существует один документ, который отвечает на все вопросы. Убедительную позицию формирует согласованная история разработки: трудовой договор и должностная инструкция; технические и продуктовые задания; backlog и issue tracker; commits, branches, pull requests и code review; сборки и CI/CD; release notes; переписка команды; акты приемки; журналы доступа; счета за инфраструктуру; клиентские релизы.
Важно сохранять метаданные и понимать происхождение каждого доказательства. Скриншот репозитория показывает состояние экрана на определенный момент, но не обязательно подтверждает, кто и когда создал содержимое. При возникновении конфликта безопаснее сформировать форензик-копию репозитория или устройства, зафиксировать hash и цепочку хранения, а затем передавать материалы специалисту в контролируемом режиме.
Если требуется сравнение двух программ, эксперту следует передавать конкретные версии и полные наборы материалов, отделив сторонние библиотеки, сгенерированный код и общедоступные компоненты. Эксперт может установить технические совпадения, их объем, структуру и хронологию. Вопросы о том, кто является автором, кому принадлежат права и имело ли место правонарушение, разрешает суд.
Подрядчик – это другая правовая модель
Режим служебного произведения применяется к отношениям автора и работодателя. Если код создает фрилансер, индивидуальный предприниматель или студия, оплата счета и подписание обычного акта не передают исключительные права автоматически.
Нужен письменный договор, в котором перечислены конкретные результаты и способы использования, территория, срок, вознаграждение, момент перехода прав, возможность изменения, передачи аффилированным лицам и выдачи лицензий. Когда подрядчиком является юридическое лицо, необходимо проверить два звена: получил ли подрядчик права от физических авторов и передал ли затем необходимый объем прав заказчику.
Отдельный риск возникает, если MVP написан основателем или CTO до регистрации компании. Участие автора в капитале не означает автоматической передачи кода созданному позднее ТОО. Такой результат нужно передать компании отдельным письменным документом.
Как не доводить вопрос до суда
Компании полезно провести короткий IP-аудит до конфликта: составить перечень всех лиц, участвовавших в продукте; проверить их статус; сопоставить договоры с фактическими задачами; восстановить историю версий; закрыть разрывы в передаче прав; утвердить режим коммерческой тайны; перевести репозитории и инфраструктуру на корпоративные аккаунты; оформить контролируемый offboarding.
Правильный вывод состоит не в том, что работодателю достаточно написать широкую оговорку в трудовом договоре. Компания должна уметь доказать путь конкретного результата от задания и автора до релиза и коммерческого использования. Именно эта цепочка, а не один сертификат или один commit, определяет устойчивость прав на программный продукт.
