Может ли компания претендовать на весь написанный разработчиком код
2026-02-21 21:50 Diff
https://skillbox.ru/media/code/mozhet-li-kompaniya-pretendovat-na-ves-napisannyy-razrabotchikom-kod/

#статьи

  • 21 фев 2022
  • 0

Может ли компания претендовать на весь написанный разработчиком код

Ха! Программисты — не просто гребцы на галерах, а полноправные владельцы кода, который они пишут. Разбираемся вместе с юристом.

Иллюстрация: Polina Vari / Skillbox Media

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

Ассоциированный партнёр Legit. Юридический консультант с более чем 15-летним опытом.

Специализируется на вопросах интеллектуальной собственности, праве в IP/IT, разрешении коммерческих и антимонопольных споров, юридического дизайна процессов и документов.

Есть один вечный вопрос, который беспокоит разработчиков: а правда ли, что работодателю или заказчику принадлежат права на все результаты их труда?

  • Первая новость — хорошая: ну конечно же, нет! Аллилуйя, гражданский и трудовой кодексы в России ещё пока действуют, а разработчики не стали рабами IT-корпораций!
  • Новость вторая: и всё-таки работодателю принадлежат права на те разработки, которые вы для него создали. И эта новость — тоже хорошая, мне кажется.

Правда в том, что компания наняла вас, скорее всего, не за красивые глаза, а за ваши скиллы, а если выражаться ещё точнее — за то, что вы, благодаря своим умениям и навыкам, способны для неё создать. Будем откровенны: компания не заинтересована в оплате вашего труда (например, количества часов, которые вы проводите за компьютером), она вам платит за результат. И если вы разработчик, то результатом вашего труда, вероятнее всего, будет код.

Отсюда следствие: компания заинтересована в приобретении исключительных прав на весь написанный вами код. И её интерес охраняется законом.

В России код (объектный или исходный) признаётся объектом авторского права (программой для ЭВМ). И даже если вы разрабатываете или организуете базу данных, то и она может охраняться как объект интеллектуальной собственности. Вопрос в том, кому принадлежат исключительные права.

Здесь надо сразу оговориться, что, в широком смысле, существуют лишь два сценария ваших отношений с компанией относительно процесса разработки:

  • вы работник — у вас трудовой договор,
  • вы подрядчик — фрилансер, самозанятый, ИП.

Два сценария — два способа правового регулирования.

Для работников и их работодателей действует, на первый взгляд, довольно простое правило: исключительные (то есть имущественные) права на все результаты интеллектуальной деятельности (РИД), которые создаст работник в рамках трудовых обязанностей, принадлежат работодателю — и это общее правило. Разумеется, стороны могут договором предусмотреть иное — но где вы видели это «иное»? :) Такие правила установлены статьёй 1295 ГК РФ.

Однако есть нюансы, и они настолько важны, что в них стоит разобраться.

1. За разработчиком в любом случае сохраняются авторские (неимущественные) права — например, право называться (считаться, указываться) автором. Такие права неотчуждаемы.

2. Работодатель должен в установленный срок (в случае с программами для ЭВМ — в течение трёх лет) либо начать использовать РИД, либо передать или предоставить исключительное право на этот результат иному лицу, либо уведомить автора о сохранении РИД в тайне. Если работодатель в установленный срок этого не сделал, исключительные права возвращаются работнику. Однако работодатель сохранит право использования РИД на условиях простой (неисключительной) лицензии — за деньги, конечно, и на условиях, о которых вы с работодателем договоритесь отдельно (или которые за вас определит суд).

Вывод для компаний: контролируем, что и когда создают работники, и вовремя вступаем в свои права.

Вывод для работников: уведомляем работодателя и следим за сроками. И тут сразу же рубрика «Вредные советы»: кажется, что скрыть от компании результаты разработки — классная идея! На самом деле — нет. Не делайте так :)

3. В-третьих, даже если исключительные права на служебное произведение перешли работодателю и он стал его использовать, работник имеет право на авторское вознаграждение.

