Права на ПО: как объяснить клиенту, что он покупает вместе с программой
Быстрый ответ: Клиент почти никогда не покупает «право собственности на ПО» целиком. Обычно он получает лицензию на ПО, то есть права на использование ПО в пределах договора: где ставить, сколько пользователей, можно ли обновляться, можно ли дорабатывать и кому передавать доступ. Объясняйте это простыми словами, показывайте ключевые пункты лицензии и фиксируйте их в счете, оферте или договоре, чтобы потом не спорить «а мы думали, нам всё можно».
Однажды мне написал заказчик в пятницу в 19:40: «Мы купили вашу программу. Пришлите, пожалуйста, исходники и право собственности на по, а то бухгалтерия просит». Пятница, дождь, кофе уже не помогает. И ты сидишь и думаешь: сейчас начнется разговор из серии «мы же заплатили, значит оно наше», а дальше по классике: “а можно поставить на 40 компьютеров?”, “а можно перепродать?”, “а можно поменять логотип и выдавать за свою разработку?”.
Смешнее всего, что люди не вредные. Они просто путают покупку коробки с покупкой прав. В рознице мы привыкли: заплатил, унес. В софте это почти никогда так не работает. И если вы заранее не разложили по полочкам права на по и права на использование по, конфликт возникает буквально из воздуха. Причем и клиент потом чувствует себя обманутым, и вы выглядите жадным, хотя речь всего лишь о границах лицензии.
После прочтения у вас появится понятный сценарий разговора: как объяснить, что именно покупают вместе с программой, как зафиксировать условия так, чтобы юристу потом не было стыдно, и как клиенту быстро проверить, что он использует ПО законно. Плюс расскажу, где чаще всего ломается коммуникация и почему слова из бухгалтерии типа «номер лицензии по» иногда вообще не про то, что вы продаете.
Почему клиент думает, что покупает право собственности на ПО, и что ему отвечать?
Потому что слово «купили» у нас в голове означает «стало моим». Но с программами чаще продают не вещь, а разрешение на использование. В вашем разговоре полезно прямо проговорить: «Вы покупаете лицензию на ПО, то есть право пользоваться программой на условиях договора, а исключительные права остаются у правообладателя». Это звучит сухо, но дальше можно перевести на человеческий: «как аренда, только для софта».
Короткий ответ: В большинстве сделок клиент получает лицензию, а не полную передачу исключительных прав. Поэтому «право собственности на по» в переписке чаще означает просто право законного использования.
Здесь важно не перегнуть палку и не начать читать лекцию про четвертую часть ГК РФ. Лучше задайте два вопроса: «Сколько людей будет пользоваться?» и «Нужно ли право модификации/доработки?». Клиент сам увидит, что права на использование по бывают разные. Типичная ошибка продавца: говорить «у нас стандартная лицензия», не объясняя, что в ней. Проверка простая: попросите клиента в ответ пересказать условия своими словами. Если пересказ совпал, значит всё работает.
Как объяснять права на ПО пошагово, без занудства и недомолвок?
Шаг 1. Как назвать сделку так, чтобы не родилась иллюзия «теперь это наше»?
Первое, что делаем, это убираем двусмысленность в формулировках. В счете, коммерческом предложении и письме используйте слова «лицензия на ПО» или «предоставление прав на использование ПО», а не просто «продажа программы». Зачем: клиент цепляется за слова, а потом несет их в бухгалтерию и руководителю. И вот уже «продажа» превращается в ожидание «передайте исходники и исключительные права».
Типичная ошибка: написать «передача ПО в собственность» (иногда это делает менеджер от души, иногда шаблон из прошлого века). Как проверить: откройте все точки касания, где фигурирует продукт, и убедитесь, что везде одна логика. Если где-то всплыло «право собственности на по», потом будет боль. Кстати, если клиенту нужны параллельно иные лицензии, вроде «лицензия на деятельность по» (это уже про лицензируемые виды деятельности), важно сразу развести понятия, чтобы не смешать теплое с мягким.
Короткий ответ: В документах и переписке называйте предмет сделки «лицензией», тогда ожидания клиента становятся адекватнее.
Шаг 2. Какие именно права на использование ПО клиент получает по умолчанию?
Второй шаг, это разложить права на по на простые куски: установка (на сколько устройств), доступ (сколько пользователей), территория (Россия или где угодно), срок (бессрочно или подписка), функциональные ограничения (модули, лимиты), обновления и техподдержка. Зачем: клиенту проще согласиться с понятной картой, чем с общими словами «вам предоставляется неисключительная лицензия». И да, иногда клиент спрашивает «по запросу право на получение чего именно? ключа? файла? доступа?». Хорошо, когда у вас это заранее описано.
Типичная ошибка: не проговорить срок. А срок это главный триггер конфликтов между бессрочной (perpetual) и подписочной (subscription) моделью. В найденной фактуре это прямо подчеркнуто: бессрочная лицензия дает право использования на неопределенный срок, а подписочная действует только в период оплаты. Как проверить: в договоре должна быть отдельная фраза про срок и порядок продления, а у клиента должен быть понятный счетчик, где он видит дату окончания подписки.
Короткий ответ: «Права на использование ПО» это не одно право, а набор условий: срок, пользователи, устройства, территория, обновления, поддержка.
Шаг 3. Как честно сказать про запреты: перепродажа, модификация, распространение?
Третий шаг самый неудобный, но лучше его пройти сразу. Лицензионные соглашения часто запрещают перепродажу, модификацию и распространение без разрешения правообладателя. Это не «жадность разработчика», а нормальная защита прав на по и способ удержать модель бизнеса от распада. Скажите прямо: «Перепродать лицензии нельзя, исходники не передаем, модификации только по отдельному согласованию». И объясните почему: иначе завтра ваш продукт окажется у конкурента под новым названием.
Типичная ошибка: стесняться и говорить туманно, а потом согласовывать в пожарном режиме, когда клиент уже «переупаковал» ваше решение под себя. Как проверить: в лицензии должны быть пункты про запрет декомпиляции, запрет распространения и порядок согласования доработок. Если клиенту критично дорабатывать, предложите отдельное соглашение: либо расширенная лицензия на право по (то есть на определенные способы использования), либо договор разработки с передачей результатов по правилам РФ.
Короткий ответ: Запреты в лицензии лучше озвучить заранее, иначе клиент узнает о них в момент конфликта.
Шаг 4. Как связать лицензию с оплатой: ключ, доступ, акт, оферта?
Четвертый шаг, это привязать права к событию оплаты и выдаче доступа. Клиенту важно понимать, что именно он получает «в руки»: ключ, аккаунт, ссылку на дистрибутив, токен, доступ в облако. Тут же всплывают запросы вроде «проверить по лицензии можно где?» или «у нас есть номер лицензии по, что с ним делать?». Если вы работаете с корпоративными заказчиками, им часто нужен понятный идентификатор: номер заказа, номер договора, номер лицензии, чтобы потом сверять установки и акты.
Типичная ошибка: выдать ключ без сопроводительных условий, а потом доказывать, что это была именно лицензия, а не «передали всё». Как проверить: отправляйте вместе с доступом копию лицензионного соглашения и короткое письмо с выжимкой условий. В фактуре это есть как рекомендация: «предоставить копию лицензионного соглашения и обсудить ключевые моменты, такие как срок лицензии, обновления и техническая поддержка». Источник: редакционный материал из предоставленного блока, без указания автора и даты, используется как справочная памятка для продавцов ПО.
Короткий ответ: Ключ или доступ без текста лицензии это приглашение к спорам; выдавайте их вместе и фиксируйте условия.
Шаг 5. Как объяснить «регистрацию прав на ПО» и не пообещать лишнего?
Пятый шаг, это аккуратно проговорить, что регистрация прав на по и защита прав на по не равны «мы поставим печать, и никто не украдет». В России права на программу для ЭВМ возникают с факта создания, но иногда нужна доказательная база и правильные документы. Клиенту полезно знать, что вы как правообладатель фиксируете авторство, версию, дату, и что у вас есть цепочка прав от разработчиков. Это сильно снижает тревожность, особенно у тех, кто покупает ПО для бизнеса и боится «проверки».
Типичная ошибка: говорить «у нас всё зарегистрировано», когда по факту только торговое название проверяли в поиске. Как проверить: у вас должны быть договоры с разработчиками, акты, внутренний реестр версий, а если заявляете о регистрации, то подтверждающие документы. Если параллельно вы защищаете бренд, полезно показать клиенту, что у названия/логотипа тоже есть стратегия. Для ориентира можно посмотреть видео «Как зарегистрировать торговую марку в России» https://dzen.ru/video/watch/680f4ca1b2d1294335db3172?share_to=link и ролик про сроки и стоимость регистрации https://dzen.ru/video/watch/680f4b2ef9416f7527aa5324?share_to=link.
Короткий ответ: Регистрация и документы не делают вас «неуязвимыми», но дают доказательства и экономят время в споре.
Шаг 6. Как разрулить «нам нужна лицензия по ИНН» и другие бухгалтерские формулировки?
Шестой шаг, это перевод с бухгалтерского на человеческий. Запрос «лицензия по инн» обычно означает: «дайте реквизиты и документ, чтобы провести платеж и показать проверяющим, что покупка легальна». Объясните: «ИНН относится к контрагенту, а лицензия на ПО описана в договоре/оферте и подтверждается актом или письмом о предоставлении прав». Если у вас SaaS, добавьте ссылку на условия и идентификатор аккаунта. Если коробка, добавьте серийный номер и контакты поддержки.
Типичная ошибка: начинать спорить «так не бывает». Бывает, просто люди называют привычными словами то, что им нужно для учета. Как проверить: попросите скрин требования из их внутреннего регламента или письма бухгалтера. Часто там видно, что нужен не «реестр лицензий по», а обычный комплект документов. И отдельно: если кто-то сравнивает покупку ПО с «такси по лицензии» или ищет «лицензия такси по номеру», мягко остановите: лицензирование перевозок и лицензионный договор на ПО юридически разные истории.
Короткий ответ: «Лицензия по ИНН» почти всегда означает просьбу о правильных закрывающих документах, а не про государственный реестр.
Шаг 7. Как встроить защиту бренда, чтобы клиент не нарвался на чужой товарный знак?
Седьмой шаг неожиданно важный: даже если вы продаете ПО, клиент может использовать ваше название в рекламе, на сайте, в соцсетях, в описаниях услуг. Если название не защищено, начинаются странные истории: претензии от третьих лиц, блокировки карточек, спор за домен. Тут к месту короткий ликбез про товарные знаки и проверки. Для самозанятых есть понятное видео «Узнайте, как зарегистрировать товарный знак для самозанятых: требования, этапы и советы экспертов» 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.
Короткий ответ: ПО продается по лицензии, а название и логотип лучше защищать отдельно, через товарный знак.
Какие мини-кейсы показывают, что объяснять права на ПО надо «на берегу»?
Кейс первый: небольшой автосервис в Казани купил CRM для записи клиентов. Руководитель думал, что вместе с программой получает право «передать её знакомому» и поставить на второй филиал, который оформлен на другое юрлицо. В договоре было ограничение на одно юрлицо и один домен, но никто вслух это не проговорил. Через месяц они попросили «просто добавить еще один аккаунт», а по факту это была новая лицензия. Разрулили быстро, потому что нашли письмо с выжимкой условий, которое продавец отправлял вместе с доступом. Время сэкономили оба, и никто не уходил в обиды.
Кейс второй: студия разработки из Новосибирска внедряла клиенту десктопное ПО на 25 рабочих мест. IT-отдел клиента хотел модифицировать интерфейс и «чуть-чуть» поменять логику, а менеджер со стороны подрядчика вначале сказал «да без проблем», не заглянув в лицензии библиотек внутри продукта. Потом выяснилось, что часть компонентов можно менять только в определенных рамках. Спасло то, что они остановились, оформили отдельное соглашение на доработки и прописали, кто владеет результатом. Никакой магии, только бумага и трезвость.
Кейс третий: онлайн-школа из Екатеринбурга купила подписочную платформу для обучения и была уверена, что «если оплатили год, то дальше оно останется навсегда». В момент продления они удивились, что доступ закрывается. Конфликт не разгорелся, потому что в оферте был четкий срок, а в письме при подключении было человеческое объяснение, что подписка это аренда сервиса. Подписку продлили, а параллельно школа попросила консультацию по бренду, потому что собиралась масштабироваться и боялась чужих претензий.
Где чаще всего ломается коммуникация и почему люди теряют время?
Первое место поломки это слово «купили». Оно живет в счетах, в переписке, в голосовых, в ТЗ. Потом кто-то в компании клиента задает невинный вопрос: «А где регистрация прав на по, где подтверждение, что мы теперь владельцы?». И процесс срывается на ровном месте. Лечится простым: единые формулировки во всех документах и короткая памятка на одну страницу, которую клиент может переслать бухгалтеру и IT.
Второе место это ожидания по обновлениям и поддержке. Клиент слышит «бессрочная лицензия» и думает, что обновления бессрочные тоже. Или наоборот, видит подписку и думает, что поддержка входит «по умолчанию», хотя у вас базовый тариф без SLA. Это тот случай, когда полезно документировать: какие версии доступны, как часто релизы, что входит в поддержку, в какие сроки отвечаете. В фактуре из блока прямо отмечено, что рынок тянется к подписочной модели, а правообладатели ужесточают контроль соблюдения условий. Это значит, что мутные договоренности будут всплывать чаще, а не реже.
Третье место это смешение разных «право на …» из жизни и из юриспруденции. Иногда в поиске люди набирают странные вещи вроде «право на пенсию по» или «право на ребенка по» или «право на труд по», потому что автоподсказки и привычка искать всё в одном поле. В переписке это тоже встречается: «нам нужно право», без уточнений. Не смейтесь (хотя иногда хочется), лучше уточните: право использования? право доработки? право передачи третьим лицам? ответы на вопросы по право в этой теме всегда начинаются с уточнения объекта и способа использования.
Кому реально выгодно заранее оформлять права и выстраивать защиту?
Если вы продаете ПО корпоративным клиентам, работаете через тендеры, или у вас продукт уходит в регионы по партнерам, вам почти неизбежно пригодится аккуратная юридическая упаковка: лицензионный договор или оферта, понятная схема выдачи доступа, и документы по цепочке прав. Это не про «бумажки ради бумажек». Это про то, чтобы продажи не тормозили на юристах клиента и чтобы вы не тратили вечера на объяснение одного и того же.
Отдельная история про бренд: если название продукта уже крутится в рекламе, в Telegram, во ВКонтакте, на маркетплейсах, стоит подумать о товарном знаке и проверке обозначения. Тут может помочь поддержка в формате консультации, аудита рисков и сопровождения регистрации. Если хотите быть в курсе новостей и разборов кейсов по интеллектуальной собственности, подпишитесь на Телеграмм канал Патентного бюро Лирейт». А если вы как раз смотрите в сторону защиты бренда, вот полезные страницы: Регистрация товарного знака, Монополия на бренд, Юридическая защита интеллектуальной собственности.
FAQ
Вопрос: Клиент просит «право собственности на ПО». Что отвечать без конфликта?
Ответ: Скажите, что обычно передается лицензия на ПО, то есть право использования, а исключительные права остаются у правообладателя. Если клиенту действительно нужна передача исключительных прав, это отдельный договор и другая цена и риски.
Вопрос: Чем отличается бессрочная лицензия от подписки, и какие сроки важны?
Ответ: Бессрочная лицензия дает право использовать программу без ограничения по времени, а подписочная действует только пока оплачена. Важно отдельно оговорить, входят ли обновления и поддержка и на какой период.
Вопрос: Можно ли «проверить по лицензии», что мы используем ПО законно?
Ответ: Да, сверяйте условия договора: количество пользователей, устройств, юрлицо, срок и способ использования. Плюс храните письмо или акт о предоставлении прав и идентификатор лицензии или аккаунта.
Вопрос: Что делать, если бухгалтерия просит «лицензию по ИНН»?
Ответ: Обычно им нужен договор/оферта, счет, акт и реквизиты поставщика с ИНН, чтобы правильно провести оплату. Сама лицензия описывается условиями договора, а не «привязывается к ИНН» как отдельный гос-документ.
Вопрос: Клиент хочет доработать программу. Это входит в права на использование ПО?
Ответ: Чаще нет, модификация обычно ограничена лицензией и требует согласования. Лучше заранее оформить отдельные условия на доработки и права на результат, чтобы не спорить, кому принадлежит новый функционал.
Вопрос: Зачем нам товарный знак, если речь про софт и лицензии?
Ответ: Потому что название и логотип это отдельный объект прав, и его могут оспорить или запретить использовать. Проверка и регистрация товарного знака помогают снизить риск претензий и блокировок в рекламе и на площадках.
Вопрос: Где посмотреть про патентование логотипа или названия, если мы решим защититься?
Ответ: Можно начать с понятных разборов: «Как запатентовать логотип и сколько стоит?» https://dzen.ru/video/watch/67d193d70f97ee77f2696cdf?share_to=link и «Как запатентовать название бренда и логотип в России?» https://dzen.ru/video/watch/67d193476d765c59f45ecc5f?share_to=link. Там хорошо объясняют базовую механику и типичные ошибки.