Право на софт: передача прав на обновления и модификации программы
Один из самых странных разговоров в моей практике начался так: «Эльвира, мы купили право на софт, а обновления нам теперь продают отдельно. Это вообще законно или нас разводят?» И вот ты сидишь, смотришь в договор, а там аккуратно написано: «предоставляется право использования версии X». Про обновления ни слова. И вроде никто не обманул, но ощущение такое, будто купили билет на поезд, а потом выяснилось, что сиденье и багаж оплачиваются отдельно.
Ещё веселее становится, когда в команде есть разработчик, который привык «да я сам поправлю». Он лезет в код, делает модификацию, выкатывает патч, и внезапно выясняется, что право на обновление программного обеспечения у вас не оформлено, а изменения юридически принадлежат не тем, кто их оплатил. На бумаге это выглядит скучно, а в жизни заканчивается нервными переписками, сорванными релизами и попытками срочно найти «документы на обновление прав» хоть в каком-то виде.
Зачем вообще разбираться, кому принадлежат обновления
После этого текста вы сможете спокойно проверить: что именно вы купили или продали, где в договоре спрятаны права на обновление, кто владеет модификациями и как передать эти права без фокусов. Я буду говорить про российские реалии и про то, что в РФ действительно работает: исключительное право у автора или правообладателя, передача имущественных прав по договору, и вечная власть лицензионных условий, которые многие пролистывают быстрее, чем мемы в телеге.
Пошаговый гайд: как передавать права на обновления и модификации
Шаг 1. Отделяем «версию» от «обновлений», иначе будет сюрприз
Сначала фиксируем, что такое «программа», а что такое «обновление» и «модификация». В договорах часто пишут «ПО», и всё, точка. Но в жизни обновления бывают разные: багфикс, мажорная версия, патч безопасности, новая платформа, новый модуль. Зачем это делать? Чтобы у вас появилось поле для переговоров: можно купить право на софт и отдельно согласовать права на обновление программы, включая сроки и объём. Типичная ошибка тут простая: думать, что обновления «по умолчанию входят». Не входят, если это не написано. Проверка: в договоре должны быть слова про обновления и их статус, а ещё желательно указание, включена ли техническая поддержка и на каких условиях она выпускает новые версии.
И да, отдельная боль у корпоративных клиентов: «права на обновление 1с» или «права на обновление windows» часто живут в отдельной логике поставки, где у вас не “купили навсегда”, а “есть право получать обновления, пока действует подписка”. Это нормально, но только если вы это осознали до оплаты, а не когда бухгалтерия закрывает квартал.
Шаг 2. Понимаем, что у кого: исключительное право, лицензия и «а можно мы поменяем код?»
По российскому праву исключительное право на программу для ЭВМ принадлежит автору или правообладателю, и включает в том числе модификацию и распространение. Это важный момент: модификация не «вне закона», она просто должна быть разрешена. Что делаем на практике: определяем, вы передаёте исключительное право целиком или выдаёте лицензию на использование. Если вы заказчик и хотите, чтобы ваши доработки принадлежали вам, это надо отдельно закрепить. Типичная ошибка: заключить договор разработки, но не прописать переход прав, а потом удивляться, что подрядчик вправе использовать тот же код где-то ещё. Проверка: ищем в тексте договора блок про исключительные права и права на переработку (модификацию), а также про право создавать производные версии.
Иногда мне показывают «лицензия на право обновления программного обеспечения» отдельным документом, и это хорошо, если он не противоречит основному договору. А то бывает, что основной договор запрещает любые изменения, а приложение обещает «модификации по заявкам». Потом стороны спорят, какой документ главнее. Спойлер: суду обычно не нравится бардак.
Шаг 3. Закрепляем, кому принадлежат обновления, которые сделали за ваш счёт
Дальше самое «денежное»: если вы оплачиваете разработку обновлений, кому они принадлежат? Делать нужно прямо: прописать режим прав на результаты доработок, патчей, новых модулей, документации. Зачем: иначе у вас обновление есть, а юридически права на него остаются у исполнителя, и вы не можете нормально передать продукт инвестору, продать бизнес или даже просто сменить подрядчика. Типичная ошибка: ограничиться фразой «исполнитель обязуется обновлять ПО», без указания, что создаваемые обновления передаются заказчику. Проверка: в договоре должна быть понятная формулировка о переходе исключительных прав на конкретные результаты работ или о предоставлении лицензии на обновления на нужных вам условиях.
Мини-кейс из недавнего: у клиента был небольшой SaaS для логистики, разработка на аутсорсе, релизы каждые две недели. Через полгода захотели сменить команду: старые ребята подняли цену и начали тормозить. В договоре оказалась лицензия только на использование текущей версии. На доработки прав нет. Пришлось экстренно подписывать допсоглашение, иначе новая команда не могла легально продолжать модификацию. Потеряли примерно месяц и часть доверия пользователей. Никакой драмы на публику, но внутри было «приятно».
Шаг 4. Приводим в порядок лицензии сторонних компонентов, иначе обновление станет миной
Если в вашей программе есть сторонние библиотеки, фреймворки или куски кода, обновления и модификации могут упереться в их лицензии. Особенно это видно, когда продукт растёт, команда меняется, и внезапно выясняется, что половина проекта на компонентах с несовместимыми условиями. Исследования прямо показывают, что проблемы несовместимости лицензий встречаются часто (в одном из обзоров на arXiv фигурирует 72,91% проектов с такими рисками). Что делаем: поднимаем список компонентов и их лицензий, проверяем, можно ли их использовать в коммерческом продукте, можно ли модифицировать и распространять. Типичная ошибка: «это же просто пакет из репозитория». Проверка: у вас должен быть внутренний реестр компонентов, а в договоре с подрядчиком, если он разрабатывает, обязанность передать список и гарантировать соблюдение лицензий.
Да, это тот скучный кусок, из-за которого релиз иногда переносится на неделю. Но лучше неделя сейчас, чем потом объяснять контрагенту, почему вы не можете передать ему права на модуль, потому что внутри чужая лицензия с сюрпризом.
Шаг 5. Строим понятный режим «получать обновления»: сроки, каналы, поддержка
Права на обновление это не магия и не абонемент «на всё хорошее». Это либо обязанность поставщика выпускать обновления, либо ваше право получать их на определённых условиях, либо подписка. Что делаем: прописываем в договоре период, порядок поставки (репозиторий, личный кабинет, акт, релиз-ноты), что считается обновлением, что считается новой версией, и как принимается результат. Типичная ошибка: не определять критерии готовности и безопасность, а потом спорить, считается ли «подняли версию библиотеки» обновлением или «это же мелочь». Проверка: у вас есть SLA или хотя бы договорные сроки, и понятный механизм приемки, чтобы не спорить в стиле «оно же работает у меня на ноуте».
Кстати, отдельная ветка запросов, которые ко мне прилетают из интернета, звучит смешно и грустно: «скачать рут права на софт», «софт рут права на андроид», «софт без рут прав на андроид», «софты на стандофф без рут прав», «софт на стандофф 2 без рут прав», «софт без рут прав на андроид стандофф», «софт на оксайд без рут прав», «софт на стендофф без рут права», «софт на стендов без рут прав». С юридической точки зрения это не про «права на обновление программы», а про попытки обойти ограничения и ковырять чужой продукт. В деловых договорах такие истории лучше даже не приближать к вашему бренду, чтобы потом не объяснять, что вы вообще хотели сказать.
Шаг 6. Документируем модификации так, чтобы их можно было передать и защитить
Дальше включаем дисциплину. При модификации ПО ведём документацию: что изменили, кто сделал, на основании какой задачи, где исходники, какие права переданы. Это особенно важно, если у вас несколько подрядчиков или разработчики меняются каждые полгода. Зачем: когда вы передаёте права на обновления новому владельцу продукта или новому подрядчику, без истории изменений всё превращается в археологию. Типичная ошибка: хранить всё «в переписке» и в головах. Проверка: у вас есть репозиторий, история коммитов, доступы, и в договоре закреплено, что результаты передаются вместе с исходниками и документацией, а не только «собранным файлом».
Мини-кейс: агентство делало мобильное приложение для сети кофеен, обновления выходили перед сезонными акциями. Когда маркетинг попросил «быстро добавить оплату по QR», выяснилось, что часть кода писалась на личных аккаунтах, и формально компания не могла доказать передачу прав на эти куски. Переоформили доступы, собрали акты передачи, сделали допник. Две недели, море раздражения, но дальше обновления пошли спокойнее.
Шаг 7. Если передаёте бизнес или продукт, отдельно оформляйте «пакет обновлений»
Продажа проекта, вход инвестора, передача продукта внутри группы компаний часто ломаются на мелочи: права на софт передали, а право на обновление программного обеспечения осталось у старой компании, потому что подписка оформлена на неё, доступы в кабинет на её почту, а договор поддержки на её ИНН. Что делаем: собираем отдельный пакет документов, где указано, что переходят права по лицензиям, доступы, договоры сопровождения, и кто оплачивает дальнейшие обновления. Типичная ошибка: думать, что «акта передачи исключительных прав достаточно». Иногда достаточно, иногда нет. Проверка: после сделки новый владелец реально может скачать обновления, получить поддержку и законно заказывать модификации.
И тут забавная деталь: люди иногда путают «обновление прав на вождение» и «права на обновление». В запросах встречается и «обновление прав на вождение 2026», и «документы на обновление прав». Это вообще из другой оперы, но я понимаю, почему поисковики всё мешают в одну кастрюлю. В договорах на ПО такую кашу лучше не допускать: терминология должна быть железной, иначе спор будет выглядеть как переписка на кухне после полуночи.
Подводные камни: где чаще всего всё ломается
Первый классический провал это когда лицензионное соглашение живёт отдельно от «договорённостей в чате». В чате обещали обновления «в течение года», а в договоре указано право использования текущей версии без обязательств по дальнейшим релизам. Суд и экспертизы чат уважают не всегда так, как хотелось бы, и вы в итоге платите дважды: сначала за разработку, потом за «восстановление отношений» с поставщиком. Я не фанат драм, но это как раз тот случай, когда одна строчка про права на обновление программы стоит дешевле, чем один день простоя сервиса.
Второй подводный камень это модификации силами заказчика без права на переработку. Люди искренне думают: «мы же купили, значит можем чинить». Нет. Купили право использования на условиях лицензии, и если переработка запрещена, то любое «подкрутили, чтобы работало» формально нарушение. Иногда правообладатель закрывает глаза, иногда нет, особенно если вы потом выносите модифицированную версию на рынок или показываете её партнёрам. Проверяйте, что в лицензии разрешено: модифицировать, адаптировать, интегрировать, передавать третьим лицам. Если этого нет, лучше договориться и оформить, чем играть в прятки.
Третий момент почти бытовой: доступы. У вас может быть право на обновление программного обеспечения на бумаге, но доступ к репозиторию, кабинету, ключам подписан на личную почту бывшего сотрудника. И он не злодей, просто уехал в отпуск и не отвечает. В итоге вы зависите не от права, а от пароля. Предусмотрите корпоративные аккаунты, порядок передачи доступов и ответственность за их удержание, иначе любой релиз превращается в квест.
Где оформление интеллектуальной собственности реально экономит время
Если вы регулярно платите за доработки, ведёте продукт в подписке, меняете подрядчиков или готовитесь к сделке, оформление прав на ПО и отдельное закрепление прав на обновление обычно окупаются временем и нервами. Не «в смысле денег обязательно вернётся», а в смысле вы не будете каждую итерацию начинать с вопроса: «а мы вообще можем это делать?». Форматы поддержки бывают разные: кто-то приносит черновик договора на 3 страницы, и мы просто доводим формулировки; кто-то приходит с пачкой документов и просит собрать нормальную конструкцию с передачей прав и режимом обновлений. Самое ценное тут даже не бумага, а когда вам объясняют человеческим языком, что именно вы покупаете.
Если хотите, можно заглядывать в Телеграмм канал Патентного бюро Лирейт», я там часто комментирую такие «скользкие» ситуации без занудства, с примерами из переписок (обезличенно, конечно). И да, у нас есть ещё Канал в Максе Патентного бюро Лирейт», если вам удобнее читать там, где меньше шума. Иногда одна короткая заметка про лицензию спасает неделю работы, проверено на людях.
FAQ
Вопрос: «Права на обновление» это отдельное право или часть лицензии на программу?
Ответ: В реальной договорной жизни это обычно часть лицензии или отдельное условие о сопровождении: право получать обновления и обязанность поставщика их предоставлять. По умолчанию «право на софт» не гарантирует, что вам будут поставлять будущие версии, если это прямо не закреплено.
Вопрос: Можно ли передать другому лицу право получать обновления по нашей подписке?
Ответ: Иногда да, но зависит от условий лицензионного договора и правил поставщика. В договорах часто стоит запрет на уступку или требование согласия правообладателя. Проверьте раздел про уступку прав и передачу лицензии.
Вопрос: Чем отличается модификация от обновления в юридическом смысле?
Ответ: В быту обновление это то, что выпускает правообладатель. Модификация это переработка программы, которую может сделать и третье лицо, если разрешено. Юридически важно, чтобы лицензия разрешала переработку и определяла, кому принадлежат результаты.
Вопрос: Если мы оплатили доработку подрядчику, разве права на неё не переходят автоматически?
Ответ: Нет, автоматического перехода исключительных прав обычно не происходит без прямого условия в договоре. Надо прописывать передачу прав на результаты работ или выдачу лицензии на созданные обновления и модификации.
Вопрос: Что проверить в договоре, чтобы не потерять право на обновление программного обеспечения?
Ответ: Ищите: определение обновлений, срок и порядок предоставления, включена ли поддержка, что является новой версией, можно ли устанавливать обновления на несколько устройств/серверов, и можно ли передавать лицензию внутри группы компаний или при продаже проекта.
Вопрос: Почему все говорят про несовместимость лицензий open source, это реально частая проблема?
Ответ: Да, она встречается регулярно, и исследования это подтверждают. Ошибка обычно в том, что компоненты добавляют быстро, а юридическую часть не ведут. Потом при передаче прав или при выпуске коммерческого релиза выясняется, что часть кода нельзя распространять на ваших условиях.
Вопрос: Мы видим запросы типа «скачать рут права на софт» или «софт без рут прав на андроид», это вообще про интеллектуальную собственность?
Ответ: Это скорее про попытки обойти ограничения устройства или программ, и к легальной передаче прав на обновления отношения почти не имеет. Если вы бизнес и развиваете продукт, лучше держаться в зоне чистых лицензий и понятных договоров, чтобы потом не объяснять партнёрам происхождение «модификаций».