Ещё одна хорошая новость для разработчиков: авторское вознаграждение — это не ваша зарплата, оно не включено в зарплату и должно быть согласовано и выплачено отдельно. А всё потому, что соглашение о выплате авторского вознаграждения — гражданско-правовое по своей природе, а не трудовое.

На самом деле с помощью таких выплат компании нередко пытаются стимулировать программистов — чтобы они документировали свои наработки, правильно учитывали затраченное время и вовремя уведомляли работодателя. В итоге работнику полагается вознаграждение, а компания получает своевременный учёт интеллектуальной собственности и затрат на её создание.

Если вознаграждение выплачено не было, работник может его потребовать через суд. Не сказать, чтобы в России взыскивали какие-то значимые суммы, но прецеденты были: смотрите, например, относительно свежее определение Верховного Суда РФ от 5 июня 2020 года № 78-КГ20-1 по делу А. Кукина против «НТЦ тонкоплёночных технологий в энергетике». Хотя речь шла о вознаграждении за служебные патенты, суд сформулировал и универсальные подходы.

4. Наконец, самое важное: не всякая программа, написанная работником, — служебное произведение. Потому что, даже если вы штатный разработчик (допустим, senior) и ваша основная работа — что-то кодить, и вы что-то таки накодили «для себя» и сделали это в рабочее время, в офисе и на компьютере работодателя, а потом разместили всё это в корпоративном репозитории (вопрос, конечно, зачем?), совсем не факт, что исключительные права на такой код принадлежат вашей компании. Как писал классик, «а был ли мальчик»? Привет из сериала «Кремниевая долина», где у главного героя чуть не отобрали права на программу за то, что однажды он задеплоил её с рабочей машины.

Дело в том, что закон (п. 1 ст. 1295 ГК РФ) оперирует таким критерием, как трудовые обязанности. Так вот, если написание совершенно конкретной программы входило в трудовые обязанности, значит, права на неё принадлежат компании. Ну а если не входило — выходит, права остаются за разработчиком.

Чем же определяются трудовые обязанности? Прежде всего трудовым договором, должностью (позицией) и должностной инструкцией. В этих документах зафиксировано, кем является сотрудник и чем он должен заниматься на работе.

Работодатель должен доказать, что конкретный РИД был создан как служебный, именно в рамках прямых обязанностей сотрудника. И здесь обычно компания оказывается между Сциллой и Харибдой.

  • С одной стороны, нельзя описать должностные обязанности слишком абстрактно. Например, теоретически можно написать что-то вроде «программист программирует»: да, это вроде как верно, но что именно, где, как и зачем он программирует? А главное, вдруг он что-то запроектировал, но руками код не писал?
  • С другой стороны, нельзя слишком уходить в частности. Например, формулировка: «Иванов Иван Иванович пишет код интерфейса модуля „Коленный сустав“ программы „Рога и копыта“ на языке Python» — выглядит не слишком жизнеспособной и работает ровно до тех пор, пока Иванов И. И. свой модуль не завершит. И, не дай бог, он переключится на Java!

Что делать компаниям: регулярно обновлять документы (трудовой договор, штатное расписание), писать адекватные должностные инструкции для каждой позиции и, главное, — сформировать систему постановки задач и приёмки результатов. Когда обязанности работника достаточно конкретно определены в матрице, а уже конкретные служебные задания ставятся руководством (сегодня он пишет модуль «Коленный сустав», а завтра занимается отладкой модуля «Сердце» — и всё это зафиксировано), доказать, что конкретная программа была создана как служебная, значительно проще.

Это best practices. Лучше сразу и обо всём договориться с работниками. О том, кто, как и кем работает; кто и как ставит задачи; как и когда надо отчитываться о результатах; и, конечно, как будет рассчитываться и выплачиваться авторское вознаграждение. Так поступают хорошие (и не просто хорошие, а умные) компании.

А что же нехорошие (или неумные)? Они предлагают подписать договор с формулировками вроде: «Исключительные права на любые РИД, созданные Ивановым И. И., принадлежат ООО „Рога и копыта“». Однако такие формулировки не работают и расходятся с законом. Особенно если Иван Иваныч по трудовому договору — вахтёр. Некоторые поступают ещё хитрее и авторами всех разработок по документам вдруг волшебным образом оказываются генеральный директор или собственник. Видите такое в договоре — сразу задумайтесь, надо ли оно вам.

