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