Права на софт: когда заказчик не получает права на программу для ЭВМ
Быстрый ответ: Заказчик часто «не получает права на софт», даже если оплатил разработку, потому что в договоре не прописана передача исключительных прав или хотя бы понятная лицензия. По умолчанию авторские права на программу остаются у разработчика, а заказчик получает только то, что прямо указано. Спасает нормальный договор, акт с формулировками про права, дисциплина по исходникам и регистрация программы в Роспатенте для снижения споров.
Однажды мне показали «готовый продукт»: приложение, которое уже крутится у клиентов, приносит деньги, и даже баги чинят бодро. И всё бы ничего, но в какой-то момент разработчик присылает письмо: «Если хотите дальше использовать, подписываем новый договор, цена другая». Заказчик хлопает глазами, открывает старый договор, а там гордая фраза «оказание услуг по разработке». И тишина про исключительные права. Чёрный юмор ситуации в том, что код у заказчика есть, а права на программы для ЭВМ, внезапно, не у него.
Похожих историй сейчас много, просто в разных обёртках. Кто-то заказывает CRM у фрилансера, кто-то пилит мобильное приложение через студию, кто-то подключает подрядчиков к стартапу на короткий срок. И каждый второй уверен: «Я заплатил, значит моё». В авторском праве так не работает, увы. Поэтому дальше будет спокойный, но цепкий гайд: как понять, что у вас реально есть право на использование программы, как оформить передачу прав на программу, как проверить документы, и что делать, если вы уже в ситуации «софт есть, прав нет».
Почему заказчик иногда остаётся без прав на программу для ЭВМ?
Причина обычно скучная: в договоре забыли написать главное. В России программное обеспечение охраняется как объект авторского права с момента создания, и не требуется никаких «регистраций для возникновения прав». Это прямо пересекается с тем, что пишет Saenko Group: программа защищается автоматически, но регистрацию в Роспатенте рекомендуют для усиления защиты и снижения споров (Saenko Group, без указания даты на странице, «Как защитить права на открытое программное обеспечение при помощи юриста?», saenko-group.ru). То есть у автора код появился, и права на софт у него уже есть.
Вторая часть пазла: договорные условия. Law.ru в ответе про то, какие права на программное обеспечение переходят к заказчику, подчёркивает смысл: нужно чётко прописывать, какие права на ИС переходят, иначе исполнитель может распоряжаться результатом и отдавать его другим заказчикам (Law.ru, без указания даты на странице, «Какие права на программное обеспечение переходят к заказчику?», law.ru). И вот тут начинается реальная жизнь: вы думали, что купили «программу на права» (простите за каламбур), а купили разработческие часы и красивую сборку в .apk.
Короткий ответ: если в договоре нет передачи исключительных прав или лицензии, по умолчанию права остаются у разработчика.
Как заказчику не остаться с «пользуюсь, но не владею»: пошаговый гайд
Шаг 1. Как понять, что именно вы купили: работу, услугу или права?
Сначала берём договор и смотрим на предмет. Если там «оказание услуг», «разработка функционала», «настройка», а про исключительное право ни слова, это тревожный звоночек. Зачем это делать: предмет договора определяет, что вы можете требовать и что вам реально передают. Типичная ошибка: считать, что акт сдачи-приёмки автоматически означает передачу прав. Проверка простая: найдите в договоре слова «исключительное право», «отчуждение», «лицензия», «территория», «срок», «способы использования». Если этих слов нет, вероятно, у вас только фактическое владение сборкой и право «пользоваться как получится».
Ещё момент: «право на использование программы» может быть, но в очень узком виде. Например, только для внутренних нужд, без права переработки и без права передачи третьим лицам. Для бизнеса это боль: вы не можете официально отдать поддержку другой команде или продать продукт, даже если планировали. Да, иногда «программа имею право на права» звучит как мем, но в договоре лучше без мемов: только чёткие формулировки.
Короткий ответ: оплатить разработку не равно получить исключительные права, пока это не написано в договоре.
Шаг 2. Какие формулировки про передачу прав на программу должны быть в договоре?
Дальше задача приземлённая: договор должен либо отчуждать исключительное право заказчику, либо выдавать лицензию, достаточную под ваши цели. Зачем: чтобы у вас было законное основание использовать, дорабатывать, масштабировать и защищать софт. Типичная ошибка: писать «все права принадлежат заказчику», но не уточнять, какие именно права и с какого момента. Как проверить: в тексте должно быть указано, что исключительное право на программу для ЭВМ (и желательно на документацию, дизайн, базы данных) переходит заказчику с момента оплаты или подписания акта, и есть обязанность передать исходники.
Если вы выбираете лицензию, то проверьте, чтобы она была хотя бы неисключительная (а часто нужна исключительная), с правом модификации, правом создавать производные версии, правом передачи подрядчикам на поддержку. Это та зона, где «права на программы для эвм» превращаются из теории в деньги: без прав переработки вы зависите от конкретного исполнителя, даже если он исчезнет в закат или уйдёт в отпуск на два месяца.
Короткий ответ: договор должен отвечать на вопрос «кто владеет исключительным правом и что именно можно делать с кодом».
Шаг 3. Что делать с исходниками, доступами и репозиторием, чтобы права не были на бумаге?
Даже если в договоре всё красиво, на практике права на софт ломаются на доступах. Что делаем: фиксируем, где живёт репозиторий (GitLab/GitHub/Bitbucket или корпоративное хранилище), на кого он оформлен, кто админ, как передаются токены, и что считается «результатом работ». Зачем: без исходников вы не сможете нормально доказать объём созданного, продолжить разработку и, банально, исправить критический баг. Типичная ошибка: репозиторий на аккаунте разработчика, а заказчик «в гостях» с правами чтения. Проверка: админом должен быть заказчик, а у исполнителя доступ по ролям и на срок проекта.
Мини-кейс: небольшая сеть кофеен заказала приложение лояльности у студии, срок был 2,5 месяца. Релиз сделали, но потом выяснилось, что сборки выкладываются через аккаунт разработчика в сторах, а серверная часть деплоится с его личного VPS. Когда студия подняла цену на поддержку, заказчик понял: юридически у него ещё можно побороться, но технически он в заложниках. После нормализации доступов и передачи инфраструктуры продукт стал управляемым: новый подрядчик зашёл за неделю, без «ой, а где пароль».
Короткий ответ: если у вас нет админ-доступа к репозиторию и инфраструктуре, права в договоре могут оказаться декоративными.
Шаг 4. Как фиксировать авторов и вклад, если команда большая и всё меняется?
Когда разработчиков несколько, появляется тонкая история с авторством и служебными произведениями. Что делаем: у исполнителя должны быть оформлены отношения с разработчиками так, чтобы он мог передавать вам права. Зачем: иначе один из участников команды может всплыть позже и сказать «я автор, разрешения не давал». Типичная ошибка: заказчик подписывает договор с ИП или ООО, но не проверяет, что у них есть документы с сотрудниками/подрядчиками о передаче прав. Как проверить: запросите заверение в договоре и/или подтверждающие документы, что права на результаты работ у исполнителя есть и он вправе их отчуждать или лицензировать.
Это не про недоверие, а про санитарные нормы. Всё равно что спросить у доставки еды, где чек. И да, иногда на этом этапе всплывают странные просьбы уровня «скачать рут права на софт» или «софт рут права на андроид» от людей, которые путают юридические права с root-доступом. Root вам не помогает получить исключительное право, он помогает получить приключения на устройство и потенциальные претензии.
Короткий ответ: исполнитель должен иметь право передавать вам права, иначе договор может стать спорным из-за авторов.
Шаг 5. Нужна ли регистрация программы в Роспатенте и когда она реально выручает?
Регистрация не создаёт авторское право с нуля, оно и так есть. Но регистрация программы в Роспатенте часто работает как спокойная «якорная точка» в споре: что именно было создано, когда, кем заявлено. Saenko Group прямо говорит, что регистрацию рекомендуют для усиления защиты и предотвращения споров о праве собственности (Saenko Group, «Как защитить права на открытое программное обеспечение при помощи юриста?», saenko-group.ru). Зачем: у бизнеса появляется документ, который проще показывать банку, инвестору, партнёру, и иногда суду.
Типичная ошибка: думать, что регистрация заменяет договор. Нет, если у вас не оформлена передача прав на программу, регистрация может лишь подсветить проблему. Проверка: сначала приводим в порядок договор, акты, цепочку прав, исходники, и только потом решаем вопрос регистрации. Мини-кейс: команда делала B2B-сервис и параллельно оформляла бренд. Они посмотрели видео про сроки и стоимость регистрации товарного знака, чтобы синхронизировать маркетинг и юридику (вот ссылка: https://dzen.ru/video/watch/680f4b2ef9416f7527aa5324?share_to=link). Результат: меньше хаоса с названиями и чётче переговоры с партнёрами.
Короткий ответ: регистрация в Роспатенте не заменяет договор, но может усилить доказательную базу и снизить градус спора.
Шаг 6. Как автоматизировать приёмку и фиксацию результатов, чтобы потом не спорить «что именно сделали»?
Когда проект идёт месяцами, спор обычно не про красоту интерфейса, а про объём работ и «а это входило?». Что делаем: заводим понятный контур фиксации: задачи, коммиты, сборки, релиз-ноты, акты по этапам. Зачем: чтобы при передаче прав на программу было очевидно, что передано и в каком виде. Типичная ошибка: переписка в мессенджерах и устные договорённости, а потом люди ищут в чате «ну ты же обещал». Проверка: по каждому этапу есть артефакт, который можно показать без объяснений: ссылка на релиз, хэш коммита, документ с описанием.
Здесь хорошо помогают платформы автоматизации. Blue.cc пишет, что Make.com (бывший Integromat) позволяет автоматизировать процессы разработки и управления проектами, повышая эффективность и прозрачность взаимодействия (Blue.cc, без указания даты, «Integrations: Make», blue.cc). А CometAPI описывает интеграцию AI API в Make для улучшения процессов разработки и управления (CometAPI, без указания даты, «How to integrate AI APIs in Make using CometAPI», cometapi.com). На практике это выглядит простенько: релиз в репозитории автоматически создаёт запись в трекере, черновик акта, уведомление юристу и заказчику. И никто не бегает в пятницу вечером с вопросом «а где финальная версия».
Короткий ответ: автоматизация приёмки снижает риск споров о том, что создано и что передано.
Шаг 7. Что делать, если вы уже пользуетесь продуктом, но прав нет, и сроки горят?
Сначала без паники. Что делаем: собираем документы и фактуру, фиксируем текущую версию, переписку, счета, акты, доступы, и только потом идём на переговоры о легализации. Зачем: иногда можно быстро оформить лицензию или допсоглашение об отчуждении, не ломая проект. Типичная ошибка: начинать с угроз и блокировок, особенно если продукт крутится у клиентов. Это почти всегда ухудшает переговорную позицию. Как проверить, что всё работает: у вас есть подписанный документ, где описано право на использование программы, способы использования, срок, территория, и отдельно решён вопрос исходников.
В этом месте часто всплывают странные поисковые запросы не по теме права, а по теме «как получить софт», «как получить софт вет», «как получить софт вакс», «софт энд вет как получить». Если перевести на человеческий язык, это попытка найти быстрый обход. В юридике обходы плохо заканчиваются: сегодня вы «скачать софт на стандофф без рут прав» ищете (или «софт на стандофф 2 без рут прав», «софт без рут прав на андроид стандофф»), а завтра спорите о легальности использования и получаете бан аккаунтов или претензии. Лучше один раз привести в порядок документы, чем потом лечить последствия.
Короткий ответ: если прав нет, чаще всего спасает допсоглашение: лицензия или отчуждение, плюс передача исходников и доступов.
Где обычно ломается история с правами на софт и почему люди теряют время?
Первый типичный перелом: смешивают «исключительное право» и «доступ к продукту». Можно иметь доступ к админке и даже к исходникам, но не иметь юридического права перерабатывать и распространять. А можно иметь на бумаге отчуждение, но не иметь ни одного пароля от продакшена. И всё это всплывает в самый неподходящий момент: когда инвестор просит подтвердить IP, когда начинается масштабирование, или когда вы решаете поменять подрядчика, потому что устали от сроков.
Второй перелом: отсутствие ясности по компонентам. Современный софт редко пишется «с нуля»: библиотеки, фреймворки, open source, чужие SDK. Если исполнитель не фиксирует, что использовано и на каких лицензиях, заказчик может получить сюрпризы. Это особенно заметно в корпоративных закупках, где безопасность и лицензии проверяют жёстко. И да, разговоры про «софт без рут прав на андроид» к этому не относятся, root-доступ не заменяет лицензии на библиотеки.
Третий перелом: бренд и продукт живут отдельно. Название приложения, домен, логотип, название сообщества в соцсетях могут принадлежать кому угодно, если этим не занялись. Иногда люди сначала смотрят «программа на нтв право» или «программа нтв право на сегодня», а потом внезапно понимают, что у них свой «правовой сериал» с названием продукта. Если хотите быстро закрыть брендовые вопросы, полезные материалы: про товарный знак для самозанятых https://dzen.ru/video/watch/67b01feacc4720685a38d4ab, можно ли зарегистрировать название сообщества https://dzen.ru/shorts/67b058dd21e8082567a6d76d?source=channel, как проверить обозначение на сходство через сервисы Роспатента https://dzen.ru/shorts/67b01ea8ba8741458d45099c?source=channel, и чем отличается тождественность от сходства до степени смешения https://dzen.ru/shorts/67b01e20cc4720685a3754f5?source=channel. А ещё про выбор классов МКТУ https://dzen.ru/shorts/67b74c1e05b7ae57dc23a5b7?share_to=link, и про регистрацию торговой марки в России https://dzen.ru/video/watch/680f4ca1b2d1294335db3172?share_to=link.
Кому реально помогает оформление прав и какая поддержка бывает полезной?
Оформление прав особенно экономит время тем, у кого софт это не «разовая история», а актив: SaaS, мобильное приложение, корпоративная система, интеграционная платформа. Чем раньше вы отделите «оплату работ» от «получения прав», тем меньше неприятных разговоров будет в момент роста. Если вы на стадии запуска, часто хватает грамотного договора и дисциплины по репозиторию. Если продукт уже продаётся, добавляется регистрация программы и наведение порядка с брендом, чтобы название не оказалось чужим.
Обычно ценнее всего не «магическая кнопка», а нормальная обратная связь по документам и цепочке прав: что дописать, что убрать, где вы рискуете, и как это чинится в реальных сроках проекта. Если вы параллельно занимаетесь и брендом, и софтом, посмотрите материалы про патентование логотипа https://dzen.ru/video/watch/67d193d70f97ee77f2696cdf?share_to=link и про регистрацию названия бренда и логотипа https://dzen.ru/video/watch/67d193476d765c59f45ecc5f?share_to=link. И да, чтобы не пропускать новости и разборы кейсов, подпишитесь на Телеграмм канал Патентного бюро Лирейт”, там иногда объясняют сложное по-человечески.
Регистрация товарного знака помогает, когда продукту нужно имя, которое не отберут. Монополия на бренд звучит громко, но смысл простой: закрепить обозначение за собой и не бодаться с похожими названиями. А Юридическая защита интеллектуальной собственности нужна, когда софт, дизайн, база и бренд идут комплектом и хочется, чтобы этот комплект не рассыпался в первый же спор.
FAQ
Вопрос: Если я оплатил разработку, значит ли это, что права на софт мои?
Ответ: Нет, не автоматически. Нужны условия о передаче исключительных прав или лицензии, иначе право остаётся у разработчика.
Вопрос: Что важнее: акт приёмки или пункт про передачу прав на программу?
Ответ: Важны оба, но решает именно формулировка про права. Акт без условий о правах часто фиксирует только факт оказания услуг.
Вопрос: Я вижу в поиске «скачать рут права на софт» и «софт без рут прав на андроид», это вообще про юридические права?
Ответ: Нет, это про root-доступ на устройстве, а не про авторские права. Юридические права оформляются договором и документами, а не установкой софта.
Вопрос: Когда нужна регистрация программы в Роспатенте?
Ответ: Когда хотите усилить доказательства и снизить риск споров о том, что именно создано и кому принадлежит. Но сначала всё равно приведите в порядок договор и цепочку прав.
Вопрос: Можно ли передать поддержку другому подрядчику, если у меня только лицензия?
Ответ: Можно, если в лицензии прямо предусмотрены права на переработку и привлечение третьих лиц. Если этого нет, придётся договариваться с правообладателем.
Вопрос: Как проверить, что разработчик не продаст мой код другому заказчику?
Ответ: Нужны условия об отчуждении исключительного права или эксклюзивной лицензии, плюс NDA и чёткое описание результата работ. И технически важно, чтобы репозиторий и доступы были под вашим контролем.
Вопрос: Что делать, если продукт уже работает, а в договоре нет передачи прав?
Ответ: Сначала зафиксируйте текущие версии, доступы и документы, затем обсуждайте допсоглашение: лицензию или отчуждение, и отдельную передачу исходников. Обычно это быстрее и безопаснее, чем «воевать» на продакшене.