На эту тему в России есть два показательных кейса.

Первый — дело Антона Мамичева против Veeam. По сути, в нём нет победителей — только проигравшие. Оно чётко показывает: не всякая программа, созданная работником, является служебной — и очень опасно не договариваться обо всём вовремя.

Второй — нашумевшее дело Nginx. Дело о том, что вопрос о принадлежности исключительных прав на программу может застать вас врасплох даже через много лет после того, как вы уже уволились, — причём на вас могут попытаться повесить даже уголовную ответственность. К счастью, пока это дело не завершилось каким-то судебным актом. Однако история очень показательная и яркая.

Здесь всё значительно проще. Когда у вас нет трудовых отношений с компанией, ни одна из ваших разработок не может быть признана служебной. Следовательно, все вопросы права определяются только договором (и в некоторых случаях — рядом сопутствующих фактических обстоятельств). В каком бы статусе вы ни выступали по отношению к компании-заказчику (физическое лицо, самозанятый, ИП или юридическое лицо), вам, скорее всего, потребуется договор авторского заказа.

Российское гражданское законодательство исходит из принципа диспозитивности. Это значит, что стороны могут договориться о том, какое право и в каком объёме будет принадлежать заказчику. Согласно ст. 1288 ГК РФ (о договоре авторского заказа) заказчик может получить как исключительное право на разработку, так и ограниченное право использования (лицензию).

Вывод: условие о принадлежности исключительных прав на разработку должно быть явно согласовано.

Но это ещё не всё. Из договора должно определённо следовать, что именно будет создано. Сложность в том, что на момент заключения договора никакой разработки ещё нет (например, ваш код ещё не написан), однако стороны понимают, что именно должно явиться результатом разработки и кому будут принадлежать права на них.

В этом и есть основное отличие договора авторского заказа от любых иных договоров:

  • в договоре об отчуждении исключительных прав речь идёт об уже существующем объекте;
  • в договоре подряда — о работе по созданию неких сущностей, не являющихся объектами интеллектуальной собственности;
  • в договоре об оказании услуг — о потреблении услуги (но не объекта) непосредственно в момент её оказания.

Как правило, описание будущей разработки или требований к ней содержится в техническом задании или спецификации, которые оформляются как приложение к договору. Такие описания должны быть достаточно подробными, чтобы по ним можно было идентифицировать конкретную разработку — результат исполнения договора.

Кроме того, в договоре надо предусмотреть точку перехода прав на разработку. Это может быть момент фактического создания продукта, момент оплаты, момент подписания акта приёмки или какая-то иная указанная в договоре дата (но, конечно, не ранее даты фактического создания произведения).

И здесь необходимо вновь проявить осмотрительность: если факт перехода прав определяется актом, в акте должно быть в полном объёме отражено, что именно и каким образом по договору передано — то есть все элементы разработки. Упустите что-то, не отразите в акте — рискуете оказаться в ситуации, когда документально не сможете подтвердить, что разрабатывали определённый программный модуль и передавали его заказчику. А мы ведь все помним удивительную силу бумаг в суде, не так ли?

Разработка, особенно в IT, особенно служебная, — очень непростая для юриста материя. Программисту, кажется, проще: если какая-то функциональность создаётся, значит, появляется какой-то работающий код — и лучше его не трогать, пока он работает как надо.

Когда на эту же ситуацию смотрит юрист, он видит совсем другие сущности и у него возникают совершенно другие вопросы. Какой именно код, какой конкретно программист и на каких именно условиях написал? Кому принадлежат права? Что с авторским вознаграждением? И если юрист не находит ответов, у него может непроизвольно произойти системный сбой: «Шеф, всё пропало! Гипс снимают, клиент уезжает!» Тогда во избежание рисков юрист вдруг рожает абсурдную рекомендацию: «Разработку использовать категорически не рекомендуется!»

Конечно, это пример не самого бизнес-ориентированного подхода не самого хорошего юриста. Но всё-таки пожалейте своего юриста и прислушайтесь к его советам до того, как приступите к разработке :)

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу