Доступ к репозиторию не даёт компании права распоряжаться кодом, который в нём хранится. Один модуль могли написать штатные разработчики, другой — подрядчик, третий может включать стороннюю библиотеку. Для каждого случая нужны свои основания использования. Если документы не привязаны к версиям продукта, разбираться в правах придётся в неудобный момент: перед поставкой клиенту, сделкой с инвестором или спором с бывшим участником команды.
Поэтому управление интеллектуальной собственностью в IT-компании не сводится к хранению договоров. Команде нужен порядок, который помогает выяснить происхождение значимых частей продукта, допустимые способы их использования и того, кто отвечает за изменения. Особенно если продукт часто обновляется, а над ним работают сотрудники, подрядчики и внешние правообладатели.
Что включить в карту активов
Составьте перечень того, что компания создаёт, покупает, лицензирует или предоставляет другим лицам. При этом разделяйте объект и место его хранения: исходный код не равен серверу, а права на дизайн не возникают лишь потому, что макет лежит в корпоративном аккаунте.
- Программные активы: исходный и объектный код, собственные библиотеки, скрипты, архитектурные и пользовательские интерфейсы, документация.
- Данные и материалы: базы данных, подборки и структура данных, тексты, графика, аудио, обучающие материалы. Разные виды информации охраняются по-разному, поэтому их правовой режим нужно определять отдельно.
- Средства индивидуализации: названия продуктов, логотипы и другие обозначения, под которыми компания или её сервисы выходят на рынок.
- Закрытые знания: технические решения, настройки, методики и коммерческая информация, для которых может быть важен режим конфиденциальности.
- Внешние компоненты: библиотеки, шрифты, изображения, API и другие ресурсы, используемые с разрешения третьих лиц.
По каждому активу запишите название, версию или ссылку на проект, назначение, создателей и поставщиков, основание использования и известные ограничения. Добавьте место хранения подтверждающих документов и ответственного внутри компании. Не нужно описывать каждую строку кода: карта должна помогать быстро выяснить, на каком основании компания выпускает, меняет или передаёт конкретную часть продукта.
Как связывать права с результатом работы
Сотрудники и подрядчики
В работе с сотрудниками общей фразы «всё созданное принадлежит компании» недостаточно. Документы и рабочий процесс должны позволять установить, что было поручено, кто и когда создал результат, входила ли эта работа в обязанности сотрудника и что компания приняла. Правила о служебных произведениях и вознаграждении зависят от применимого права и обстоятельств работы. Восстановить историю помогают постановки задач, изменения в коде, документация к релизам и кадровые документы — при условии, что они соответствуют тому, как разработка устроена на деле.
С подрядчиком возникает другой риск: оплаченный счёт и полученные файлы ещё не всегда означают, что компания приобрела исключительное право. В документах стоит различать передачу права и разрешение использовать результат, указывать конкретные результаты, способы использования, момент перехода права или начала лицензии и возможность доработки. Если подрядчик привлекает помощников, нужно понимать, как оформлены права на их вклад. Договор, который нельзя связать с заданиями, переданными файлами и актами, оставляет этот вопрос открытым.
Совместная разработка и предыдущие наработки
Разработчик может принести в проект код, написанный раньше, а подрядчик — включить в заказанную систему свой универсальный модуль. Такие наработки не стоит автоматически считать частью передаваемого результата. Обозначьте их отдельно и согласуйте, как компания вправе их использовать, в том числе при поддержке продукта после прекращения сотрудничества.
Если сервис совместно разрабатывают несколько компаний, заранее определите вклад и полномочия каждой стороны: кто выпускает обновления, лицензирует продукт, даёт доступ аффилированным лицам и защищает права при нарушении. Формулировка «права принадлежат сторонам совместно» без порядка принятия решений способна задержать даже обычный релиз.
Одна таблица прав для продукта, а не разрозненные папки
Реестр удобно вести по продукту и его существенным частям. Для каждой записи важно видеть не просто правообладателя, а то, что компания вправе делать сейчас. Например, макет можно использовать в приложении, но не в печатной рекламе; стороннюю библиотеку — распространять при соблюдении лицензии; материалы клиента — применять только для выполнения его заказа.
| Поле реестра | Что записать |
|---|---|
| Актив и версия | Модуль оплаты, версия релиза или период разработки |
| Происхождение | Команда, подрядчик, правообладатель стороннего компонента |
| Правовое основание | Договор, документы о служебном результате, лицензия |
| Пределы использования | Разрешённые действия, срок, территория, условия распространения |
| Доказательства | Задание, переданные файлы, акт, переписка, сведения о версии лицензии |
| Владелец процесса | Сотрудник, который обновляет запись и инициирует проверку |
Запись в реестре не создаёт права и не заменяет договор. Зато она показывает пробелы: скажем, компонент уже вошёл в коммерческий релиз, а подтверждение лицензии относится к другой версии. Доступ к реестру нужен разработке, продуктовой команде и тем, кто согласует договоры. Конфиденциальные сведения при этом следует открывать с учётом рабочих ролей.
Контроль сторонних компонентов без торможения разработки
Проверяйте внешние материалы до включения в основную ветку или публикации, а не после претензии. Для компонента фиксируйте название, источник, версию, условия использования, способ интеграции и место применения. В случае свободного ПО одного названия лицензии мало: обязанности могут зависеть от того, как компонент используется и распространяется. Для платных сервисов и API важны также ограничения аккаунта, объёма использования и предоставления доступа клиентам.
Найденный в интернете файл нельзя брать в продукт лишь потому, что рядом с ним нет запрета. Если подтвердить права на иконку или изображение не получается, лучше заменить материал либо получить разрешение. С клиентскими файлами действует та же логика: разрешение обработать материал для заказа не обязательно даёт право показывать его в портфолио.
От внутренних прав к условиям для клиентов
Компания может предоставить клиенту лишь тот объём прав, которым располагает сама. Обещание «полной передачи всех прав на систему» рискованно, если в ней есть сторонние библиотеки, ранее созданная платформа компании или лицензированные изображения. В клиентском договоре нужно разграничить собственные разработки, индивидуальный результат и сторонние элементы, а затем определить права клиента на использование, изменение и передачу доступа другим лицам.
Для сервиса по подписке условия обычно строятся иначе: клиент получает доступ к программе, а не исключительное право на неё. Договор должен совпадать с тем, как сервис работает на практике: можно ли выгрузить данные, использовать интеграции, подключать подрядчиков клиента и что происходит после прекращения доступа. Споры нередко начинаются там, где обещанная клиенту свобода использования расходится с правами самой компании.
Охрана активов, которые нельзя просто «передать по акту»
Название продукта, домен и товарный знак выполняют разные функции. Регистрация домена не заменяет проверки и оформления прав на обозначение. То, что название видно в интерфейсе, само по себе не решает вопрос о его охране в нужных странах и категориях продуктов. Для важных брендов назначьте ответственного за проверку новых названий, заявки, продления и единообразное использование обозначений.
Пометка «конфиденциально» также не сделает техническое решение секретным сама по себе. Определите, какую информацию нужно закрыть, кто получает к ней доступ, как она передаётся подрядчику и что происходит после завершения проекта. Если компания рассчитывает на охрану секрета производства, режим конфиденциальности необходимо выстраивать по требованиям применимого права. Публикация описания решения до оценки вариантов охраны может сузить выбор дальнейших мер.
Когда обновлять реестр и кто принимает решение
Назначьте владельца процесса. Ему не требуется лично проверять каждый коммит, но он должен следить за контрольными точками. Юрист оценивает документы и ограничения, технический руководитель — состав продукта, продуктовый менеджер сообщает о новых способах использования. У решения по спорному компоненту должны быть автор и дата: иначе через несколько релизов будет трудно понять, почему его приняли.
- При запуске задачи отмечайте, создаётся ли новый охраняемый результат и нужны ли внешние материалы.
- Перед приёмкой сверяйте задание, переданные файлы, участие соисполнителей и документы о правах.
- Перед релизом проверяйте новые зависимости, контент, название функции и обещания клиентам.
- При изменении модели продаж пересматривайте права: внутренняя система, облачный сервис и экземпляр, поставляемый клиенту, могут требовать разных действий с компонентами.
- При уходе участника команды проверяйте передачу рабочих материалов и прав доступа. Это отдельная процедура, не решающая сама по себе вопрос о принадлежности созданных результатов.
Небольшой команде может хватить реестра с обязательными полями и правила: компонент с неустановленным происхождением не включают в релиз. С ростом компании автоматизация поможет собирать данные о зависимостях и версиях, но договоры и фактический способ использования всё равно придётся проверять.
Что делать с обнаруженным пробелом
Если документов не хватает, выясните, затронут ли уже выпущенный продукт и для каких действий компании необходимо спорное право. Сохраните имеющиеся договоры, задания, историю версий и переписку; не меняйте задним числом даты или состав результата. Дальше выбирайте действие по ситуации: запросить подтверждение или лицензию, оформить отношения с автором, заменить компонент, ограничить его использование либо отложить поставку. При возможном конфликте с правообладателем план лучше согласовать индивидуально.
Допустим, команда собирается предлагать модуль отчётности отдельным клиентам. Сопоставьте его версию с заданиями разработчиков, правами на графику и лицензиями библиотек. Затем проверьте, разрешена ли именно поставка клиенту. Если лицензия подтверждает только использование библиотеки внутри сервиса, общий договор на разработку не устранит этот пробел.
Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию. Вывод о правах зависит от применимого права, документов и фактической истории создания продукта.