Использование программы для ЭВМ в составе SaaS-сервиса: правовые нюансы и риски
Обычно всё начинается невинно. Команда пилит сервис, выкатывает «закрытую бету», первые клиенты заходят по ссылке, платят картой, пишут в поддержку: «у вас кнопка “Сохранить” пропадает». И где-то рядом, в общем чате, кто-то осторожно спрашивает: «А нам вообще можно это так отдавать? У нас же внутри… ну, библиотека. И ещё один модуль, который фрилансер писал». В такие моменты тишина становится плотной: все видят интерфейс, а право никто не видит, пока оно не стукнет в дверь.
С SaaS есть коварная иллюзия: раз пользователь ничего не скачивает, значит «мы ничего не распространяем», значит «лицензии не нужны». И вот тут начинается весёлое. Потому что программа для ЭВМ в России охраняется авторским правом с момента создания, это прямо следует из статьи 1261 ГК РФ. То есть не нужно регистрировать, «отправлять себе на почту» и прочие ритуалы из нулевых. Но нужно понимать, кто автор, кому принадлежат права, как именно вы даёте доступ, и почему бухгалтер вдруг задаёт вопрос про НДС (да, и такое бывает).
Зачем вообще читать дальше, если сервис уже работает
После этого текста у вас в голове должен сложиться нормальный, рабочий маршрут: как легально использовать программу для ЭВМ внутри SaaS-сервиса, как не поссориться с разработчиками и подрядчиками, как не получить сюрприз от правообладателя чужой библиотеки и почему «пользовательское соглашение на сайте» не всегда спасает. Я пишу как человек, который видел, как один и тот же продукт можно оформить спокойно, а можно так, что потом два месяца разгребают переписку, акты и «а давайте быстро подпишем задним числом». Лучше не доводить до этого, правда.
Пошаговый гайд: как запускать SaaS так, чтобы не споткнуться об права
Шаг 1. Зафиксируйте, что именно у вас является программой для ЭВМ, а что просто «сервисом»
Первое, что мы делаем в работе, это вынимаем из тумана слова «платформа», «облако», «продукт» и раскладываем по полкам: где код (то есть программа для ЭВМ), где база данных, где интерфейс и тексты, где товарный знак и домен. Зачем это нужно? Потому что права, риски и договоры у этих сущностей разные. Программа для ЭВМ как объект авторского права живёт своей жизнью: у неё есть авторы, правообладатель, служебные произведения, отчуждение, лицензии. А «сервис» как способ предоставления доступа через интернет это уже про модель использования, а не про объект.
Типичная ошибка на этом шаге: «у нас всё своё». Потом открываешь репозиторий, а там половина функциональности собрана на сторонних компонентах, плюс дизайн от подрядчика, плюс тексты в интерфейсе взяты из чужого сайта (иногда случайно, иногда “для теста”, а потом забыли). Проверка простая: составьте перечень ключевых модулей и зависимостей и ответьте на два вопроса по каждому: кто автор и на каком основании вы это используете. Если на часть компонентов основание звучит как «вроде можно», значит, уже есть работа.
Шаг 2. Приведите в порядок права с командой: сотрудники, ГПХ, фрилансеры
Дальше я всегда иду к источнику: кто писал код. Если это штатный разработчик, смотрим, действительно ли это служебное произведение, и как оформлены отношения. Если подрядчик по договору, смотрим, что у вас там в договоре: передача исключительных прав или лицензия, на какой срок, на какую территорию, с правом переработки, с правом использовать в составе SaaS. Это звучит скучно, но скука тут целебная: она спасает от ситуации «фрилансер обиделся и попросил удалить его модуль».
Типичная ошибка: подписали договор оказания услуг «на разработку», оплатили, акт закрыли, а про права ни слова. В итоге у вас есть работа, но нет прав на программу для ЭВМ, и вы юридически зависите от доброй воли автора. Как проверить, что всё работает: по каждому разработчику должен быть документ, где прямо сказано, кому принадлежат исключительные права на созданный код, и есть ли у вас право использовать и модифицировать его в коммерческом SaaS. Это не «на всякий случай», это базовая гигиена, как бэкап.
Шаг 3. Разберитесь с open source и чужими библиотеками до того, как придёт корпоративный клиент
Опенсорс не бесплатный, он просто по-другому оплачивается: вниманием к лицензии. В SaaS часто думают: «мы же не распространяем, значит copyleft нас не касается». Иногда это правда, иногда нет, зависит от конкретной лицензии и сценария использования. Плюс у корпоративных клиентов бывает комплаенс: они спрашивают перечень компонентов, лицензии, наличие ограничений. И это не паранойя, это просто привычка больших компаний закрывать риски заранее.
Типичная ошибка здесь особенно обидная: разработчик «для ускорения» добавил зависимость, а лицензия требует раскрывать исходники при определённых условиях, или запрещает коммерческое использование без отдельного разрешения. Потом этот модуль становится критичным, убрать его больно, и начинается торг с самим собой: «может, пронесёт». Проверка: сделайте инвентаризацию зависимостей (хотя бы основных) и заведите привычку хранить рядом с проектом сведения о лицензиях. У меня был кейс: небольшой сервис для бухгалтерии на 12 человек команды, сроки горели, и они за неделю до пилота для сети кафе выяснили, что внутри есть компонент с неясной лицензией. Потратили три вечера, переписали кусок, и пилот не сорвали. Если бы выяснили через месяц, переписывали бы уже “на бою”, с клиентами в проде.
Шаг 4. Правильно оформите доступ в SaaS: договор и формулировки решают больше, чем кажется
В модели SaaS пользователь получает доступ к функциональности через интернет и, как правило, ничего не устанавливает. Это отличается от классической схемы, когда вы передаёте права на использование ПО по лицензионному договору в привычном смысле. И вот тут тонкость: многие берут шаблон «лицензионное соглашение на программу», вставляют название сервиса и думают, что закрыли вопрос. А у вас может быть смешанная конструкция: услуги, доступ к функционалу, и элементы лицензии на использование интерфейса или отдельных модулей, если что-то всё-таки передаётся.
Типичная ошибка: договор написан так, что непонятно, что именно получает пользователь, какие ограничения, кто отвечает за данные, что делать при сбое, можно ли использовать результаты обработки. В споре это превращается в кашу. Проверка: дайте договор прочитать человеку не из вашей команды, например, менеджеру по продажам или техдиректору. Если он не может своими словами объяснить, что продаём и где границы, значит, формулировки надо лечить. И да, пользовательское соглашение на сайте это лучше, чем ничего, но с B2B оно часто не взлетает, там любят подписанный документ или оферту с понятными условиями.
Шаг 5. Не проспите налоги: SaaS и НДС иногда встречаются слишком близко
Налоговая часть в SaaS неприятна тем, что она приходит не сразу. Сначала вы радуетесь подпискам, потом приходит бухгалтер или внешний консультант и говорит: «а это у вас что: лицензия или услуга?» И если вы надеялись на освобождение по НДС как по лицензионным платежам, может выясниться, что в вашем конкретном оформлении это не работает. В практике обсуждают, что передача прав на использование ПО в рамках SaaS может облагаться НДС, потому что не подпадает под освобождение, предусмотренное для лицензионных соглашений. Тут важны детали того, что именно вы передаёте и как описали предмет договора.
Типичная ошибка: юридический текст пишет один человек, финмодель считает другой, а потом они встречаются в конце квартала и оба удивлены. Проверка: посадите рядом юриста и бухгалтера (или налогового консультанта) и прогоните ваш договор глазами: что называется услугой, что правом использования, есть ли лицензионные формулировки и за что именно берутся деньги. У меня был мини-кейс у команды, которая автоматизировала кадровые процессы для небольших производств: запустились быстро, подписок стало около сотни, и только после этого начали думать про налоги. Закончилось тем, что переписывали оферту, меняли описание тарифа и пересобирали пакет документов для клиентов. Не катастрофа, но нервов съело прилично.
Шаг 6. Проверьте легальность всего, что крутится на серверах, включая «временное»
Легализация программного обеспечения звучит как что-то из девяностых, но на деле это про банальное: у вас на сборочной машине, на сервере, в платных библиотеках и в инструментах разработки всё должно быть использовано правомерно. Особенно если вы продаёте SaaS компаниям, которые могут попросить подтверждения: от лицензий на коммерческие компоненты до прав на шрифты, которые внезапно оказываются платными. «Мы поставили на тест, потом удалим» очень часто превращается в «да оно так и осталось».
Типичная ошибка: считать, что раз код не отдаём пользователю, то можно использовать любой софт где угодно. Нет, нельзя. Проверка: сделайте ревизию платных компонентов и инструментов, хотя бы точечно по критичным: биллинг, аналитика, отчётность, платные API, шрифты, и всё то, что вы точно не хотите объяснять в конфликте. И если у вас есть подрядчик, который приносит «готовый модуль», просите подтверждение прав и лицензий, иначе вы просто покупаете кота, который потом кусается.
Шаг 7. Данные и безопасность: юридический риск приходит через утечки, а не через формулировки
С SaaS вы почти всегда лезете в чужие данные: персональные, коммерческие, иногда медицинские или финансовые. И даже если вы не храните ничего “страшного”, клиенты могут считать иначе. Нужны меры защиты, доступы, журналы, разграничение ролей, понятная политика хранения и удаления. Да, это техника, но юридические последствия обычно начинаются именно с «у нас кто-то увидел чужой отчёт».
Типичная ошибка: сделать безопасность «потом», потому что сначала надо продать. А потом прилетает инцидент, и вы судорожно ищете, кто, когда и с какого IP заходил. Проверка: у вас должны быть хотя бы базовые вещи: контроль доступов, резервные копии, логирование критичных действий, порядок реагирования на инциденты. И документально должно быть понятно, кто за что отвечает: вы как провайдер, клиент как оператор своих процессов, и где границы. Кстати, исследования по облакам в распределённой разработке отдельно отмечают риски зависимости от провайдера, недоступности облака, техдолга и допзатрат на поддержку. Это не страшилки, это просто реальность, в которую лучше смотреть заранее, а не в ночь падения продакшена.
Подводные камни: где чаще всего ломается SaaS с точки зрения права
Первый слом почти всегда человеческий: «мы же друзья, подпишем потом». Потом это “потом” превращается в полгода, разработчик уходит, доступы меняются, и внезапно выясняется, что никто не может показать документ, по которому компании принадлежат права на ключевой кусок. Вторая частая поломка, ещё более тихая: смешение чужого и своего в одной кастрюле. Когда в сервисе есть сторонние модули, шрифты, изображения, платные библиотеки, а никто не ведёт учёт, вы просто не знаете, где у вас риски. И это неприятно не только юридически, но и технически: заменить компонент в зрелом продукте бывает дороже, чем написать свой с нуля.
Ещё один «любимый» камень, на который наступают даже сильные команды: договор с клиентом. Продажи хотят коротко и красиво, юристы хотят закрыть всё, технари хотят, чтобы их не трогали. И в итоге подписывают текст, который плохо отражает реальность: обещают доступ 24/7 без оговорок, берут на себя ответственность за данные клиента целиком, или, наоборот, пишут настолько расплывчато, что потом невозможно понять, что именно вы предоставляете. А когда начинается спор, суд и эксперты не лезут в ваши намерения, они читают бумагу. Бумага, как водится, хладнокровная.
И да, зависимость от провайдера и инфраструктуры в облачной модели тоже про риски. Не потому что «облако плохое», а потому что у вас появляются внешние точки отказа: хостинг, платёжка, провайдер почты, карты. Условия могут поменяться, доступ может пропасть, стоимость может подрасти. В договоре с клиентом лучше заранее честно обозначать, где у вас «внешняя часть» и какие есть ограничения. Не для того чтобы снять с себя всё, а чтобы ожидания были человеческими, а не сказочными.
Кому реально поможет оформление прав и регистрация, и в каком виде это обычно работает
Если вы делаете SaaS всерьёз, рано или поздно вы упрётесь в вопрос “а что именно мы продаём и кому это принадлежит”. Самое заметное облегчение получают команды, которые выходят в B2B, идут к инвестору или начинают масштабировать разработку на подрядчиков. Там любая неопределённость по интеллектуальной собственности превращается в тормоз: каждый новый договор требует объяснений, каждый клиент присылает протокол разногласий, каждый новый разработчик добавляет слой риска.
Форматы поддержки, которые обычно экономят время, простые: аудит прав на программу для ЭВМ и зависимостей, нормальные договоры с разработчиками и подрядчиками, выстроенная оферта или рамочный договор для клиентов, плюс аккуратная работа с брендом. Если вы параллельно развиваете название и дизайн, полезно подумать о Регистрация товарного знака и о том, как закрепить за собой Монополия на бренд, потому что в SaaS бренд иногда дороже кода, даже если техдиректор со мной поспорит. А если хочется держать руку на пульсе и не пропускать новости по интеллектуальной собственности, удобнее всего подписаться на Telegram-канал и отдельно на Телеграмм канал Патентного бюро Лирейт», там обычно обсуждают то, что потом внезапно всплывает в договорах и переписках.
Если нужна именно Юридическая защита интеллектуальной собственности как процесс, а не разовая бумага, я бы смотрела на связку “права на код плюс бренд плюс договорная база”. Она не делает жизнь идеально безопасной, но убирает самые глупые провалы, из-за которых потом стыдно перед самим собой. И это, честно, уже неплохо.
FAQ
Вопрос: Если у нас SaaS и пользователи ничего не скачивают, это вообще лицензирование или услуги?
Ответ: В SaaS пользователю обычно предоставляют доступ к функциональности через интернет, и это отличается от классической модели, где ПО передают для установки. На практике договор часто смешанный: элементы услуг и условия использования программы для ЭВМ. Важно, чтобы предмет был описан так, как вы реально работаете, иначе вы сами себе создаёте спорные зоны.
Вопрос: Нужно ли регистрировать программу для ЭВМ, чтобы она охранялась?
Ответ: Охрана по авторскому праву возникает с момента создания, это следует из статьи 1261 ГК РФ. Регистрация не обязательна для появления прав, но документы, подтверждающие правообладание и цепочку прав, всё равно нужны, особенно если код писали разные люди и подрядчики.
Вопрос: Можно ли использовать код фрилансера, если мы оплатили работу и подписали акт?
Ответ: Оплата и акт сами по себе не всегда означают переход исключительных прав. Нужна прямая договорённость о том, кому принадлежат права на результат, и какие способы использования разрешены, включая использование в составе SaaS и право на переработку.
Вопрос: Что делать, если в продукте много open source, и мы не уверены в лицензиях?
Ответ: Начать с инвентаризации ключевых зависимостей и их лицензий, не пытаясь объять всё за один вечер. Затем оценить ограничения и привести использование в соответствие: где-то достаточно соблюсти условия уведомлений, а где-то придётся заменить компонент или получить отдельное разрешение. “Не уверены” в этом вопросе обычно означает “риск уже есть”.
Вопрос: Правда ли, что SaaS может облагаться НДС, даже если мы называем договор «лицензионным»?
Ответ: Налоговая квалификация зависит от сути отношений и формулировок. В практике встречается позиция, что передача прав на использование ПО в рамках SaaS может облагаться НДС, так как не всегда подпадает под освобождение, предусмотренное для лицензионных соглашений. Это как раз тот случай, когда стоит согласовать договорные формулировки с бухгалтерией заранее.
Вопрос: Какие документы чаще всего просят B2B-клиенты по правам на SaaS?
Ответ: Обычно это договор или оферта с понятным предметом и ответственностью, подтверждения прав на ключевые компоненты (особенно если разработка была подрядной), и сведения о сторонних библиотеках или сервисах, если клиент живёт в режиме комплаенса. Иногда просят и описание мер защиты данных, потому что риски утечек для них больнее любых формулировок.
Вопрос: Когда имеет смысл регистрировать товарный знак, если мы про SaaS?
Ответ: Когда название сервиса начинает жить своей жизнью: появляются продажи, партнёрства, реклама, упоминания в соцсетях и каталогах, и вы понимаете, что менять имя будет дорого и по времени, и по репутации. В SaaS бренд часто становится главным ориентиром для клиента, и лучше, чтобы его не “увели” в самый неподходящий момент.