Как защитить ПО в Узбекистане: авторское право, патент или тайна

Ташкентский финтех-стартап — резидент IT Park, выручка растёт, инвестор готов зайти в раунд. На due diligence юрист инвестора задаёт один вопрос: «Покажите документы, по которым исключительное право на код принадлежит компании». Документов нет. Ядро продукта три года писал ведущий разработчик, оформленный по договору оказания услуг как самозанятый, без единой строчки о передаче прав. По закону имущественные права на этот код принадлежат ему, физическому лицу, а не компании, в которую инвестор собирался вложить деньги. Раунд встал на два месяца, пока стороны задним числом оформляли уступку прав — и разработчик, поняв свою позицию, поднял цену. Эта статья — про то, какой из трёх режимов защищает ваш софт в Узбекистане, и про три дыры, через которые право утекает из компании ещё до того, как вы успели его защитить.

Три режима: что каждый из них реально закрывает

Программное обеспечение — это не один объект, а слой из нескольких. Исходный и объектный код, архитектура, алгоритмы, интерфейс, данные, само название продукта. Разные слои защищаются разными инструментами, и путаница между ними — самая частая ошибка основателей.

• Авторское право защищает выражение — конкретный исходный и объектный код, как литературное произведение. Возникает автоматически в момент создания, охватывает форму, но не идею.
• Патент защищает техническое решение — но не программу «как таковую». В Узбекистане программа для ЭВМ прямо исключена из патентоспособных объектов; запатентовать можно изобретение, реализованное в софте, если оно даёт технический результат.
• Коммерческая тайна защищает то, что нельзя показывать вообще: алгоритм, формулу, архитектуру, базу клиентов. Защищает идею и ноу-хау — ровно то, до чего авторское право не дотягивается, — но только пока секрет остаётся секретом.

Эти режимы не конкурируют, а складываются. Зрелый продукт обычно защищён всеми тремя одновременно: код — авторским правом, ключевой алгоритм — режимом тайны, название и логотип — товарным знаком, а внешний вид интерфейса при желании — промышленным образцом.

Авторское право: возникает само, но регистрация всё равно нужна

Главная новость для основателя: чтобы код был защищён авторским правом, регистрировать ничего не надо. Право возникает в силу самого факта создания произведения — это базовый принцип Закона «Об авторском праве и смежных правах», и программы для ЭВМ прямо отнесены к охраняемым произведениям наравне с литературными.

Тогда зачем платить за регистрацию? Затем, что авторское право легко иметь и тяжело доказать. Когда конкурент выпустит подозрительно похожий продукт, а вы придёте в суд, первый вопрос будет: «Докажите, что этот код написали вы, и написали раньше». ЦИС ведёт государственный реестр программ для ЭВМ и баз данных; регистрация добровольная, по итогу выдаётся свидетельство с фиксированной датой и депонированным фрагментом кода. Это не «создаёт» право — оно у вас и так есть, — но превращает спор «моё слово против вашего» в спор с официальным документом и датой приоритета на вашей стороне.

Стоит ли регистрировать каждый релиз? Нет. Регистрируют ключевые версии: первый коммерческий релиз, крупные мажорные обновления, версию перед инвестиционным раундом или сделкой. Госпошлина за регистрацию одной программы — ориентировочно несколько сотен тысяч сум; точную ставку смотрите в актуальной таблице пошлин ЦИС, она пересматривается примерно раз в год. На фоне стоимости разработки это символическая сумма за документ, который в суде стоит дороже любых показаний.

Чего регистрация не делает: она не проверяет код на оригинальность и не гарантирует, что вы не нарушили чужие права. Свидетельство фиксирует «вот этот код существовал у этого лица на эту дату» — не более. Если вы вставили чужую библиотеку с несовместимой лицензией, свидетельство вас не спасёт.

Патент: когда алгоритм всё-таки патентуется

Соблазн «запатентовать алгоритм» возникает у каждого второго технического основателя. В Узбекистане это в лоб не работает: программа для ЭВМ как таковая не относится к изобретениям по Патентному закону, как и алгоритмы, и математические методы. Патент защищает техническое решение задачи, а не последовательность команд.

Граница проходит по техническому результату. Если ваш софт — это бизнес-логика, интерфейс или способ организации данных, патента не будет. Если же программа управляет работой устройства, обрабатывает сигнал новым способом, повышает быстродействие или экономит ресурс измеримым техническим образом — у вас потенциально есть изобретение, «реализованное в ПО». Формула в заявке тогда пишется не на код, а на способ или устройство.

