Компания разрабатывает программу, платит сотрудникам и подрядчикам, предоставляет доступ клиентам и получает выручку. Но на вопрос о принадлежности прав руководство нередко отвечает: «Конечно, программа наша. Мы же за нее заплатили».
В судебном споре такого ответа может оказаться недостаточно. Он также не закрывает вопросы инвестора или проверки обоснованности налоговых льгот.
В своей практике я вижу, что даже средние и крупные компании уделяют оформлению собственных программ значительно меньше внимания, чем недвижимости или оборудованию. По моим наблюдениям, регистрация ПО в Казахстане пока не стала привычной частью управления разработкой. Документы начинают собирать после увольнения ключевого специалиста, конфликта с подрядчиком или получения иска.
Между тем неопределенность в правах на один продукт способна одновременно затронуть его использование, договоры с клиентами, налоговую позицию и стоимость бизнеса. Поэтому регистрацию необходимо рассматривать вместе с оформлением имущественных прав, сохранением истории разработки и учетом результата.
Закон Республики Казахстан «Об авторском праве и смежных правах» охраняет компьютерные программы, включая исходный текст и объектный код. Согласно статьям 7 и 9 авторское право возникает вследствие создания произведения; обязательная регистрация для этого не требуется.
Однако возникновение права и возможность подтвердить его принадлежность конкретному лицу имеют разное практическое значение. В споре компании придется установить, какой объект создан, кем, когда и на каком основании она вправе его использовать.
Внесение сведений в Государственный реестр прав на объекты, охраняемые авторским правом, создает дополнительный документальный след. При этом регистрация носит учетный характер и не исключает судебного спора. Свидетельство не устраняет недостатки договоров и само по себе не доказывает исключительные имущественные права работодателя.
Юридический вывод: регистрация добровольна, но подготовка доказательств принадлежности прав необходима для их эффективной защиты. Договоры, служебные задания, материалы регистрации и история версий должны относиться к одному определенному продукту.
В одном из судебных споров, в которых я представлял интересы бизнеса, бывший работник предъявил компании требования о запрете использования ПО и взыскании компенсации. В обоснование он ссылался, в частности, на свидетельство о внесении сведений в реестр. Компания возражала: разработка создавалась в рамках трудовых отношений и корпоративных заданий, поэтому имущественные права принадлежат работодателю.
Для разрешения спора потребовалось разбирать трудовые документы, задания, технические материалы и версии разработки. Существенными стали вопросы о составе зарегистрированного объекта, его соотношении с корпоративной программой и обстоятельствах создания спорных элементов.
Статья 14 Закона об авторском праве разграничивает личные неимущественные права автора и имущественные права на служебное произведение. По общему правилу последние принадлежат работодателю, если произведение создано при выполнении служебных обязанностей или служебного задания и договором не предусмотрено иное.
Поэтому выплата зарплаты не должна оставаться единственным аргументом компании. Важно подтвердить содержание трудовой функции, конкретные задания и созданный результат. Участие нескольких работников также требует установить вклад каждого, а не просто объявить продукт «командной разработкой».
Юридический вывод: авторство сотрудника само по себе не означает принадлежности ему имущественных прав на служебную программу. Но работодателю необходимо доказать основания применения служебного режима.
Авторское право не предоставляет монополию на идею сервиса, метод работы или общий принцип построения системы. Это следует из пункта 4 статьи 6 Закона об авторском праве. При этом конкретная форма выражения программы, включая охраняемый код, может защищаться.
Идею автоматизировать доставку могут реализовать разные участники рынка. Но это не дает одному из них права копировать охраняемый код другого без соответствующего основания. Для защиты нужно определить конкретные элементы, принадлежность прав на них и способ предполагаемого нарушения.
Такая определенность необходима и при лицензировании. Компания должна сопоставить права, полученные от авторов и подрядчиков, с тем, что она предоставляет клиенту. Статьи 31 и 32 Закона об авторском праве регулируют договорную передачу имущественных прав. По пункту 7 статьи 32 дальнейшая передача полученных прав другим лицам допускается при прямом договорном разрешении.
Оплата разработки не заменяет согласованных условий о правах. Соглашение о конфиденциальности также не решает весь вопрос: обязанность хранить информацию и право коммерчески использовать результат имеют разное содержание.
Отсутствие свидетельства само по себе не делает лицензирование незаконным. Компания может обладать необходимыми правами в силу закона или договора. Но клиентский договор не восполняет отсутствие этих прав. Если поставщик гарантирует законность использования продукта, он должен иметь основания для такой гарантии.
Для SaaS необходимо определить фактическую договорную модель: предоставление удаленного доступа к функционалу не всегда равнозначно передаче прав на экземпляр программы. Само название модели не подтверждает правообладание и не определяет налоговую квалификацию.
Юридический вывод: до коммерциализации продукта нужно установить объем собственных прав, ограничения сторонних компонентов и полномочия на предоставление прав клиентам.
Для участника Astana Hub оформление разработки может иметь прямое значение при применении налоговых преимуществ. В Налоговом кодексе, действующем с 2026 года, статьи 739-741 разграничивают доходы от объектов интеллектуальной собственности, услуг в сфере информатизации и иные доходы. Условия их налогообложения необходимо анализировать отдельно.
Особенно важна статья 740. Для применения предусмотренного ею порядка уменьшения КПН по доходам от объектов интеллектуальной собственности участник должен обладать исключительными имущественными правами на соответствующий объект. Это условие конкретного порядка уменьшения КПН; распространять его на все льготы Astana Hub было бы неправильно.
Предположим, компания получает платежи за использование программы и применяет к ним соответствующий порядок. При проверке выясняется, что ключевой результат создан подрядчиком, а переход исключительных имущественных прав документально не подтвержден. Тогда вопрос выходит за пределы отношений с разработчиком: на каком основании компания применила налоговое преимущество к этому доходу?
Наличие свидетельства не заменяет подтверждения имущественных прав. Его отсутствие также автоматически не означает утрату льготы. Проверять необходимо правообладание, характер дохода и остальные условия применяемой нормы.
Статья 740 предусматривает расчет с коэффициентом взаимосвязи расходов, поэтому значение имеют и документы о создании, приобретении объекта и привлечении исполнителей. Отдельный порядок для услуг информатизации установлен статьей 741. При определении приоритетной деятельности следует учитывать перечень, действующий с 2026 года.
Служба мониторинга Astana Hub обращает внимание на исключительные имущественные права и запрашиваемую документацию, включая договоры, акты, ЭСФ и материалы по интеллектуальной собственности.
Юридический вывод: компания должна подтверждать связь между конкретной программой, правами на нее, договором с клиентом и доходом, к которому применяется льгота. Наименование платежа «лицензионным» эту связь не доказывает. Ошибка в подтверждении условий может поставить вопрос о пересчете налоговых обязательств.
Формула «без регистрации никто не даст инвестиции» слишком категорична. Но если ключевая технология принадлежит основателю лично или ее правовой статус зависит от бывшего подрядчика, это способно повлиять на оценку бизнеса, условия и сроки сделки.
Инвестор проверяет происхождение продукта, договоры с разработчиками, сторонние лицензии, споры и соответствие документов фактически работающей программе. Эти вопросы отражены, в частности, в руководстве WIPO по проверке интеллектуальной собственности перед сделкой. Свидетельство полезно в составе такого комплекта, но не заменяет последовательного подтверждения перехода прав.
Программа может также признаваться нематериальным активом при выполнении применимых условий учета. Для компаний, использующих МСФО, IAS 38 предусматривает требования к идентифицируемости, контролю, ожидаемым экономическим выгодам и оценке стоимости. Расходы на исследования и затраты на разработку учитываются по разным правилам.
Поэтому регистрация не означает автоматической постановки программы на баланс. Отсутствие регистрации также само по себе не исключает признания актива. Правовые основания контроля проверяет юрист, состав и готовность продукта определяет техническая команда, учетную оценку проводит финансовая служба.
Юридический вывод: регистрация, принадлежность имущественных прав и признание НМА требуют самостоятельной проверки. Их согласованность помогает подготовить продукт к инвестициям, продаже и реорганизации.
Начать стоит с продукта, от которого сильнее всего зависят выручка или непрерывность работы компании.
Эта работа помогает не только защищаться в суде. Она снижает зависимость от отдельных разработчиков, позволяет обосновывать договорные гарантии и облегчает проверку продукта перед сделкой.
Задача юриста в таком проекте состоит в том, чтобы компания могла документально подтвердить, какой продукт она создала, какими правами располагает, что предоставляет клиенту и на каком основании применяет выбранный налоговый порядок.