Право на софт при увольнении разработчиков — защита прав на ПО без рисков
В один и тот же месяц у меня было два звонка с одинаковым сюжетом. В первом стартапчик на 12 человек «отпустил» ведущего разработчика, а через неделю внезапно выяснил, что доступы к репозиторию завязаны на его личную почту, часть задач в трекере закрыта «на честном слове», а на проде крутится модуль, который, по словам бывшего сотрудника, «вообще-то мой». Во втором случае разработчик ушёл из студии игр, и спустя пару месяцев на его GitHub всплыл похожий код. Не один в один, но достаточно, чтобы юристы напряглись и начали задавать неприятные вопросы про права разработчика и авторское право разработчика.
Увольнение в ИТ часто воспринимают как бытовуху: отдал ноут, подписал обходной, написал «спасибо команде» в чате. Но право на софт так не работает. Код не исчезает вместе с доступом в офис, а споры о том, кому принадлежат права разработчиков игр или права разработчика приложений, почему-то всегда начинаются ровно тогда, когда продукт уже приносит деньги и стало «обидно». И да, иногда всё это всплывает в суде: в 2021 году было 266 судебных актов по защите авторских прав на программы для ЭВМ, и в 45,12% случаев требования удовлетворяли полностью или частично. Это не «страшилка», это статистика, которую я держу в голове, когда кто-то говорит: «Да у нас всё на доверии».
Ниже я разложу процесс как практичный гайд: что именно оформлять до увольнения и в день расставания, чтобы право на софт не превращалось в лотерею. В итоге у вас будет понятная цепочка документов и фактов: что написано, кем создано, по чьему заданию, на каких условиях и где это подтверждено. Это помогает и работодателю, и разработчику: первому не бояться, что «уехал мозг проекта», второму не сидеть с ощущением, что у него тихо «отжали» портфолио.
Пошаговый гайд: как зафиксировать право на софт при увольнении
Шаг 1. Поднимите договоры и проверьте, что там вообще сказано про права
Первое, что делаем, это достаём трудовой договор, допсоглашения, оффер, внутренние положения и всё, что похоже на договорённости. Зачем: по п. 2 ст. 1295 ГК РФ исключительное право на служебное произведение обычно принадлежит работодателю, если договором не предусмотрено иное. То есть закон уже на стороне компании, но только если вы реально можете показать, что это служебное произведение, а не «пет-проект, который случайно оказался в проде». Типичная ошибка: думать, что одной фразы «всё, созданное в период работы, принадлежит работодателю» достаточно. Иногда достаточно, иногда нет, особенно если обязанности в трудовом описаны как «разработка иные поручения», а фактически человек делал архитектуру продукта и писал ключевые модули без формализации.
Как проверить, что всё работает: в документах должно быть внятно прописано, что входит в трудовую функцию, какие результаты интеллектуальной деятельности создаются, и что происходит с исключительными правами. Если формулировки кривые, я бы хотя бы зафиксировала текущую позицию сторон отдельным соглашением при увольнении. Да, звучит не романтично, но потом меньше поводов выяснять отношения через письма с темой «досудебная претензия».
Шаг 2. Привяжите код к служебным заданиям, а не к «ну он же работал»
Дальше включаем скучный режим: документируем служебные задания и поручения. Зачем: когда возникает спор, суду и юристам важны не ваши внутренние ощущения, а связка «задача выдана, результат получен, это часть работы». Типичная ошибка: всё держать в переписке в мессенджере или в голосовых в Telegram, а потом удивляться, что «оно не считается». Переписка может помочь, но куда сильнее, когда есть оформленные задания, пусть даже в виде письма или записи в трекере, но с понятными атрибутами: кто поставил, когда, что принять как результат.
Как проверить: у вас есть история задач (в Jira, YouTrack, Redmine, хоть в Trello), и по ключевым фичам можно поднять, кто их делал и по какому поручению. Мини-кейс из жизни: в интернет-магазине на Bitrix один разработчик «собрал» модуль интеграции со службой доставки за четыре дня и ушёл через месяц. Компания думала, что это мелочь и ничего не оформляла. Когда модуль начали продавать как отдельное решение партнёрам, бывший сотрудник заявил, что это его разработка и он не давал согласия. Спасло то, что в трекере лежала цепочка задач с приемкой от тимлида и привязкой к рабочему времени. Не идеально, но это был якорь.
Шаг 3. Разделите личное и рабочее, пока это ещё не стало драмой
Третий шаг для тех, кто любит «таскать с собой» куски кода: разграничьте личные и служебные проекты. Зачем: иначе вы легко попадаете в серую зону, где непонятно, чья библиотека, чей шаблон, чей «скелет» приложения. Типичная ошибка разработчика: использовать свой старый код, не сказав об этом, а потом считать, что у него автоматически остаются права разработчика программ на этот фрагмент. Типичная ошибка работодателя: молча поощрять это, а потом пытаться «забрать всё целиком», включая то, что человек написал до трудоустройства.
Как проверить: посмотрите репозитории, зависимости, README, историю коммитов и лицензии сторонних библиотек. Если в коде есть куски из личного репо, лучше честно описать их статус в соглашении: либо сотрудник передаёт права, либо предоставляет лицензию, либо компания отказывается от использования. Да, это неприятный разговор. Но он всё равно случится, просто позже и намного злее.
Шаг 4. В день увольнения зафиксируйте передачу: не только ноут, но и права, доступы, артефакты
Четвёртый шаг самый «больной», потому что он про момент, когда все уже устали и хотят разойтись. Что делаем: оформляем акт приема-передачи того, что реально важно для жизни продукта. Зачем: чтобы потом не спорить, что именно было передано, а что «оно лежало у меня локально и я забыл». Типичная ошибка: ограничиться актом на материальные вещи и не закрепить результаты работы: исходники, сборки, документацию, ключи, доступы, токены, админки, рабочие аккаунты. И отдельно фиксируем, что результаты, созданные как служебные, остаются у работодателя, если договором не предусмотрено иное.
Как проверить: доступы сменены, права доступа пересмотрены, репозитории и CI/CD не завязаны на личные аккаунты. Ещё одна проверка, которую я люблю: попросите тимлида или DevOps сделать «холодный запуск» по инструкции, как будто разработчика никогда не было. Если сборка не воспроизводится, значит, вы не передали часть знания, а это тоже риск, пусть и не всегда юридический.
Шаг 5. Если были подрядчики и фриланс, не путайте их с «нашими» по умолчанию
Иногда увольняется сотрудник, а вместе с ним выясняется, что кусок проекта писал фрилансер «по знакомству» и скидывал архивы в личку. Зачем выношу это отдельным шагом: потому что служебные произведения по ст. 1295 ГК РФ это про трудовые отношения, а подряд это другая история. Типичная ошибка: считать, что если разработчик в штате прикрутил код подрядчика, то исключительные права автоматически оказались у компании. Не всегда. Нужно, чтобы договор с подрядчиком содержал условия о переходе прав или лицензии, иначе можно получить сюрприз.
Как проверить: на каждый внешний кусок кода должны быть документы, где понятно, что компания вправе это использовать, дорабатывать и распространять. Мини-кейс: студия делала мобильное приложение, и часть UI-анимаций отдали знакомому на «быстро и недорого». Через полгода продукт вышел в сторы, а автор анимаций попросил доплату и пригрозил запретом использования. Разрулили переговорами, но проще было бы сразу закрыть вопрос документом, а не надеждой на адекватность людей (она, кстати, не всегда в комплекте).
Шаг 6. Не забудьте про внутреннюю «гигиену»: подписи, архивы, переписки
Шестой шаг кажется мелким, но он решает половину нервов. Что делаем: приводим в порядок электронные документы, используем электронные подписи там, где это принято в компании, и сохраняем ключевые переписки и артефакты разработки. Зачем: компании всё чаще проводят аудит прав на программное обеспечение, и когда нет следов, начинается охота на привидений. Типичная ошибка: хранить доказательства в личных чатах и на личной почте, а потом терять доступ или историю. Ещё хуже, когда руководитель просит «удали переписку, чтобы не светить», а потом сам же ищет подтверждения, что задание было служебным. Ирония судьбы, да.
Как проверить: у вас есть централизованный архив документов и понятный доступ к нему, а также фиксируются версии ТЗ, дизайна, исходников и релизов. Если спор всё же случится, именно эти «скучные файлы» могут сыграть решающую роль. Напомню ещё одну цифру: в первой половине 2022 года было 86 судебных актов по делам о защите авторских прав на программы для ЭВМ, и там 36,05% удовлетворили, а 45,34% отклонили. Разница иногда в том, есть ли у стороны доказательства, а не в том, кто громче возмущался.
Шаг 7. Не мешайте в одну кучу «права разработчика» и бытовые запросы из Android-сообщества
Седьмой шаг звучит странно, но я правда с этим сталкивалась: люди гуглят «права разработчика», и поисковик приносит им инструкции уровня «включить права разработчика» на телефоне. В правовом контексте права разработчика программного обеспечения это про интеллектуальные права, договоры, служебные произведения, а «права разработчика на андроид» часто означает просто режим в настройках телефона. Типичная ошибка: обсуждать с командой «как получить права разработчика», имея в виду юридические права, а в переписке кто-то кидает ссылку на Android-мануал. Смешно первые пять минут, потом грустно, когда выясняется, что ни трудовая функция, ни переход прав не описаны вообще.
Как проверить: если у вас в документах есть ясные формулировки про исключительные права, авторство, порядок приемки и передачи результатов, значит вы на правильной дорожке. А если у вас в корпоративной базе знаний рядом с политикой по IP лежит «софт рут права на андроид» и «софт без рут прав на андроид», то… возможно, вам надо развести по папкам хотя бы смыслы. И да, я вижу, как в запросах всплывает «софт на стандофф без рут прав», «софт на стандофф 2 без рут прав», «скачать софт на стандофф без рут прав», «софт на стендофф без рут прав», «софт на стендофф 2 без рут прав», «софт без рут прав на андроид стандофф», «скачать рут права на софт». К юридической теме увольнений и право на софт это не имеет отношения, и я не помогу с обходами и «скачать». Но сам факт путаницы полезно помнить: когда сотрудник пишет «права разработчика», уточняйте, он про Android-меню или про интеллектуальные права.
Подводные камни: где чаще всего всё ломается
Первое место, где люди теряют время, это иллюзия, что служебность очевидна. Она очевидна вам, потому что вы платили зарплату. Но если у разработчика гибридный график, часть задач обсуждали устно, а код он коммитил по ночам со своего ноутбука, потом внезапно появляется простор для фантазии: «я сделал это вне работы», «это мой наработанный фреймворк», «вы вообще не ставили задачу». И каждый из этих тезисов придётся опровергать доказательствами, а не интонацией. Поэтому служебные задания и приемка результата это не бюрократия ради бюрократии, это страховка от будущих переписываний истории.
Второй камень это «серые» доступы и личные аккаунты. Репозиторий на личном GitHub, домен оформлен на физлицо, аккаунт в облаке на бывшего DevOps, админка в аналитике на корпоративной почте, которую уже отключили. Юридически вы можете быть правы, но технически у вас нет контроля, а значит нет возможности нормально пользоваться своим же софтом. И тут начинается странный торг: бывший сотрудник «поможет восстановить», если вы заплатите, или если «по-хорошему». Мне не нравится этот стиль отношений, но он возникает именно там, где компания не отделила активы от персоналий.
Третий камень это попытка решить всё одним документом на выходе. На практике это работает хуже, чем кажется. Когда человек увольняется, он уже эмоционально вне команды, и любые бумаги про «передачу прав» воспринимаются как недоверие или попытка прижать. Лучше, когда базовые правила игры были подписаны раньше, а при увольнении вы просто фиксируете факт передачи и закрываете хвосты. Не идеально, да. Но намного спокойнее, чем «подпиши сейчас, иначе трудовую не отдадим» (так делать нельзя, и это быстро превращает обычное увольнение в конфликт).
Кому реально помогает оформление прав и поддержка юристов
Я обычно советую не геройствовать тем, у кого продукт живой: приложения, игры, SaaS, внутренние системы, которые потом внезапно начинают продавать наружу. Там права разработчиков игр и права разработчика приложений всплывают в самый неподходящий момент, например когда инвестор просит due diligence или когда партнёр хочет лицензионный договор. Юрист, который умеет в интеллектуальную собственность, полезен не потому, что он напишет «страшный» договор, а потому что он заставит вас связать людей, задачи и код в одну доказуемую картину.
Если вам ближе человеческий формат, чем «судебная перспектива на 12 страниц», иногда хватает консультации, правки трудовых и проектных документов, и нормальной схемы приема-передачи при увольнении. Хотите держать руку на пульсе по интеллектуальной собственности и не пропускать новости, подпишитесь на Телеграмм канал Патентного бюро Лирейт». А если нужен более широкий контур, у ребят есть Юридическая защита интеллектуальной собственности, плюс отдельные направления вроде Регистрация товарного знака и Монополия на бренд, когда у софта появляется имя, которое тоже хочется защитить.
FAQ
Вопрос: Кому принадлежит исключительное право на код, который разработчик написал в компании?
Ответ: Обычно работодателю, если код является служебным произведением и договором не предусмотрено иное. В российском праве это прямо закреплено, в том числе в п. 2 ст. 1295 ГК РФ. Но «обычно» не равно «всегда», важны обязанности, задания и доказательства создания в рамках работы.
Вопрос: Если разработчик уволился, может ли он использовать тот же код в новом проекте?
Ответ: Если код служебный и исключительные права у работодателя, то использовать его без разрешения нельзя. На практике чаще спорят не о самом правиле, а о том, был ли код действительно служебным и что именно было создано в компании.
Вопрос: Что важнее при увольнении: акт на технику или акт на результаты разработки?
Ответ: Оба, но многие забывают про результаты разработки. Передача ноутбука не подтверждает передачу исходников, документации, ключей, доступов и правомерности использования конкретных модулей. Если есть акт приема-передачи по проекту, споров обычно меньше.
Вопрос: У нас всё в Jira и Git, этого достаточно, чтобы защитить софт?
Ответ: Это хороший фундамент, но не магия. Важно, чтобы задачи были связаны с поручениями, была приемка результата, и чтобы доступы и история коммитов сохранялись. Если документы о правах и трудовой функции отсутствуют, одних трекеров может не хватить.
Вопрос: «Права разработчика» это то, что нужно включить на Android, или это про интеллектуальные права?
Ответ: Это две разные вселенные. «Включить права разработчика» на Android это режим в настройках телефона. А права разработчика программ, права разработчика программного обеспечения и авторское право разработчика это про юридические права на код и условия их перехода.
Вопрос: В поиске вижу запросы про «софт на стандофф без рут прав» и «скачать рут права на софт». Это связано с правами на ПО при увольнении?
Ответ: Нет, это другая тема из Android-сообщества и вокруг игр, не про юридическое право на софт. При увольнении обсуждают служебные произведения, договоры, передачу прав и доказательства создания, а не «рут» и не «скачать».
Вопрос: Нужно ли регистрировать программу для ЭВМ, чтобы доказать право на софт?
Ответ: Авторское право возникает с момента создания, регистрация не обязательна. Но иногда регистрация и правильный пакет документов помогают проще подтверждать авторство и состав программы, особенно когда в команде была текучка и продукт менялся быстро.