Когда за это стоит браться: патент имеет смысл, если решение трудно скрыть (его видно по работе продукта, реверс-инжиниринг реален) и одновременно его сложно обойти альтернативной реализацией. Если же ваше преимущество — в коде, который никто не видит, патент только навредит: заявка раскрывает суть решения, а защиту в Узбекистане даёт лишь на 20 лет и только в тех странах, где вы патент получили. Подробнее о выборе между национальной и зарубежной заявкой — у нашей команды по патентам.

Коммерческая тайна: режим, который защищает идею

То, до чего не дотягивается авторское право (идея, алгоритм, метод) и что вы не хотите раскрывать в патенте, защищает режим коммерческой тайны. В Узбекистане есть профильный Закон «О коммерческой тайне», и он работает по принципу «защищено ровно настолько, насколько вы сами это охраняете».

Ключевое слово — режим. Информация становится коммерческой тайной не сама по себе, а когда вы ввели и документально зафиксировали меры по её охране:

• утвердили перечень сведений, составляющих тайну (исходный код ядра, архитектура, параметры моделей, база клиентов);
• ограничили доступ и ведёте учёт, кто к чему допущен;
• включили условие о конфиденциальности в трудовые договоры и в договоры с подрядчиками, подкрепив NDA;
• маркируете носители грифом «Коммерческая тайна».

Если режим не введён, секрета юридически нет: ушедший разработчик, унёсший алгоритм к конкуренту, не нарушил ничего, потому что охранять было нечего. Поэтому для софтверной компании режим тайны — не бумажная формальность, а единственная защита самого ценного слоя продукта, который принципиально не показывают ни в реестре, ни в патенте.

Служебное произведение и договоры с подрядчиками: где утекает право

Вернёмся к стартапу из вступления. Его ошибка — самая дорогая и самая частая в IT. Разберём, кому принадлежит код в трёх типичных ситуациях.

Штатный сотрудник. Код, написанный работником в рамках трудовых обязанностей, — это служебное произведение. По умолчанию исключительное право на него принадлежит работодателю, а у автора остаётся право на имя и право на авторское вознаграждение. Это работает в вашу пользу — но только если у разработчика есть трудовой договор, а его обязанности и задание сформулированы так, что спорный код в них попадает. «Разработчик написал в свободное время сервис, не входящий в его задачи» — это уже не служебное произведение, и право остаётся у него.

Подрядчик, фрилансер, аутсорс-команда. Здесь по умолчанию всё наоборот: исключительное право остаётся у автора-исполнителя, если в договоре прямо не написано, что оно передаётся (уступается) заказчику. Договор оказания услуг или подряда сам по себе право на код не переносит — он про работу, а не про IP. Именно на этом сгорел стартап из вступления: услуги оплачены, акты подписаны, а право на код так и осталось у физлица.

Сооснователь без оформления. Самая взрывоопасная конфигурация: двое пишут продукт «на доверии», без трудовых договоров и без соглашения о распределении прав. Каждый — соавтор, право общее, и распоряжаться им можно только сообща. Когда один уходит, он уносит половину прав на продукт — и может заблокировать сделку или лицензирование.

Вывод для основателя один: исключительное право не появляется у компании само. Его нужно либо получить как работодателю по служебному произведению (с правильно оформленными трудовыми отношениями), либо забрать у исполнителя письменной уступкой. Механика уступки исключительного права — в нашем разборе договора уступки; для кода работают те же принципы, что и для товарного знака: без письменного документа право не перешло.

Open-source: лицензия, которая может стать ловушкой

Почти любой современный продукт собран на чужих библиотеках, и каждая идёт со своей лицензией. Пермиссивные лицензии (MIT, BSD, Apache 2.0) разрешают использовать код в проприетарном продукте почти без условий — нужно лишь сохранить уведомление об авторстве. Копилефт-лицензии (GPL, AGPL) устроены иначе: они требуют, чтобы производное произведение распространялось на тех же условиях, то есть с открытием исходного кода.

Ловушка в том, что включив GPL-компонент в ядро своего закрытого продукта, вы можете оказаться обязаны открыть и собственный код — а для SaaS особенно опасна AGPL, которая считает «распространением» даже предоставление доступа по сети. Для компании, продающей закрытый софт, это означает потерю того самого преимущества, ради которого писался код.

