Исходный код и права на ИС: почему владение кодом не означает владение правами
Быстрый ответ: Владеть исходным кодом (иметь файл, доступ к репозиторию, копию на флешке) и владеть правами на него это разные вещи. В России код охраняется авторским правом с момента создания, а исключительное право на ИС определяется договором, лицензией и статусом разработки (например, служебная). Если не закрепить права письменно, легко получить спор, блокировку релиза и риск нарушения прав на ИС.
Однажды мне показали «доказательство владения продуктом» в виде архива с GitHub: «Вот же, у нас весь исходный код, значит наш». Архив был свежий, папки аккуратные, даже README написан человеческим языком. А потом выяснилось, что подрядчик доступ выдал, да, но права не передал. И внезапно это не актив компании, а потенциальная головная боль в два клика: «удалю доступ», «отзову лицензию», «пойду в суд».
С кодом вообще забавно: он лежит на диске, весит мегабайты, выглядит как вещь. И мозг автоматически думает, что это «наше имущество». Но право в ИС живёт не в папке проекта, а в бумагах и формулировках. Без них вы можете хоть распечатать репозиторий на принтере и обклеить офис, это не добавит вам права изменять, распространять или продавать продукт.
После чтения у вас будет понятная схема, как проверить, кому принадлежит исключительное право на ИС в отношении кода, как оформить отношения с разработчиками и подрядчиками, как не нарваться на конфликт из серии «код есть, а прав нет данных права на ис», и где искать официальную правовую информацию и нормативную правовую информацию, если хочется опереться не на слухи из чатов, а на реальную базу.
Почему владение исходным кодом не равно владению правами?
Потому что исходный код в России охраняется авторским правом как литературное произведение с момента создания в объективной форме. Это прямо разбирается, например, в материале Андрея Васильева «Правовой статус исходного кода: между коммерческой тайной, авторским правом и открытой лицензией» (vc.ru). Правообладатель получает исключительное право на использование, распространение и модификацию кода, и оно не «переезжает» к вам вместе с zip-архивом или доступом к GitLab. Вот почему фраза «нам прислали исходники» сама по себе ни о чем не говорит.
Короткий ответ: Файл с кодом можно держать в руках, а исключительное право на ис держится на договоре и нормах права, а не на флешке.
Как пошагово проверить и оформить права на исходный код в России?
Шаг 1. Как понять, кто автор и кто правообладатель прямо сейчас?
Сначала фиксируем факты: кто писал код, в каком статусе, по каким задачам, в какие сроки и где это обсуждалось. Поднимаем переписку, тикеты, коммиты, договоры, счета, акты. Зачем это нужно: автором почти всегда будет физлицо, а правообладателем может быть компания, заказчик или сам разработчик, в зависимости от условий. Типичная ошибка здесь простая: «раз платили, значит наше». Платили за работу, а не обязательно за отчуждение исключительного права на ис.
Проверка, что всё работает: вы можете в одном абзаце объяснить цепочку прав от автора к бизнесу и показать документ, на котором она держится. Если вы начинаете путаться и уходить в «ну там в переписке было», значит у вас не правовая информация, а впечатления. Кстати, если нужен ориентир по терминам и базовым нормам, смотрите официальная правовая информация на официальном портале правовой информации и в любой нормальной системе правовой информации, там быстрее отсекаются мифы.
Короткий ответ: Если вы не можете показать документ, который передает права, то с высокой вероятностью исключительное право осталось у автора или подрядчика.
Шаг 2. Как отличить служебный код от «написал ночью для себя, но в офисе»?
Если код создавался работником в рамках трудового договора, результат обычно квалифицируется как служебное произведение, и права на программу принадлежат работодателю, если договором не предусмотрено иное. Это подробно обсуждают в статье на Хабре «Права на код и приложения: как ИТ-компании защитить интеллектуальную собственность и выстроить отношения с разработчиками» (habr.com). Зачем вам это различие: оно решает судьбу продукта, особенно если сотрудник уходит и уносит с собой «свой» модуль, который внезапно оказался ядром системы.
Типичная ошибка: считать служебным всё, что сделано человеком, который числится в штате. На практике ломается на формулировках обязанностей, заданиях, доказательствах постановки задач и том, было ли создание конкретного ПО предусмотрено трудовой функцией. Проверка, что всё работает: у вас есть трудовой договор, должностная инструкция, положение о создании результатов ИС (если есть), и в документах видно, что разработка ПО входит в обязанности или была отдельная служебная задача.
Короткий ответ: «Служебное» определяется не настроением работодателя, а документами и тем, входила ли разработка в трудовые обязанности.
Шаг 3. Как оформлять права с подрядчиком, чтобы потом не было «мы же оплатили»?
С подрядчиком самое скользкое: он может передать вам исходники, настроить CI, даже показать, как деплоить, но это всё ещё не означает передачу исключительного права. На vc.ru в том же разборе про правовой статус исходного кода отдельно подчеркивается: владение исходным кодом не дает автоматического права на его использование или распространение, права определяются лицензией или договором. Зачем это проговаривать: иначе в момент масштабирования вы узнаете, что не можете легально переработать продукт или передать его инвестору.
Типичная ошибка: подписать акт «услуги оказаны» без блока про отчуждение прав или лицензию, а потом удивляться, почему подрядчик требует доплатить «за права». Проверка, что всё работает: в договоре есть либо отчуждение исключительного права на ПО, либо лицензия с понятными способами использования, территорией, сроком, возможностью модификации и передачи прав. И да, полезно держать под рукой интернет правовой информации и вопрос правовая информация по формулировкам: иногда один абзац спасает месяцы нервов.
Короткий ответ: Оплата работ не равна покупке прав. Права живут в разделе договора, а не в счете.
Шаг 4. Что делать с открытым исходным кодом и лицензиями, чтобы не устроить себе нарушение прав на ис?
Опенсорс часто выглядит как бесплатный буфет: бери что хочешь, главное не урони тарелку. Но лицензии там разные, и условия тоже разные: где-то нужно сохранять уведомления об авторстве, где-то раскрывать модификации, где-то нельзя использовать товарные знаки проекта. Зачем это учитывать: несоблюдение условий лицензии легко превращается в нарушение прав на ис, а потом продукт приходится срочно переписывать. В кейсах из индустрии нередки истории, когда компания использовала открытый код без соблюдения лицензии и в итоге получила разбирательство и переделку части ПО.
Типичная ошибка: «у нас же кусочек, кто заметит». Заметят. Особенно когда у вас релиз в маркетплейсе, публичный SDK или вы открыли клиентский код. Проверка, что всё работает: вы можете перечислить ключевые зависимости, их лицензии и показать, как вы выполняете условия. Сейчас есть тренд на инструменты для проверки соблюдения лицензий, и он не просто так появился: кодовых баз много, ручками следить тяжело.
Короткий ответ: Открытый код не значит «ничей». У него почти всегда есть лицензия, и её условия надо выполнить.
Шаг 5. Как закрепить режим доступа к коду и не перепутать его с правами?
Доступ к репозиторию это просто доступ. Сегодня он у вас, завтра его нет, особенно если проект жил в аккаунте разработчика или подрядчика. Зачем наводить порядок: контроль доступа влияет на безопасность и на доказательства, но сам по себе не создает исключительное право на ис. Типичная ошибка: хранить всё в «личном Git» тимлида и считать, что этого достаточно, ведь компания платит зарплату. А потом тимлид уходит, и начинается сериал «восстановите доступ, пожалуйста».
Проверка, что всё работает: репозитории оформлены на юрлицо, есть регламент по доступам, резервные копии, и отдельно оформлены права на результаты ИС. Здесь хорошо помогает информационно правовая информация из внутренних политик плюс нормальная нормативная правовая информация из официальных источников, чтобы не изобрести регламент, который противоречит здравому смыслу.
Короткий ответ: Админ-доступ к Git это не документ о правах. Он решает «могу зайти», но не «имею право использовать».
Шаг 6. Как подготовиться к сделке, инвестору или конфликту: доказательства и «бумажная гигиена»
Если вы собираетесь продавать продукт, привлекать инвестиции или просто выходить из «гаражной» стадии, цепочка прав проверяется первой. Зачем: никто не хочет купить спор или зависимость от бывшего подрядчика. Типичная ошибка: начинать собирать документы за неделю до due diligence, а потом выяснять, что у части кода вообще нет данных права на ис, потому что разработчики менялись, договоров нет, а коммиты анонимные.
Проверка, что всё работает: у вас лежит единый пакет документов, и вы внятно показываете, что исключительное право на ис у вашей компании или у вас как у правообладателя. Мини-кейс из жизни: стартап на два основателя и одного фрилансера за три месяца собрал MVP, автоматизировали выставление счетов и интеграцию с CRM. Когда пришли к партнёру, выяснилось: фрилансер отдавал код, но права не отчуждал. Потратили ещё пару недель на допсоглашение и переподписание актов, зато потом разговор пошёл бодрее.
Короткий ответ: Самая дорогая бумага это та, которую вы не подписали вовремя.
Какие подводные камни чаще всего ломают процесс?
Первый камень это иллюзия, что «всё очевидно и так». В ИТ очевидно только то, что у всех дедлайн. Служебные произведения, лицензии, отчуждение, право использования, право на переработку, право на распространение: это скучные слова ровно до первой претензии. И да, когда начинается спор, внезапно всем нужна 1 правовая информация, официальная правовая информация, портал правовой информации, официальный портал правовой информации, и желательно вчера. Лучше не доводить до состояния «срочно ищем юриста, потому что релиз завтра».
Второй камень это смешение ИС и бренда. Люди часто параллельно делают приложение, телеграм-канал, сообщество, и используют одно название везде. Потом выясняется, что код вроде бы ваш, а название уже занято или слишком похоже на чужое. Если вы как раз думаете о названии и товарном знаке, полезно посмотреть: можно ли зарегистрировать как товарный знак название своего сообщества и как зарегистрировать товарный знак для самозанятых. Это про разные сущности: код охраняется авторским правом, а бренд обычно защищают товарным знаком.
Третий камень новый и неприятный: генерация кода моделями и «похожесть» фрагментов. Исследование «LiCoEval: Evaluating LLMs on License Compliance in Code Generation» (Weiwei Xu, Kai Gao, Hao He, Minghui Zhou, arXiv) показывает риск: модели могут выдавать код, схожий с существующим, без указания лицензии, и это тянет вопросы по соблюдению условий. Не надо впадать в паранойю, но нужно понимать, что контроль лицензий и происхождения фрагментов становится отдельной задачей. Если вы уже защищаете бренд, то по обозначениям тоже есть нюансы: вот короткое видео про то, как проверить обозначение на сходство, и ещё про разницу между тождественностью и схожестью до степени смешения.
Кому и зачем стоит оформлять ИС «по-взрослому», а не по ощущениям?
Если вы продуктовая команда, студия разработки, самозанятый, который растёт в мини-агентство, или бизнес, который нанял разработчиков в штат, оформление прав почти всегда экономит время. Не в смысле «станете богатыми», а в смысле «не будете неделями выяснять, кто кому что должен», когда горит релиз, меняется подрядчик или приходит крупный заказчик с юридическими вопросами. Хорошо работает формат, когда вам помогают собрать цепочку прав, привести договоры к нормальному виду и подсказать, где вы сами себе поставили капкан формулировками.
А ещё рядом обычно стоит бренд: название, логотип, классы МКТУ, планы на расширение. Если вы на этой стадии, посмотрите: как зарегистрировать торговую марку в России, регистрация товарного знака сроки и стоимость, и отдельно про визуальную часть: как запатентовать логотип и сколько стоит? и как запатентовать название бренда и логотип в России? По классам тоже вечная боль, там есть полезная подсказка: как правильно выбрать классы МКТУ. Если хочется держать руку на пульсе новостей и практики, подпишитесь на Телеграмм канал Патентного бюро Лирейт», там часто разбирают кейсы без занудства.
Ссылки, которые часто спрашивают «куда нажать»: Регистрация товарного знака, Монополия на бренд, Юридическая защита интеллектуальной собственности. И да, когда вы собираете правовую позицию, полезно опираться на систему правовой информации и официальный портал правовой информации, а не на пересказ в сторис.
FAQ
Вопрос: Если мне передали репозиторий и доступы, значит я могу делать с кодом что угодно?
Ответ: Нет. Доступ это техническая возможность, а право использования определяется лицензией или договором. Без них вы рискуете выйти за пределы разрешенного и получить претензию.
Вопрос: Когда возникает авторское право на исходный код в России?
Ответ: С момента создания кода в объективной форме. Исходный код охраняется авторским правом как литературное произведение, об этом пишет, например, Андрей Васильев на vc.ru.
Вопрос: Я работодатель. Всё, что написал сотрудник, автоматически моё?
Ответ: Чаще всего служебное ПО действительно переходит работодателю, если создано в рамках трудовых обязанностей и договором не установлено иное. Но «автоматически» ломается, когда нет документов, заданий и ясной трудовой функции.
Вопрос: Как не попасть в нарушение прав на ис из-за опенсорса?
Ответ: Читать лицензии и выполнять их условия: уведомления, раскрытие модификаций, ограничения на использование. Лучше заранее настроить проверку зависимостей, чем потом переписывать модуль в спешке.
Вопрос: Где искать официальная правовая информация и нормативная правовая информация, чтобы не гадать?
Ответ: Начните с официального портала правовой информации и проверенной системы правовой информации. Там проще сверить формулировки и понять, что реально написано в норме, а что додумали в чатах.
Вопрос: Если код сгенерирован с помощью генератора, это снижает риски по лицензиям?
Ответ: Не обязательно. Есть исследования (например, LiCoEval на arXiv), где отмечают, что модели могут выдавать похожий код без указания лицензии, и это создает риск несоблюдения условий. Контроль источников и зависимостей всё равно нужен.
Вопрос: Что делать, если в проекте «нет данных права на ис» и уже скоро релиз?
Ответ: Быстро собрать цепочку: кто авторы, какие договоры, что именно передавалось, и оформить недостающие соглашения. Чем раньше вы это сделаете, тем меньше шансов, что релиз встанет из-за спора о правах.