Привет! Сегодня я расскажу про вопрос, который критически важен для любого IT/IP/медиа бизнеса – оформление прав на служебные разработки сотрудников. Официально это называется "служебные произведения", но мы будем называть это "разработки", потому что звучит как-то более естественно.
Почему это важно
По умолчанию авторские права на все, что делает сотрудник – код, дизайн, видео, графика, сайты и т.п. (далее – «разработки») – принадлежит сотруднику, а не компании. Сделать так, чтобы права на разработки принадлежали компании, можно, но для этого нужно правильно составить документы и наладить процессы.
Что будет, если этого не сделать
Компания не сможет использовать разработки сотрудника – это будет нарушением его авторских прав. Сотрудник может подать в суд на компанию и отсудить деньги. Сотрудник может продать продукт конкурентам. Сотрудник может уйти и начать свой бизнес с этим продуктом, а бывшая компания не сможет его использовать.
Для каких компаний это актуально
Актуально практически для любого бизнеса, который связан с IT/IP/медиа. Сотрудники разрабатывают ПО – нужно оформить права на код и дизайн. Сотрудники делают сайты – нужно оформить права на дизайн и на код. Сотрудники делают видеоконтент – нужно оформить права на видео, фоновую музыку и сценарий. Сотрудники делают видеоигры – нужно оформить права на код, дизайн, видео, саундтрек, сценарий, персонажей. Сотрудники делают рекламу – нужно оформлять права на все креативы.
Для каких должностей это актуально
Для всех, кто делает контент. Программисты. Дизайнеры. Видеографы. Композиторы / звукоинженеры. Гейм-дизайнеры. Игровые писатели. Арт-директоры.
Развенчиваем мифы
Миф 1. Достаточно написать в договоре, что «все права на разработки сотрудника принадлежат компании». Это не сработает.
Миф 2. Сотруднику не нужно платить ничего, кроме зарплаты. Это несет риски.
Миф 3. Если нарушить авторские права сотрудника, за это ничего не будет. Это неправда, сотрудники тоже знают свои права.
Что теперь делать?
Чтобы права на разработки принадлежали компании, нужно выполнить три условия:
1. Создание разработок должно входить в должностные обязанности сотрудника;
2. Сотруднику нужно выплатить за разработку отдельное вознаграждение, помимо зарплаты;
3. Разработку нужно начать использовать в течение 3 лет.
Теперь разберемся по каждому пункту.
Создание разработок должно входить в должностные обязанности
Это ключевой момент. Компания может получить права только на то, что работник сделал в рамках своих трудовых обязанностей. Например, тестировщик создает приложение. Вероятнее всего, у тестировщика в должностной инструкции ничего не сказано о создании приложений. В этом случае права на приложение будут принадлежать сотруднику, т.к. создание приложений не входило в его должностные обязанности.
Другой пример. Дизайнер делает дизайн, но в должностной инструкции у него какая-нибудь максимально расплывчатая формулировка вроде «выполнять текущие задачи» или «выполнять указания руководителя». Здесь нет ничего про создание дизайнов, поэтому все, что сотрудник надизайнит, будет принадлежать ему, а не компании.
Даже если сотрудники делали это в рабочее время и на рабочем компьютере, это, скорее всего, не поможет, потому что ключевой вопрос – входило ли это в обязанности. Если не входило – значит, это инициатива сотрудника и его собственность.
Поэтому для всех, кто делает разработки, нужна подробная должностная инструкция с максимально полным описанием всего, что делает сотрудник. Если функционал поменялся и добавились новые обязанности – это тоже обязательно нужно зафиксировать.
Сотруднику нужно выплатить отдельное вознаграждение, помимо зарплаты
Часто компании вообще никак не решают этот вопрос. Либо включают в трудовые договоры условия вроде «авторское вознаграждение за разработки входит в состав заработной платы». В 2020 г. Верховный суд признал такую практику незаконной. Авторское вознаграждение должно быть выплачено отдельно от зарплаты. Хорошая новость в том, что размер вознаграждения определяется по соглашению сторон, т.е. фиксированных ставок нет, и вы в принципе можете договориться с сотрудником на любую сумму, хоть 100 рублей.
Разработку нужно начать использовать в течение 3 лет
В течение 3 лет после того, как сотрудник создал разработку, работодатель должен сделать одно из следующих действий:
1. Начать использовать разработку;
2. Продать разработку другому лицу;
3. Письменно сообщить сотруднику о том, что разработка сохраняется в тайне.
Если ничего из этого не сделать, то все права на разработку перейдут к сотруднику. В 90% случаев компания просто начинает использовать разработку, и вопрос закрывается. Но если у вас другие планы, то нужно не забыть сделать одно из этих действий.
Важно!
По закону именно работодатель должен доказать, что разработка является служебной, т.е. что он выполнил все три условия. Сотрудник ничего доказывать не должен. Т.е. именно компания должна заранее собрать все доказательства: что разработка входила в обязанности сотрудника, что ему выплачено вознаграждение отдельно от зарплаты и т.д. Поэтому в случае спора компания будет находиться в заведомо более рискованной позиции.
Как все это оформить
Как видите, оформить права на служебные разработки – очень важно, но не очень просто. Но хорошая новость в том, что нет каких-то жестких обязательных требований, как это делать. Можно выбрать свой вариант в зависимости от того, как в компании устроены процессы и как вам удобнее работать.
Условно можно выделить два варианта, как это обычно делается:
1. Вариант «много бумажек». Что вам понадобится:
1.1. Трудовой договор
1.2. Должностная инструкция. Должны быть подробно расписаны конкретные обязанности сотрудника, в том числе, по созданию разработок.
1.3. Положение о служебных разработках. Ваш внутренний регламент, который фиксирует, как у вас ставятся задачи на разработку, как разработки передаются от сотрудника и как они учитываются разработки.
1.4. Служебное задание. Задание сотруднику на конкретную разработку с примерным описанием задачи.
1.5. Акт о приемке разработки у сотрудника. Документ, которым сотрудник подтверждает, что передал права компании на конкретную разработку.
1.6. Выплата авторского вознаграждения.
2. Вариант «чуть меньше бумажек». Что вам понадобится:
2.1. Трудовой договор.
2.2. Должностная инструкция.
2.3. Положение о служебных разработках.
2.4. Таск-менеджер (Jira, Youtrack, Asana и т.п.). Постановка, выполнение задач и передача результата фиксируются в трекере.
2.5. Выплата авторского вознаграждения.
У обоих вариантов есть плюсы и минусы. Выбирать нужно тот, с которым лично вам будет удобнее работать. Если в компании любят обкладываться бумажками, то подойдет первый вариант. Он также может подойти небольшим компаниям, где мало разработчиков, и есть возможность подписывать бумажки с каждым разработчиком по каждому продукту. Еще этот вариант хорош на случай суда, потому что суды лучше всего воспринимают доказательства на бумажке с подписями и печатями. Минус – много бумажек и нагрузка на сотрудника, который будет ими заниматься.
Если в компании десятки, сотни, тысячи разработчиков, то вариант «много бумажек», скорее всего, не вариант, потому что оформлять такое количество разработок на бумаге нереально. Он немного сложнее в случае суда, потому что придется потратить больше усилий на фиксацию доказательств и объяснения суду, как это все работает. Впрочем, уже есть прецеденты, когда судьи принимают скриншоты из трекеров в качестве доказательств.
А что, если никак не оформлять?
На самом деле это еще не конец света, и в случае спора есть шанс доказать, что права на разработку принадлежат компании. Суды учитывают не только бумажки, которые вы составили или не составили, но и другие обстоятельства по делу. Например:
· Соотношение сферы деятельности работодателя и сферы, для которой предназначена конкретная разработка;
· Пределы трудовых обязанностей сотрудника;
· Место выполнения работ;
· Кому принадлежат использованные оборудование и материалы – сотруднику или компании;
· Возможность осуществления работодателем контроля за работой, в рамках которой создана разработка;
· Цель создания;
· Последующее поведение сотрудника и работодателя;
· Составляемые ими в процессе трудовой деятельности сотрудника документы, которые в совокупности могли бы свидетельствовать о разработке объектов в порядке исполнения трудовых обязанностей.
Но нужно понимать две вещи.
Во-первых, по закону именно работодатель должен доказать, что разработка является служебной. Сотрудник не должен оправдываться и доказывать, что это не так. Все доказательства придется собирать компании.
Во-вторых, в этом случае вы будете слишком сильно зависеть от количества и качества доказательств, которые вы сможете собрать. Если вы не сможете их собрать или соберете недостаточно, то есть реальный риск проиграть дело. А если у вас будет настроена система оформления прав на служебные разработки, то все нужные документы будут оформляться вовремя, и у вас будет выше шанс выиграть спор. Поэтому лучше заранее настроить у себя в компании систему оформления прав на разработки.
Примеры судов
Пример 1. Программисты работали в медтехе и разработали ПО. Потом они ушли, создали свою фирму, и начали продавать это ПО. Бывший работодатель подал в суд и потребовал признать за ним право на ПО, мол, это служебная разработка. Но из доказательств у него был только трудовой договор. Не было задания на разработку, доказательств создания именно в период работы в компании, акта приемки разработки у сотрудника. Суд отказал в иске. Результат – работодатель потерял права на ПО, сотрудник открыл с ним свой бизнес.
Решение Арбитражного суда г. Москвы по делу А40-202764/18-110-1552 от 01.02.2019
Пример 2. Сотрудник сделал несколько изобретений. Работодатель сказал, что авторское вознаграждение за них уже включено в состав зарплаты, и не выплатил отдельное вознаграждение. Работник взыскал с компании 370 000 рублей.
Апелляционное определение Санкт-Петербургского городского суда по делу № 33-650/2021 от 28.01.2021
Саммари
По умолчанию весь контент, который делает сотрудник (код, дизайны, графика, видео, сайты и т.п.), принадлежит сотруднику. Чтобы права принадлежали компании, нужно правильно оформить документы и настроить процессы. Без этого не получится использовать разработки. Риски: компания может потерять права на разработки; сотрудник может подать в суд на компанию и отсудить денег. Что разработка является служебной, должен доказывать именно работодатель, т.е. компания заведомо находится в более невыгодном положении.
Как я это делаю
1. Проводим аудит существующих документов и процессов в этой сфере.
2. Подготовка предложений по документам и процессам, обсуждение с заказчиком, корректировка. Стараюсь максимально сохранить существующие процессы, чтобы командам было привычно работать.
3. Создание документов и описания процессов: трудовые договоры, должностные инструкции, положение о служебных разработках и т.д.
4. Помощь командам во внедрении документов и процессов. Делаем так, чтобы все работало.
Что делать дальше
Если у вас есть вопрос, нужно посмотреть документы или вы хотите сделать такую систему у себя в компании – напишите мне. Мои контакты здесь https://taplink.cc/m_voytsekhovsky