Чаще всего вопрос о правах на код всплывает, когда разработчик уходит и считает написанный код своим. Может ли он запретить компании использовать программу и хватит ли для защиты трудового договора? Зарплата и корпоративный ноутбук сами по себе этот вопрос не решают. Верховный суд РК разъясняет, что работа в рабочее время или на технике работодателя не делает произведение служебным. Правила при этом простые, в этой статье разберем их по шагам.
Для многих IT-компаний главный актив — программный код. Но создать продукт и юридически контролировать его — разные задачи. Компания может вложить в разработку миллионы теңге, успешно продавать продукт и при этом не иметь документов на отдельные части своей технологии. В Казахстане этот вопрос встает все чаще: IT-рынок растет, компании переходят на SaaS и внедряют искусственный интеллект. Чем сложнее продукт, тем больше людей его создают: штатные программисты, подрядчики, интеграторы, дизайнеры.
Чем автор программы отличается от правообладателя
В обычном бизнесе права на актив подтверждают понятные документы: договор, накладная, запись в реестре недвижимости. С программами иначе. По ст. 7 Закона РК «Об авторском праве и смежных правах» программа охраняется как произведение — и исходный текст, и объектный код. Право возникает в момент создания, без регистрации (ст. 9 Закона). Поэтому защита у кода появляется раньше компании, договора и даже готового продукта.
В правах на код полезно различать три вещи:
- Авторство — связь программы с человеком, который ее создал. Автор всегда физическое лицо.
- Исключительные имущественные права — право использовать программу, разрешать или запрещать ее использование другим.
- Собственность на носитель — владение сервером или ноутбуком, где хранится код.
Купив сервер с программой, компания получает только железо. Репозиторий тоже показывает лишь, где лежит код. Важно другое: на каком основании компания получила права.
Служебное произведение — это результат, который работник создал, выполняя трудовые обязанности или служебное задание. Права на него закон делит так (ст. 14 Закона):
| Права | Кому принадлежат |
|---|---|
| Авторство и право на имя | Разработчику, навсегда |
| Исключительные имущественные права | Работодателю, если договор не устанавливает иное |
Разработчик остается автором и может указать проект в резюме, а продавать служебную программу может компания. Так удобно обеим: компания развивает продукт, а программист сохраняет имя в проекте.
Когда код сотрудника становится служебным произведением
Чаще всего компании пишут программы силами своих сотрудников. Верховный суд в п. 15 постановления № 11 называет два признака служебного произведения: работник создал его, выполняя трудовые обязанности, и по служебному заданию работодателя. Рабочее время и техника компании сами по себе роли не играют.
| Ситуация | Чей код |
|---|---|
| Задача из трекера, сделанная в рабочее время или в выходные | Служебный |
| Свой проект, не связанный с обязанностями | Автора, даже если писал в офисе |
| Утилита «для себя», которой потом стала пользоваться вся команда | Нужна оценка, лучше оформить договор |
| Код основателя до регистрации компании | Основателя, права передают договором |
Пример из практики: программист CRM-системы по задаче пишет модуль аналитики, и модуль входит в продукт. Это служебное произведение. Если тот же специалист по выходным делает игру, права на нее зависят от обстоятельств и договора. Если игра пригодится компании, права проще оформить отдельным договором.
Над продуктом обычно работает команда. Согласно п. 16 Постановления, если части программы нельзя использовать отдельно, ни один соавтор без достаточных оснований не может запретить использование целого. Поэтому задание полезно ставить каждому участнику и фиксировать, кто что сделал.
Какие документы подтверждают права компании на код
Права работодателя держатся на связке: трудовой договор, должностная инструкция, служебное задание, проектная документация и история разработки. Большая часть этих документов у компании уже есть.
В трудовом договоре с программистом полезно прописать три условия:
- какие результаты считаются служебными и принадлежат работодателю;
- входит ли авторское вознаграждение в зарплату или выплачивается отдельно;
- где работник хранит код и как передает результаты.
В должностной инструкции лучше перечислить конкретику: разработка модулей CRM-системы, интеграции, техническая документация. Служебное задание программисту подходит в любой письменной форме, в том числе задачей в трекере. Например: «Разработать модуль выгрузки отчетов по продажам для CRM-системы, версия 2.4, срок — 15 марта, принимает руководитель отдела разработки».
| Что есть у компании | Подтверждает права |
|---|---|
| Зарплата, рабочее время, корпоративный ноутбук | Сами по себе нет |
| Корпоративный репозиторий | Усиливает позицию |
| Должностная инструкция с описанием разработки | Да, подтверждает трудовую функцию |
| Задача с исполнителем и сроком, акт приемки | Да, подтверждают служебное задание |
| Свидетельство Реестра | Само по себе нет, это одно из доказательств |
Определенность дает не количество бумаг, а возможность установить, по чьему заданию создан конкретный результат. В группе компаний у каждого ТОО свои права: код одного юрлица другое использует по договору.
Как превратить процесс разработки в доказательную базу
В споре компании нужно показать, что создано, кем, когда и на каком основании. Собирать это задним числом неудобно. Проще, когда процесс сам оставляет след:
- Пропишите в трудовом договоре условие о служебных произведениях, а в инструкции — обязанности по разработке.
- Ставьте задачи письменно: результат, исполнитель, срок, постановщик.
- Указывайте номер задачи в сообщениях к коммитам.
- Храните код только в корпоративном репозитории.
- Фиксируйте код-ревью и приемку результата.
- Помечайте версии тегами релизов.
- Ведите перечень сторонних библиотек с версиями и лицензиями: у MIT, Apache 2.0 и GPL разные условия.
Задачи удобно вести в трекере, где история сохраняется сама. Например, в задачах и проектах Битрикс24 у задачи есть постановщик, исполнитель и срок, а комментарии и приемка остаются в карточке. Спецификации и акты можно хранить на Диске рядом с проектом.
Права удобнее оформлять по ходу разработки, а не разово после релиза. Для этого полезно распределить роли:
| Кто | За что отвечает |
|---|---|
| Разработчики | Фиксируют этапы работы в задачах и коммитах |
| Руководители проектов | Ставят задачи и следят за сторонними компонентами |
| HR | Вносят условия о служебных произведениях в договоры и инструкции |
| Юристы | Оформляют права, в том числе на результаты подрядчиков |
| Финансовая служба | Проверяет учет программы как актива и налоговые льготы |
Что полезно знать разработчику
Правила защищают и самого программиста. Храните рабочий код в корпоративном репозитории и проверяйте лицензии библиотек. Публикацию кода в открытом доступе, передачу третьим лицам и перенос в личные проекты заранее согласуйте с компанией. Опыт, навыки и личные проекты остаются за вами.
Может ли разработчик использовать код после увольнения
Опыт и навыки уходят вместе с человеком, и на новой работе ими можно пользоваться. Служебный код бывший сотрудник копировать, распространять и продавать не вправе, если договор или закон не сохранил права за ним. Как с поваром: умение готовить остается с ним, а фирменные рецепты — у ресторана.
Чтобы уход прошел спокойно, порядок полезно расписать заранее:
- Сотрудник передает код, документацию и незавершенные задачи.
- Стороны подписывают акт: какие модули, версии и материалы переданы.
- Компания закрывает доступы к репозиториям, серверам и рабочим аккаунтам.
Все это делают по Трудовому кодексу РК и правилам защиты информации. Удерживать расчет до передачи кода компания не вправе.
Если компании нужен личный код сотрудника или основателя, права на него передают авторским договором по ст. 31–32 Закона.
Что делать, если сотрудник зарегистрировал программу на себя
Иногда разработчик вносит сведения о программе в Реестр и получает свидетельство на свое имя. Часто это недопонимание: человек писал код и считает его своим. Свидетельство весит меньше, чем кажется: сведения вносят за один рабочий день, без проверки правообладателя. Оно подтверждает, кто и когда подал сведения, а прав не создает (ст. 9-1 Закона).
Автором по умолчанию считается лицо, указанное на экземпляре произведения (п. 16 и 29 постановления № 11). Поэтому для разговора с разработчиком компании пригодятся документы:
- трудовой договор и должностная инструкция;
- задачи с описанием, исполнителем и сроками;
- история коммитов в корпоративном репозитории;
- акты приемки и состав релизов.
Начать лучше с разговора и предложить разработчику подать заявление об аннулировании добровольно. Если договориться не вышло, сведения аннулируют по решению суда, и тактику стоит выстроить с юристом.
Положено ли разработчику вознаграждение за служебный код
Размер и порядок авторского вознаграждения определяет договор между автором и работодателем (п. 15 постановления № 11). Распространены два варианта:
| Вариант | Как прописать |
|---|---|
| Вознаграждение входит в зарплату | Указать в трудовом договоре, что оплата труда включает вознаграждение за служебные произведения |
| Отдельная выплата | Описать размер или формулу: например, премию за релиз или процент от выручки модуля |
Главное — прописать условие прямо, чтобы у сторон не возникло разных ожиданий.
Переходят ли права к работнику через десять лет
В п. 15 постановления Верховного суда № 11 до сих пор написано, что через десять лет право использовать служебное произведение и получать за него вознаграждение переходит к работнику. Но это разъяснение опиралось на п. 4 ст. 14 Закона, а его исключили еще в 2009 году. Суд применяет редакцию закона, которая относится к спорным отношениям. По действующей редакции исключительные права на служебное произведение принадлежат работодателю, если договор с автором не устанавливает иное. Поэтому сами по себе десять лет ничего не меняют: права остаются у компании.
Краткий вывод
Автор всегда остается автором, личные проекты — личными, а служебный код принадлежит компании. Чтобы граница была видна, хватает понятного трудового договора, задач в трекере и истории коммитов. Когда правила известны с первого дня, команда спокойно пишет код.
Частые вопросы
Сам по себе нет. Договор подтверждает трудовые отношения, а для режима служебного произведения нужна связь кода с обязанностями и заданием. Договор — первое звено цепочки. Дальше идут должностная инструкция, задачи, коммиты и акты приемки: вместе они показывают, по чьему заданию создан код.
Если код написан по рабочей задаче, он служебный, где бы его ни писали. Время и место работы здесь не главное. Личный проект, не связанный с работой, остается за автором. Если он нужен компании, права передают договором.
Имущественные права на служебные результаты закрепить можно. Авторство и право на имя остаются у разработчика. Формулировка «все разработки» работает слабее, чем кажется. Надежнее описать, какие результаты считаются служебными, и связать их с должностной инструкцией.
Размер и порядок вознаграждения определяет договор. Вознаграждение можно включить в зарплату или платить отдельно. Ясное условие избавит обе стороны от вопросов.
Начните с разговора: доступы часто остаются у человека по забывчивости. Если это не помогло, направьте письменное уведомление со списком материалов и сроком. Корпоративные аккаунты и серверы отключите сами. Если код остался только у бывшего сотрудника, обратитесь к юристу.
Основателю как физическому лицу: до регистрации у компании нет работников и служебных произведений. Чтобы код стал активом компании, основатель передает права авторским договором. Инвесторы проверяют этот документ одним из первых.
Да, описать проект, свою роль и технологии можно — это опыт специалиста. Код, его фрагменты и снимки экрана с внутренними данными публикуют только с согласия компании. Если компания готова это разрешить, договоренность лучше оформить письменно.
При подготовке материала использовались инструменты искусственного интеллекта. Текст проверен и отредактирован редактором.
