Права на ПО при смене команды: кому принадлежит код и как защитить права
Быстрый ответ: При смене команды главное быстро выяснить, кому принадлежат права на ПО и на каких условиях можно использовать код. Если разработка шла по трудовому договору, права обычно у работодателя, но нужны корректные формулировки и документы. С подрядчиками права переходят по договору и актам. Защита прав на ПО держится на договорах, фиксации авторства, NDA и, при необходимости, регистрации в Роспатенте.
Однажды мне написали в пятницу вечером: «Эльвира, у нас половина команды ушла, а релиз в понедельник. Код чей?». И вот ты сидишь, смотришь на репозиторий, где коммиты бодрые, а документы грустные. В таск-трекере все красиво: дедлайны, статусы, «починил авторизацию». А в юридической части тишина, как в серверной ночью. И именно в такие моменты становится понятно, что права собственности на ПО это не абстрактная история, а вопрос, почему продукт вообще можно продолжать развивать.
Смена команды почти всегда приносит «подарки»: уволились ключевые разработчики, подрядчик перестал выходить на связь, новый тимлид спрашивает «а лицензии на библиотеки у нас какие?», и внезапно всплывает вопрос по передачи прав. Самое неприятное, что спор о праве на использование ПО может разгореться не сразу. Сначала все просто чинят баги, потом начинают спорить о доступах, а затем приходит письмо: «Запретите использовать мой код». Черный юмор тут в том, что код в этот момент уже в проде.
После этого гайда у вас будет понятная дорожная карта: как проверить, кому принадлежат права на ПО, что попросить у HR и бухгалтерии, какие документы собрать у подрядчиков, как оформить передачу прав по договору без странных формулировок, и что можно сделать для защиты прав на ПО, чтобы потом не бегать по судам с распечатками коммитов. Плюс покажу, где люди чаще всего «роняют» доказательства и как это починить без паники.
Почему при смене команды вопрос «кому принадлежит код» всплывает первым?
Потому что смена команды это смена контроля: меняются люди, доступы, иногда даже собственники бизнеса. И если права на ПО не зафиксированы, продукт превращается в чемодан без ручки: тащить тяжело, бросить страшно. Классическая картина: старый разработчик унес ноутбук, доступы в Git были на его личной почте, а договор с ним был «просто трудовой, без деталей». В этот момент юридический статус кода становится важнее, чем очередной хотфикс.
Краткий ответ: Если вы не можете быстро показать, на каком основании используете код, вы теряете время и переговорную позицию при любом конфликте.
Какие права на ПО вообще надо держать в голове, чтобы не запутаться?
В реальности вам нужно понимать три слоя. Первый: авторство (кто создал код). Второй: кто владеет исключительным правом, то есть кому принадлежат права собственности на ПО и кто решает, как его использовать. Третий: лицензии и разрешения на компоненты, которые вы подключили, потому что чужие библиотеки тоже умеют «кусаться». Когда говорят «по праву на объекты», обычно имеют в виду, что продукт состоит из множества объектов: код, дизайн, документация, база данных, название, логотип, домен.
Краткий ответ: Автор и правообладатель это не всегда один и тот же человек, и на этом ломается половина споров.
Как пошагово оформить права на ПО при смене команды без нервного тика?
Шаг 1: Как быстро провести инвентаризацию кода и документов, пока все не разъехались?
Сначала соберите «карту продукта»: где репозиторий, какие ветки живые, где CI/CD, кто админит облака, где хранятся ключи, и какие люди делали вклад. Это не про контроль ради контроля, а про доказательства и управляемость. Зачем: если завтра кто-то скажет «я автор этого модуля», вам нужно хотя бы понимать, о каком модуле речь и в каком коммите он появился. Типичная ошибка: делать инвентаризацию по памяти тимлида, а потом обнаружить еще один репозиторий «на всякий случай», который и есть прод.
Как проверить, что все работает: доступы должны быть оформлены на компанию, а не на личные аккаунты, и должен существовать список репозиториев и сервисов с ответственными. Мини-кейс: у финтех-стартапа из Казани новый CTO за два дня собрал таблицу доступов и обнаружил, что ключевая часть биллинга лежит в закрытом репо подрядчика. Пара звонков, один акт, и стало легче дышать. Но если бы они узнали об этом через полгода, переговоры были бы совсем другие.
Краткий ответ: Инвентаризация это ваш быстрый способ понять, что именно нужно защищать и у кого спрашивать документы.
Шаг 2: Как понять, считается ли код «служебным», если его писал сотрудник?
Если код написан сотрудником в рамках трудовых обязанностей, права обычно у работодателя. Но «обычно» не равно «автоматически без бумажек». Важно, чтобы трудовой договор или должностная инструкция закрепляли создание результатов интеллектуальной деятельности и переход прав. Это прямо отмечают в материале CNews: «Если код был написан в рамках трудовых обязанностей, права на него принадлежат работодателю. Однако… необходимо, чтобы трудовой договор или должностная инструкция содержали соответствующие положения» (CNews.ru, статья «Особенности перехода права от разработчика?», дата публикации на странице источника).
Зачем шаг: при смене команды бывшие сотрудники часто вспоминают о своем вкладе. Типичная ошибка: считать, что одна фраза «занимается разработкой ПО» в трудовом договоре закрывает все. Как проверить: попросите у HR копии трудового договора, должностной инструкции и внутренних документов о постановке задач. Если есть корпоративная почта и таск-трекер с задачами, это тоже помогает. И да, «право на труд по» тут не про лозунги, а про то, что трудовые отношения задают юридическую рамку владения результатом.
Краткий ответ: Для служебного кода решают формулировки в трудовых документах и связь разработки с обязанностями сотрудника.
Шаг 3: Что делать, если код писали фрилансеры и подрядчики, а договор «на коленке»?
С подрядчиками мир проще и жестче одновременно. Проще, потому что все держится на договоре и акте. Жестче, потому что если договор молчит о передаче прав на ПО, вы можете получить только право пользоваться результатом в узких рамках или вообще спорную ситуацию. В блоге WCR Consulting отмечают: «Права на код, созданный по договору подряда, переходят к заказчику с момента приемки и полной оплаты работы, если иное не предусмотрено договором» (WCR-Consulting.com, материал «How to Protect Software from Copying: License and Agreement?», 07.10.2025).
Зачем шаг: при смене команды подрядчики любят «вспоминать», что передача прав по договору не была оформлена, и просить доплату. Типичная ошибка: подписать акт приемки без пункта про исключительные права и без конкретики по составу результата. Как проверить: поднимите договор, ТЗ, переписку, счета и акты. Если актов нет, это не конец света, но придется задним числом фиксировать приемку и передачу права использования ПО, аккуратно и без творчества. Если нужно расширить права, делайте отдельное соглашение о передаче прав и обязанностей по договору, чтобы не было двусмысленности.
Краткий ответ: Подрядчик не «передал права устно», пока это не отражено в договоре и закрывающих документах.
Шаг 4: Как оформить совместную разработку, чтобы соавторы не стали вашим сюрпризом?
Совместная разработка звучит дружелюбно, но юридически это минное поле. Если несколько человек создают код вместе, права могут принадлежать соавторам совместно, и тогда любое использование становится вопросом согласований. NRIS об этом пишет прямо: «При совместной разработке… права на код принадлежат соавторам совместно. Важно заранее определить долю каждого соавтора и условия использования кода» (NRIS.ru, блог «Как защитить права при совместной разработке программного обеспечения?», дата публикации на странице источника).
Зачем шаг: смена команды часто означает, что один из соавторов уходит, а вы продолжаете развивать продукт. Типичная ошибка: думать, что «раз работали в одном чате, значит компания владеет всем». Как проверить: есть ли соглашение между соавторами или документы, по которым исключительное право передано компании. Мини-кейс: команда из Новосибирска делала внутренний сервис, а потом решила вывести его в отдельный продукт. Один из разработчиков был на полставки и без четкого соглашения. Договорились быстро, но только потому, что сохранились письма с согласованием условий и они оперативно подписали допсоглашение.
Краткий ответ: Если у кода несколько авторов, лучше заранее зафиксировать, кто и на каких условиях может его использовать.
Шаг 5: Как документировать передачу прав на ПО, чтобы это не было «бумага ради бумаги»?
Документирование звучит скучно, но оно спасает, когда люди меняются. Нужны акты, спецификации, ссылки на репозитории, перечень модулей, даты, и понятное описание результата. Зачем: иначе любая передача права использования ПО превращается в спор «а мы это имели в виду или другое?». Типичная ошибка: акт формата «услуги оказаны», без упоминания кода и передачи исключительных прав. Как проверить: по документам должно быть видно, что именно передано, за какое вознаграждение, и что у заказчика есть право на использование ПО и право вносить изменения.
Иногда всплывают странные запросы из серии «право на ребенка по» или «право на пенсию по» в одной папке с договорами. Это обычно следствие того, что бухгалтерия и юристы ведут архив как получится, и найти нужный акт сложнее, чем написать новый микросервис. Держите папку по продукту отдельно, с понятными названиями и версиями, и будет вам спокойнее. Если у вас есть сложные истории с наследниками или долями, это уже ближе к по оформлению наследственных прав и требует отдельной аккуратности, но в ИТ такое тоже встречается, если правообладатель физлицо.
Шаг 6: Нужна ли регистрация прав на ПО в Роспатенте и когда это реально помогает?
Регистрация программы для ЭВМ в Роспатенте не создает право с нуля, но дает сильную опору в доказательствах: дата, автор, правообладатель. Это особенно полезно, когда вы меняете команду, привлекаете инвестора или готовите сделку, и всем нужны ответы на вопросы по право, желательно короткие и проверяемые. На Legal Support прямо советуют рассмотреть регистрацию для подтверждения авторства и даты создания (Legal-support.ru, публикация «Судебная защита прав на программный код: как доказать, что нарушитель использовал модификацию кода?», дата публикации на странице источника).
Зачем шаг: если завтра возникнет спор о копировании, регистрация прав на ПО может упростить стартовую позицию. Типичная ошибка: думать, что регистрация заменяет договоры с разработчиками. Не заменяет. Как проверить: у вас должен быть комплект документов по правам плюс регистрационные материалы, чтобы они не противоречили друг другу. Мини-кейс: e-commerce команда из Москвы зарегистрировала программу перед входом в крупное партнерство. На переговорах это сэкономило недели, потому что контрагенту не пришлось разбираться в каждом подрядчике, они увидели понятный документ и дальше уже задавали нормальные вопросы про лицензии.
Краткий ответ: Регистрация полезна как доказательство, но она не лечит дырявые договоры и не заменяет передачу прав по договору.
Шаг 7: Как закрыть риски утечек и «уноса кода», пока команда меняется?
Пока вы оформляете бумаги, жизнь не останавливается. Нужны NDA, правила доступа, разграничение прав, и аккуратная процедура увольнения: сдача оборудования, отзыв токенов, смена паролей, ревизия ключей. WCR Consulting отдельно упоминают NDA как способ защиты конфиденциальной информации и предотвращения утечек кода (WCR-Consulting.com, «How to Protect Software from Copying: License and Agreement?», 07.10.2025). Зачем: самая дорогая утечка обычно происходит не из злобы, а из лени и хаоса.
Типичная ошибка: «мы доверяем людям» и один общий пароль на все. Потом новый разработчик случайно пушит в публичный репо конфиг, и начинается квест. Как проверить: логируйте доступы, включите 2FA, заведите корпоративные аккаунты, ограничьте права в проде, и держите процесс онбординга и оффбординга в одном месте. Это и есть защита прав на ПО в бытовом смысле: не только судиться, но и не давать унести продукт в кармане.
Какие подводные камни чаще всего рушат оформление прав на ПО?
Первый камень это «у нас все на доверии». Доверие прекрасно, пока не начинается спор, увольнение или продажа доли. Когда появляется инвестор или новый директор, внезапно требуется договор по оформлению права собственности, и выясняется, что половина кода писалась «по дружбе». Вторая проблема это смешение ролей: сотрудник днем работает в компании, а вечером как ИП делает «маленькую доработку» и выставляет счет. Юридически это разные режимы, и потом сложно объяснить, где служебное, а где подряд.
Третий камень это отсутствие связки между оплатой и правами. Оплатили работу, но не закрепили, что это именно передача прав на ПО или передача права использования ПО на нужных условиях. В результате заказчик уверен, что все купил, а исполнитель уверен, что продал «работу», но не права. Четвертый камень это попытка решить все одним универсальным шаблоном. Особенно опасны формулировки «передача прав по договору третьим возможна без согласия» или, наоборот, полный запрет, который потом мешает легальной передаче прав и обязанностей по договору при реорганизации.
И еще один нервный момент: если правообладатель физлицо и с ним что-то случилось, может всплыть передача прав по наследству. Тогда вы внезапно оказываетесь рядом с темами «рекомендации по оформлению наследственных прав» и «методические рекомендации по оформлению наследственных прав 2025», но уже в реальной жизни, где сроки горят. Лучше не доводить до этого и держать правообладателем компанию, а не конкретного разработчика, иначе потом придется договариваться с наследниками, которые к вашему продукту эмоционально относятся сильнее, чем вы ожидали.
Как поддержка юриста или патентного специалиста экономит время, если команда меняется?
Если у вас один разработчик и один договор, вы, скорее всего, справитесь сами. Но когда в проекте были сотрудники, ИП, студия дизайна, подрядчик по DevOps и еще кто-то «помогал с архитектурой», грамотное оформление по праву становится отдельной задачей. В таких случаях полезны услуги по передаче прав: проверить цепочку прав, привести договоры к единой логике, подготовить акты и формулировки, чтобы право на использование ПО не зависело от настроения бывшего исполнителя. Иногда это быстрее, чем спорить в переписке, кто что имел в виду год назад.
Если параллельно вы развиваете бренд, не забывайте, что кодом дело не заканчивается. Название, логотип, оформление тоже требуют защиты. Тут пригодятся материалы про регистрацию знаков: как зарегистрировать торговую марку в России, регистрация товарного знака: сроки и стоимость, а самозанятым полезно посмотреть требования и этапы регистрации товарного знака. По проверке обозначений выручает короткий разбор: как проверить на сходство через сервисы Роспатента и чем отличается тождественность от сходства до степени смешения. А еще бывает вопрос «можно ли зарегистрировать название сообщества», вот ссылка: про регистрацию названия сообщества как товарного знака. И классы МКТУ тоже важно выбрать с головой: как правильно выбрать классы МКТУ.
Если хотите держать руку на пульсе по практике и новостям, подпишитесь на Телеграмм канал Патентного бюро Лирейт». Там часто разбирают ситуации, когда права на ПО и бренд начинают конфликтовать уже на стадии переговоров или при смене команды. По услугам и направлениям: Регистрация товарного знака, Монополия на бренд, Юридическая защита интеллектуальной собственности.
FAQ
Вопрос: Кому принадлежат права на ПО, если разработчик уволился, а код остался в репозитории?
Ответ: Смотрите основание создания кода: трудовые обязанности, договор подряда или совместная разработка. Сам факт увольнения не меняет право, но без документов спор может затянуться.
Вопрос: Какие сроки важны при передаче прав на ПО по договору с подрядчиком?
Ответ: Критичны даты приемки и полной оплаты, потому что часто именно к ним привязывают переход прав. Проверьте, чтобы это было прямо написано и подтверждено актами.
Вопрос: Можно ли оформить передачу прав и обязанностей по договору, если компания реорганизуется?
Ответ: Да, но важно, чтобы договоры это допускали или вы подписали допсоглашения. Иначе передача прав по договору третьим может стать отдельным конфликтом.
Вопрос: Нужна ли регистрация прав на ПО, если у нас уже есть договоры с разработчиками?
Ответ: Регистрация не обязательна, но полезна как доказательство авторства и даты. Особенно когда меняется команда, инвестор или вы готовите сделку.
Вопрос: Что делать, если часть кода написана совместно и непонятны доли?
Ответ: Лучше зафиксировать соглашение: кто правообладатель, кто может использовать, кто получает вознаграждение. Без этого совместное владение легко превращается в запрет на любые изменения.
Вопрос: Как проверить, что защита прав на ПО реально работает, а не только на бумаге?
Ответ: Проверьте доступы, NDA, наличие актов и понятную цепочку прав от каждого автора к компании. Если за час можно собрать папку доказательств по продукту, вы в хорошей форме.