Кому принадлежит программа: 7 ошибок, из-за которых компания рискует потерять право на ПО

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

Ниже — семь ошибок, из-за которых обычная рабочая ситуация может превратиться в долгий спор.

Ошибка 1. Считать, что место хранения программы определяет ее владельца. 

Исходный код часто хранится в корпоративной системе управления версиями, например в «Git». Такая система показывает, кто и когда вносил изменения, как развивались отдельные части программы и какие версии выпускала команда. Это сильное доказательство фактической истории разработки.

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

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

Ошибка 2. Называть служебным все, что создал работник. 

В законодательстве Казахстана используется понятие «служебное произведение». Это произведение, созданное работником при выполнении служебных обязанностей или конкретного задания работодателя. Программное обеспечение, его отдельная часть, графика, тексты и документация могут быть служебными произведениями, если их создание действительно связано с работой человека.

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

Однако одного статуса работника недостаточно. Корпоративный компьютер, рабочее время и выплата заработной платы сами по себе не превращают любую разработку человека в имущество компании. Нужно подтвердить связь конкретного результата с его должностными обязанностями или заданием работодателя.

Для этого следует проверить:

• входила ли разработка программы в трудовую функцию;
• было ли поставлено понятное задание;
• какая часть или версия программы создавалась по этому заданию;
• кто фактически внес творческий вклад;
• не установили ли стороны иной порядок распределения прав.

Задание необязательно оформлять отдельным приказом. Оно может содержаться в утвержденном плане работ, служебной переписке или корпоративной системе учета задач. Главное, чтобы позднее можно было установить содержание поручения, его автора, исполнителя и принятый результат.

Ошибка 3. Смешивать автора и правообладателя. 

Автором может быть только человек, который внес творческий вклад. Компания автором не становится, даже если ей принадлежат исключительные права. За создателем сохраняются личные неимущественные права, включая право признаваться автором. Они не продаются и не переходят к работодателю.

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

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

Ошибка 4. Считать свидетельство окончательным доказательством права. 

Авторское право на программу возникает в силу ее создания. Обязательная государственная регистрация для этого не требуется. Внесение сведений в государственный реестр полезно: оно фиксирует заявленную версию, дату и указанных заявителем лиц.

Но свидетельство не равно патенту и не исключает спор. Если другой участник представит трудовые документы, задания, переписку, договоры и историю разработки, суд будет оценивать доказательства в совокупности. Само по себе свидетельство не отвечает на вопрос, была ли программа служебной и кому принадлежат исключительные права.

С июля 2026 года правила ведения реестра отдельно учитывают документы для служебных произведений, перехода прав и переработанных произведений. Перед подачей заявления компании стоит проверить, какую именно версию она регистрирует, кто указан автором, чем подтверждается право компании и допустимо ли раскрытие исходного кода с учетом коммерческой тайны.

Ошибка 5. Воспринимать цифровой продукт как один неделимый объект.

Обычно продукт состоит не только из программного кода. В него могут входить графика, тексты, документация, оригинальная структура базы данных, фотографии, шрифты и иные материалы. Права на разные части могут принадлежать разным лицам.

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

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

Ошибка 6. Думать, что переработка автоматически устраняет права на прежнюю версию. 

Смена технологии, новый внешний вид или значительная переработка не всегда создают полностью независимый продукт. Если в новой версии сохранены охраняемые элементы прежней программы, она может считаться производным произведением.

Автор переработки обладает правами на собственный творческий вклад, но должен учитывать права на исходный материал. Поэтому для каждой значимой версии желательно фиксировать, на какой основе она создана, кто участвовал в работе, какие части были заимствованы, какие сторонние материалы использованы и на каком основании компания вправе ими распоряжаться.

Фраза «мы все написали заново» сама по себе ничего не доказывает. При споре потребуются конкретные версии программы и объективная история их создания.

Ошибка 7. Начинать собирать доказательства только после увольнения. 

После ухода сотрудника часть сведений часто теряется: учетные записи закрываются, переписка удаляется, устройства очищаются, а коллеги не помнят содержание старых задач. Восстановить историю можно, но надежность таких доказательств придется отдельно объяснять.

Гораздо проще заранее сохранять:

• должностные инструкции и задания;
• историю изменений программы;
• документы о проверке и приемке результатов;
• договоры и акты с внешними исполнителями;
• перечень сторонних материалов и лицензий;
• сведения о выпущенных версиях;
• подтверждение передачи кода, документов и доступов при увольнении.

Для наиболее важных версий можно создавать архивные копии, состояние и дату которых возможно подтвердить позднее. Доступ к исходному коду также следует предоставлять только тем сотрудникам, которым он необходим для работы, а действия пользователей — сохранять в журналах системы.

Какие документы действительно помогают?

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

С внешними исполнителями нужен письменный договор, который не просто описывает услуги, а прямо регулирует права на результат. Если разработка началась до появления компании, права первых авторов следует оформить отдельно. Личные разработки, созданные раньше, также лучше заранее перечислить, чтобы впоследствии не спорить, вошли ли они в продукт компании.

Документы должны соответствовать реальности. Нельзя задним числом превратить личный проект работника в служебное произведение только потому, что это удобно компании. Но и отсутствие отдельного бумажного приказа не лишает работодателя прав автоматически, если служебный характер работы подтверждается совокупностью достоверных материалов.

Если необходимо сравнить две программы

Такое исследование следует начинать не с общего вопроса «похожи ли продукты», а с определения конкретных версий и спорных элементов. Специалист может изучить исходный код, структуру, последовательность изменений, комментарии и характерные совпадения, предварительно исключив общедоступные и автоматически созданные части.

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

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

Публикация отражает состояние законодательства на 2 августа 2026 года, предназначена для общего ознакомления и не заменяет анализ конкретной ситуации.