👨🏻💻
Российский разработчик отсудил права на свой код у работодателя: почему шаблонные трудовые договоры больше не спасают ИТ-компанииМногие из тех, кто это читает, знает, насколько мне небезразлично IT. Так вот: коллеги из CNews осветили
огненный кейс, который заставит напрячься каждого тимлида и обрадует каждого мидла. Российский программист выиграл суд у ИТ-компании, доказав, что его pet-проект принадлежит только ему, а не работодателю.
Разбираем, где проходит грань между «рабочим» и «личным», и почему старые методы присвоения интеллектуальной собственности (ИС) больше не работают.
💬
Что случилосьКлассика жанра: разработчик трудился в штате компании, а по вечерам и выходным пилил свой собственный проект. Когда проект «взлетел», работодатель решил, что раз программист работает у них, то и все, что он кодит в период трудоустройства — это служебное произведение. Компания попыталась забрать права себе, но суд ее остановил.
⚖️
Почему суд встал на сторону ИТ-шникаВ ИТ-менеджменте живет токсичный миф: если в трудовом договоре написано, что все права переходят нам — значит, код наш.
В реальности, чтобы исходный код стал
служебным произведением, компании нужно доказать три железобетонных факта:
1.
Связь с обязанностями. Код должен быть написан в рамках конкретных трудовых обязанностей (а не просто потому что «он же программист»).
2.
Служебное задание. Должен быть документальный след: конкретная задача (тикет в таск-трекере), по которой велась разработка.
3.
Авторское вознаграждение. Зарплата — это плата за
процесс труда. За
отчуждение прав компания обязана выплатить отдельное вознаграждение (пусть даже 1000 рублей, но отдельной строкой).
В этом кейсе компания посыпалась на формальностях: код писался не по ТЗ работодателя, в нерабочее время и на личном оборудовании.
✅
Как теперь работать (чтобы не встретиться в суде)💼
Для фаундеров и ИТ-компаний:— Проведите аудит кадровых документов. Обтекаемая формулировка «разработка ПО» в трудовом договоре не спасет. Должностные инструкции должны быть конкретными.
— Легализуйте таск-трекеры. В договоре должно быть прямо указано, что постановка задачи в Jira/Youtrack приравнивается к служебному заданию.
— Платите за права. Разделите в расчетном листке оклад и авторское вознаграждение за передачу исключительных прав.
💻
Для разработчиков:— Разделяйте «железо». Никогда не пишите свои pet-проекты на корпоративном макбуке. Суд всегда проверяет, на чьем оборудовании создавался РИД.
— Внимательно читайте оффер и NDA. Если компания требует передавать права на вообще все, что вы создаете 24/7 — просите исключить этот пункт (или зовите юриста).
— Соблюдайте тайминг (это не главное, но все же). Не коммитьте свой код в рабочее время.
Копипаст трудовых договоров из 2020 года обходится бизнесу слишком дорого. Эпоха джентльменских договоренностей прошла — суды теперь прекрасно разбираются и в логах, и в гитхабе.
🎬
Причем здесь медиа?Если вам кажется, что это сугубо айтишная боль, спешу разочаровать. В кино, рекламе и дизайне механизмы работают абсолютно так же. Ваш штатный моушн-дизайнер на выходных собрал гениальную 3D-сцену, а сценарист набросал крутой синопсис, который студия решила пустить в производство? Без четкого служебного задания и акта приемки исключительные права остались у них.
Для креативной индустрии такие ошибки обходятся даже дороже. Если в ИТ из-за одного спорного модуля может отвалиться фича или зависнуть сделка, то в медиа из-за неочищенного кадра, ИИ-промпта или анимации, созданной сотрудником в свободное время, стриминг или видеохостинг просто заблокирует весь ваш многомиллионный проект. Так что советы выше для киноделов и агентств актуально ровно в той же мере.
P.S. Самое смешное и грустное в таких процессах — наблюдать, как юристы компании пытаются доказать суду, что коммит разработчика в его личный репозиторий в 3 часа ночи воскресенья был сделан «по прямому и неотложному поручению руководства»...
