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