Права на софт: как защитить программные модули, разработанные подрядчиками
Самая популярная сцена в моём рабочем чате выглядит так: предприниматель присылает архив с кодом и пишет «это наш модуль, нам его подрядчик сделал», а через пару сообщений выясняется, что «наш» он только в том смысле, что за него заплатили. Исходники лежат на GitHub подрядчика, доступы уволенному тимлиду не отозвали, в договоре слово «исключительные» встречается только в фразе «исключительные случаи задержки оплаты». И вот здесь у людей впервые щёлкает: права на софт это не про «мы же оплатили», а про то, что именно вам разрешено делать с результатом разработки.
Иногда конфликт не драматичный, а тихий и вязкий. Например, вы запускаете продукт, находите инвестора, начинаете due diligence, и внезапно юристы спрашивают: «А у вас цепочка прав на программные модули чистая?» Вы в ответ: «Ну, подрядчик же всё сделал». На практике это звучит примерно как «мне знакомый электрик проводку делал, наверное, нормально». Ирония в том, что для судов и проверок важны не ощущения, а бумага, переписка, акты и то, как вы управляли доступом. Да, авторские права на ПО в России возникают автоматически с момента создания, но это никак не означает, что они автоматически перетекают к заказчику, если код писали не ваши сотрудники.
Зачем вообще заморачиваться и что получится после
Если вы дочитаете до конца, у вас сложится понятная схема: как договариваться с подрядчиком до начала работ, как фиксировать создание модулей по ходу, как забирать исходники и доступы без нервного тика, как оформлять права на использование сторонних библиотек и «кусочков», и когда имеет смысл регистрация программы в Роспатенте как дополнительная опора, если запахло спором. Я пишу это как Эльвира Габдрахманова, человек, который слишком часто видел, как «права доступа на модуль» путают с правами на сам модуль, а потом пытаются лечить это срочной допсоглашением в пятницу вечером.
Пошаговый гайд: что делать, чтобы права на софт не утекли
Шаг 1. Сначала честно ответить себе: подрядчик пишет «под вас» или «для себя, но вам тоже»
Действие простое, но неприятное: вы открываете договор и переписку и пытаетесь понять, что на самом деле происходит. Подрядчик может делать уникальный код под ваш проект, а может собирать продукт из своих заготовок, оставляя себе ядро, а вам выдавая «обвязку». Зачем это понимать: от этого зависит формулировка про исключительные права, лицензии, доработки и то, сможете ли вы завтра сменить команду разработки без шантажа «без нас оно не соберётся».
Типичная ошибка тут: считать, что раз вы оплатили работы, то права на софт уже у вас. В российской реальности оплата сама по себе не равна переходу исключительных прав, если это не прописано. Проверка, что всё работает, тоже приземлённая: попросите подрядчика письменно подтвердить, какие компоненты принадлежат ему, какие третьим лицам, а какие передаются вам. Не устно в созвоне, а в письме или в приложении к договору. Когда человек начинает юлить, это уже сигнал, что внутри есть «серые» куски.
Шаг 2. Перепрошить договор: не «создание сайта», а «передача исключительных прав на результаты»
Что делаем: добавляем в договор понятные формулировки о том, что именно создаётся (программные модули, исходный код, документация, тесты), и что исключительные права на созданное переходят к заказчику. Параллельно фиксируем территорию и срок, хотя для исключительных прав это обычно не про ограничения, а про аккуратность формулировок. Зачем: без этого вы можете получить «право пользования», но не право переработки, не право передавать дальше, не право интегрировать в другой продукт.
Типичная ошибка: писать общую фразу «все права принадлежат заказчику» без деталей, актов и указания, что именно является результатом. В споре такая фраза иногда звучит красиво, но разваливается, когда надо доказать, что конкретный модуль и конкретная версия действительно были переданы. Проверка: в договоре должны быть этапы и акты приёмки с перечислением модулей и версий, а в приложении список репозиториев, доступов, артефактов сборки. И да, слово «исключительных» должно быть не декоративным.
Шаг 3. Настроить «железное» получение исходников и контроль репозитория
Действие: репозиторий должен быть вашим или хотя бы зеркалироваться на вашу сторону с первого дня. Я обычно прошу клиентов не стесняться: доступы к GitLab/GitHub, права администратора, ключи CI/CD, секреты и переменные окружения должны быть под контролем компании, а не у подрядчика «в личном аккаунте». Зачем: модуль без истории коммитов, без пайплайна сборки и без ключей часто превращается в коробку с проводами, которую никто не может включить.
Типичная ошибка: принять результат «в виде архива на почте», а потом обнаружить, что половина зависимостей подтягивалась из приватных репозиториев подрядчика, и вы легально и технически отрезаны. Проверка: берёте чистую машину или отдельный контур, поднимаете проект по инструкции и убеждаетесь, что сборка воспроизводится без участия подрядчика. Если невозможно собрать, значит вы приняли не результат, а обещание результата.
Шаг 4. Развести «права доступа на модуль» и права на сам модуль
Тут многие спотыкаются. «Права доступа на модуль» это про то, кто может нажать кнопку, кто видит админку, кто имеет право на доступ си модуля в системе, если у вас, скажем, микросервисная архитектура и раздельные роли. А права на софт это про интеллектуальную собственность: кто может законно копировать код, менять, распространять, продавать лицензии, встраивать в другой продукт. Зачем разделять: можно выдать разработчику доступ к продакшену и при этом не отдавать ему никаких прав на ваш код. И наоборот, можно купить исключительные права и всё равно провалиться, если доступы к инфраструктуре остались у чужой команды.
Типичная ошибка: пытаться лечить отсутствие прав на код тем, что вы «снимете доступы». Это не лечит. Проверка: у вас должны быть отдельные документы и настройки. Внутри компании это обычно матрица доступов и регламенты, а с подрядчиком это условия договора и акт передачи результатов. Если вы сейчас не можете одним письмом объяснить, кто владеет модулем, а кто просто имеет доступ, значит всё перемешано.
Шаг 5. Проверить сторонние компоненты: библиотеки, фреймворки, антивирусные модули
Действие: просите у подрядчика ведомость зависимостей и лицензий. Особенно внимательно к компонентам, которые кажутся «невинными»: кусок шифрования, SDK для платежей, какой-нибудь «модуль антивируса». Отдельная боль: право на использование модуля антивируса может быть ограничено лицензией вендора, и ваш подрядчик мог поставить «как у себя», а вы потом обнаружите, что в коммерческом продукте это так нельзя или надо докупить лицензии.
Типичная ошибка: думать, что опенсорс это «можно всё». Не всегда. Проверка: минимально вы смотрите лицензии основных библиотек и наличие проприетарных компонентов. Плюс в договоре должно быть условие, что подрядчик гарантирует законность использования третьих лиц и отвечает, если он притащит что-то, что нельзя использовать в вашем сценарии. Это звучит строго, но иначе крайним будете вы.
Шаг 6. Зафиксировать авторство и дату: регистрация ПО в Роспатенте как «страховочный якорь»
Что делаем: когда модуль стабилизировался и понятна версия, можно подать на регистрацию программы для ЭВМ в Роспатент. По закону авторские права возникают автоматически, регистрация не обязательна, но в спорных ситуациях она даёт удобное доказательство, что на определённую дату у вас был такой-то объект. Зачем: в реальных конфликтах люди спорят не о философии, а о том, кто что создал и когда, и кому что передали.
Типичная ошибка: регистрировать «что-нибудь» на ранней стадии, когда через две недели код будет другим, а модуль распилен на три сервиса. Проверка: у вас есть финальный пакет материалов, который соответствует тому, что реально используется, и оформленные отношения с подрядчиком, чтобы не получилось, что вы регистрируете то, на что не получили права. Это тот самый момент, когда лучше потратить пару дней на порядок, чем потом месяцами переписываться через юристов.
Шаг 7. Включить техническую защиту там, где это уместно: подписи, шифрование, ключи HASP
Действие: если вы распространяете ПО как продукт (особенно в B2B), подумайте о технических средствах защиты, например аппаратных ключах HASP, цифровых подписях, шифровании конфигураций и управлении лицензиями. Зачем: договор и регистрация помогают в споре, но не мешают человеку прямо сейчас скопировать сборку и «поставить соседям». Техническая защита не делает вас непобедимыми, но сильно усложняет жизнь тем, кто любит «позаимствовать».
Типичная ошибка: пытаться защититься только техникой, игнорируя юридическую часть. Это как ставить дорогую дверь в картонный дом. Проверка: у вас есть связка, где юридически определено, кому и на каких условиях предоставляется доступ и лицензия, и технически ограничено исполнение. И ещё: не пытайтесь превращать защиту в паранойю, иначе пострадают ваши же пользователи и саппорт.
Мини-кейсы из практики, без героизма
Первый кейс был у небольшого маркетплейса из Казани. Команда из трёх человек заказала подрядчику модуль рекомендаций и ранжирования, сроки горели, релиз через месяц. В договоре были работы, но не было передачи исключительных прав, и подрядчик честно считал модуль своей «коробкой», которую он сдаёт в аренду. Мы быстро (за неделю, но было тяжко) перевели отношения в понятный формат: допсоглашение, акт с перечнем результатов, зеркалирование репозитория в аккаунт клиента, плюс ведомость зависимостей. Эффект не магический, но очень практичный: продукт смог спокойно нанять другого разработчика на поддержку, не выпрашивая доступы и не опасаясь, что завтра им скажут «плати ещё, иначе отключим».
Второй кейс был у ИП, который делал мобильное приложение и заказал подрядчику несколько SDK-интеграций. Там всплыло странное: часть кода была скопирована из старого проекта подрядчика, где у третьей компании были ограничения на использование. Мы не занимались «разборками», просто вычистили проблемный кусок, переписали модуль и отдельно закрепили в договоре ответственность за легальность сторонних компонентов. Проверка была простая: сборка на чистом контуре, исходники у заказчика, и закрытые зависимости заменены на публичные или лицензированные.
Третий кейс, почти бытовой: компания автоматизировала внутренний документооборот и подключила подрядчика «на подхват». После конфликта подрядчик удалил доступы и пригрозил, что модуль, который он писал, принадлежит ему. Мы подняли переписку, акты, выгрузили историю коммитов и оформили нормальные документы задним числом (я сначала подумала, что не получится, но получилось, потому что фактура сохранилась). И да, с тех пор у клиента правило: никаких «личных аккаунтов» для корпоративных репозиториев. Казалось бы, мелочь, а экономит месяцы жизни.
Подводные камни, где чаще всего всё ломается
Самая коварная точка это смешение ролей. Сегодня подрядчик «как свой», завтра он уже «чужой», а вы не помните, кому принадлежат права на софт и где лежат исходники. И тут всплывают странные запросы из интернета вроде «скачать рут права на софт» или «софт рут права на андроид». Люди путают рут-права на телефоне и юридические права на код. По-хорошему, эти миры вообще не должны пересекаться, но в реальности пересекаются в головах, и из-за этого компании иногда пытаются решать юридическую проблему настройками доступа или, наоборот, юридическими бумажками лечить отсутствие админских прав к инфраструктуре.
Ещё одна зона риска это «модули под железо». Ко мне пару раз приходили с вопросами в стиле «на лыжный модуль мотобуксировщик нужны права» или «нужны ли права на гусеничный модуль снежок». Смешно, но логика похожая: если модуль это часть устройства или софта для устройства, важно понимать, кто автор, кто изготовитель, и на каком основании вы можете производить, продавать и модифицировать. В софте то же самое: модуль может быть маленьким, но критичным. Потеряли права на него, и всё, продукт зависим от одного человека, который может уехать, устать, обидеться или просто повысить цену.
И да, «софт на стандофф без рут прав», «софт на стандофф 2 без рут прав», «софт без рут прав на андроид», «софт без рут прав на андроид стандофф», «скачать софт на стандофф без рут прав», «софт на стендофф без рут прав», «софт на стендофф 2 без рут прав» это отдельная интернет-реальность, которая к законной защите модулей отношения не имеет. Я аккуратно скажу так: если вы занимаетесь бизнес-разработкой, держитесь от серых историй подальше. Они потом всплывают в переговорах и проверках самым неприятным образом, и объяснять становится сложнее, чем написать модуль заново.
Где поддержка реально экономит время
Юристы по интеллектуальной собственности полезны не тем, что «угрожают судом», а тем, что помогают выстроить понятную цепочку прав без героизма. Когда у вас несколько подрядчиков, мобильная разработка плюс бэкенд, плюс дизайнеры, плюс сторонние библиотеки, легко потерять нить. Иногда достаточно один раз собрать документы и шаблоны: договор с передачей исключительных прав, приложение с составом результатов, порядок приёмки, правила по доступам. Если у вас есть бренд и продукт, параллельно обычно всплывают и другие задачи, например Регистрация товарного знака или история про Монополия на бренд, потому что всё это в итоге про контроль над тем, что вы создаёте и продаёте.
Если вам ближе формат «быстро спросить и не утонуть в терминах», иногда спасает нормальная обратная связь в процессе, когда договор правится до подписания, а не после конфликта. По вопросам юридической упаковки разработки и вообще по теме Юридическая защита интеллектуальной собственности можно хотя бы держать руку на пульсе и смотреть, что меняется в практике. Хотите защитить свою интеллектуальную собственность, быть в курсе всех новостей? Подпишитесь на наш Telegram-канал. И да, отдельно напомню, чтобы не потерялось: Телеграмм канал Патентного бюро Лирейт».
FAQ
Вопрос: Если подрядчик написал код, а мы оплатили, права на софт автоматически наши?
Ответ: Не автоматически. Авторские права возникают у автора с момента создания, а переход исключительных прав к заказчику должен быть закреплён договором и актами. Оплата подтверждает факт работ, но сама по себе не всегда подтверждает переход прав.
Вопрос: Нужно ли регистрировать программу в Роспатенте, чтобы защитить её?
Ответ: Нет, защита авторским правом есть и без регистрации. Но регистрация программы для ЭВМ в Роспатенте может быть удобной как дополнительное доказательство существования объекта на конкретную дату, особенно если намечается спор.
Вопрос: Чем «права доступа на модуль» отличаются от прав на сам модуль?
Ответ: Права доступа это про администрирование и роли в системе: кто может зайти, менять настройки, деплоить. Права на модуль это интеллектуальная собственность: кто может копировать код, перерабатывать, распространять и разрешать использование другим.
Вопрос: Что обязательно забрать у подрядчика при сдаче модулей?
Ответ: Исходники, историю репозитория, инструкции по сборке и развертыванию, доступы/ключи к CI/CD и инфраструктуре в рамках согласованной модели, а также акт приёмки с перечнем модулей и версий. И ещё полезно получить ведомость зависимостей и лицензий.
Вопрос: Если в модуле использованы сторонние библиотеки, это риск?
Ответ: Это нормально, но важно понимать лицензии и условия использования. Риск начинается, когда подрядчик тянет проприетарные компоненты без разрешения или приносит «наследованный» код из чужого проекта. Тогда отвечать часто приходится заказчику.
Вопрос: Помогают ли технические средства защиты, например аппаратные ключи HASP?
Ответ: Могут помочь как часть общей защиты: усложняют несанкционированное копирование и использование. Но они не заменяют юридическое оформление прав и не решают проблему, если права изначально не переданы или документы оформлены криво.
Вопрос: Можно ли оставить права подрядчику, а себе взять только лицензию?
Ответ: Можно, это рабочая модель, если вам подходит зависимость от подрядчика и условия лицензии. Тогда важно чётко прописать объём прав: на какой срок, на какую территорию, можно ли дорабатывать, можно ли передавать третьим лицам, что происходит при расторжении договора.