Практический минимум: ведите реестр всех сторонних зависимостей с указанием лицензии (manifest файлы зависимостей — ваш черновик такого реестра), отделяйте копилефт-компоненты от проприетарного ядра и проверяйте лицензии до того, как библиотека вошла в релиз, а не во время due diligence перед раундом.

Как выбрать режим: короткое дерево решений

• Это код, интерфейс, документация? → авторское право автоматически; зарегистрируйте ключевые версии в ЦИС.
• Это техническое решение с измеримым эффектом, которое видно по работе продукта? → рассмотрите патент.
• Это алгоритм или ноу-хау, которое вы не показываете? → введите режим коммерческой тайны.
• Это внешний вид интерфейса, иконки, анимации? → плюс промышленный образец.
• В любом случае: закройте вопрос прав — трудовые договоры со служебным заданием, уступка от подрядчиков, аудит open-source.

Кратко

• Код в Узбекистане защищает авторское право, а не патент; патент — только для технического решения, реализованного в ПО.
• Авторское право возникает само, но регистрация программы в ЦИС даёт дату приоритета и документ для суда — регистрируйте ключевые версии.
• Коммерческая тайна защищает идею и алгоритм, но только при введённом режиме конфиденциальности (перечень, доступ, NDA, маркировка).
• Право не появляется у компании автоматически: у штатного сотрудника — служебное произведение в вашу пользу, у подрядчика — нет, пока не оформлена уступка.
• Open-source с копилефт-лицензией (GPL, AGPL) может обязать раскрыть ваш закрытый код — ведите реестр зависимостей.

Частые вопросы

Нужно ли регистрировать программу для ЭВМ, чтобы она была защищена? Нет. Авторское право возникает автоматически в момент создания. Регистрация в ЦИС добровольная и нужна не для возникновения права, а для доказывания: свидетельство фиксирует дату и содержание кода, что решает спор о том, кто и когда написал продукт.

Можно ли запатентовать мобильное приложение? Само приложение как программу — нет, оно защищается авторским правом. Запатентовать можно техническое решение внутри него: новый способ обработки данных, управления устройством, сжатия или передачи сигнала, дающий измеримый технический результат. Бизнес-логика и интерфейс под патент не подпадают.

Кому принадлежит код, написанный фрилансером по договору? По умолчанию — самому фрилансеру. Договор оказания услуг или подряда оплачивает работу, но не переносит исключительное право на код. Чтобы право перешло к заказчику, в договоре должна быть прямая формулировка об уступке (отчуждении) исключительного права.

Что такое служебное произведение и почему это важно? Это произведение, созданное работником в рамках трудовых обязанностей. Исключительное право на него по умолчанию принадлежит работодателю. Для IT-компании это главный легальный канал, по которому код сотрудников становится активом компании, — но он работает только при оформленном трудовом договоре с корректно описанными обязанностями.

Защищает ли NDA само по себе? NDA — необходимый, но не достаточный элемент. Коммерческая тайна охраняется, когда введён весь режим: утверждён перечень секретных сведений, ограничен доступ, носители маркированы. NDA без остального режима суд может не признать достаточной мерой охраны.

Можно ли использовать GPL-библиотеку в коммерческом продукте? Использовать можно, но с условиями. GPL требует распространять производное произведение на тех же открытых условиях, а AGPL распространяет это требование и на SaaS-доступ по сети. Для закрытого продукта это риск раскрытия кода — копилефт-компоненты нужно изолировать от проприетарного ядра либо заменять пермиссивными аналогами.

Сколько действует авторское право на программу? Имущественные (исключительные) права действуют десятилетиями — весь срок жизни автора и значительный период после, после чего произведение переходит в общественное достояние. Для бизнеса практически это означает, что права на код не «истекают» в обозримом горизонте; важнее не срок, а то, кто этими правами владеет.

Софт кажется неосязаемым, но юридически это набор вполне конкретных прав — и они либо принадлежат вашей компании, либо нет. Регистрация версий, режим тайны и патент усиливают защиту, но всё это бессмысленно, если базовое исключительное право утекло к подрядчику или соавтору. Сначала соберите право внутри компании. Защищать чужой код — дорогое и проигрышное занятие.