Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>21 фев 2022</li>

3 <li>0</li>

4 </ul><h2>Может ли компания претендовать на весь написанный разработчиком код</h2>

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

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

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

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

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

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

11 <ul><li>Первая новость - хорошая: ну конечно же, нет! Аллилуйя, гражданский и трудовой кодексы в России ещё пока действуют, а разработчики не стали рабами IT-корпораций!</li>

12 <li>Новость вторая: и всё-таки работодателю принадлежат права на те разработки, которые вы для него создали. И эта новость - тоже хорошая, мне кажется.</li>

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

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

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

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

17 <ul><li>вы работник - у вас трудовой договор,</li>

18 <li>вы подрядчик - фрилансер, самозанятый, ИП.</li>

19 </ul>Два сценария - два способа правового регулирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34 <ul><li>С одной стороны, нельзя описать должностные обязанности слишком абстрактно. Например, теоретически можно написать что-то вроде "программист программирует": да, это вроде как верно, но что именно, где, как и зачем он программирует? А главное, вдруг он что-то запроектировал, но руками код не писал?</li>

35 <li>С другой стороны, нельзя слишком уходить в частности. Например, формулировка: "Иванов Иван Иванович пишет код интерфейса модуля "Коленный сустав“ программы "Рога и копыта“ на языке Python" - выглядит не слишком жизнеспособной и работает ровно до тех пор, пока Иванов И. И. свой модуль не завершит. И, не дай бог, он переключится на Java!</li>

36 </ul>Что делать компаниям:регулярно обновлять документы (трудовой договор, штатное расписание), писать адекватные должностные инструкции для каждой позиции и, главное, - сформировать систему постановки задач и приёмки результатов. Когда обязанности работника достаточно конкретно определены в матрице, а уже конкретные служебные задания ставятся руководством (сегодня он пишет модуль "Коленный сустав", а завтра занимается отладкой модуля "Сердце" - и всё это зафиксировано), доказать, что конкретная программа была создана как служебная, значительно проще.

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

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

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

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

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

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

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

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

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

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

47 <ul><li>в договоре об отчуждении исключительных прав речь идёт об уже существующем объекте;</li>

48 <li>в договоре подряда - о работе по созданию неких сущностей, не являющихся объектами интеллектуальной собственности;</li>

49 <li>в договоре об оказании услуг - о потреблении услуги (но не объекта) непосредственно в момент её оказания.</li>

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

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

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

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

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

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

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