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