Как правильно оформлять РИДы в ИТ-проектах, чтобы не создавать спорных ситуаций
При передаче прав заказчику общим понятием «сайт» или «приложение» не обойтись. Особенно если к проекту подключены сразу несколько подрядчиков. Клиент должен знать, кто и за что отвечает, а мы — гарантировать правовое использование всех уникальных объектов, что сделаны именно нами.
Меня зовут Светлана Мицкевич, я занимаюсь документооборотом в веб-продакшене Далее. В этой статье вы получите подробный гайд о том, как выявить и оформить РИДы.
В чем проблема?
Представьте, что вы реализовали уникальный сервис расчета в огромном маркетплейсе, над которым работали несколько подрядчиков. Клиент собирается развить этот сервис и переиспользовать на другом проекте. Для этого хочет найти конкретного исполнителя среди всех, т.е. вас.
А теперь иная ситуация — вы взяли сайт на поддержку и включили в UI новый кастомный модуль. Заказчик приходит к вам, как к последнему подрядчику, получив претензию от третьих лиц за использование изображения в другом блоке.
И в первом, и во втором случае проблем не будет, если у вас в документации прописаны все результаты интеллектуальной деятельности, а не общее «все, что создано в рамках сотрудничества». Но сложность в том, что команды и сами не всегда понимают, когда на проекте появляются РИДы и как правильно их оформить.
Как понять, есть ли в проекте РИД
В процессе работы над проектом мы создаем не только платформу целиком, но и десятки авторских решений. Результат интеллектуальной деятельности — это любой объект, который содержит творческий вклад автора, обладает оригинальностью и существует как самостоятельный итог: код, макет, текст, архитектура.
Например, техническая поддержка сайта: обновления, правки, настройка окружения без создания нового результата.
Что является РИДом
В разработке наиболее наглядные примеры РИД — в веб-дизайне. Если дизайнер использует стандартные компоненты шаблона, типовую сетку и готовые иконки, то с юридической точки зрения он оказывает услугу по верстке. РИД, требующий отдельной передачи прав, не возникает. А вот когда под проект рисуются собственные иллюстрации и появляется оригинальное сочетание элементов — это уже результат интеллектуальной деятельности, который требует передачи прав.
Если для интернет-магазина кофе дизайнер создает UI-kit и рисует собственный набор иконок в виде кофейных зерен, турок и сифонов — это РИД. А стандартная иконка корзины из UI-набора — нет.
С кодом ситуация сложнее и вызывает больше споров. Сам по себе факт написания кода еще ничего не значит. Большая часть проектов строится на фреймворках, CMS и библиотеках — и это нормально. Но как только в проекте появляется нестандартная логика, собственные алгоритмы, нетипичные сценарии обработки данных, этот код перестает быть просто «технической частью» и становится РИДом.
Например, для интернет-магазина эко-товаров разрабатывается «эко-калькулятор», который считает вклад пользователя в экологию на основе его покупок. В этом случае РИДом будут:
- уникальный код бизнес-логики и алгоритмов,
- уникальный код кэширующего декоратора для тяжелых запросов,
- уникальный код анимированного React-компонента.
А вот подключение готового плагина без изменений — РИДом не считается.
Контент — еще один очевидный, но часто недооцененный блок. Тексты, кастомные иллюстрации и фотографии, сделанные для конкретного сайта, — все это охраняется законом об интеллектуальной собственности.
Когда специалист скачивает фото со стока и вставляет его в макет, сама картинка — чужой РИД, взятый по лицензии. Новый РИД здесь — сам макет страницы сайта или баннера, где дизайнер творчески переработал изображения и включил в оригинальную дизайн-концепцию.
Самая тонкая зона — архитектура и пользовательские сценарии. Общие принципы юзабилити не охраняются законом. Но если в проекте: нестандартные сценарии взаимодействия, уникальная логика переходов, особые реакции системы на поведение пользователя — это уже не просто «удобно», а результат интеллектуальной работы команды.
Например, система образовательной платформы при серии ошибок предлагает разные сценарии помощи и активирует специальные интерфейсные элементы — это полноценный РИД.
Не является РИДом в разработке
Проверим, насколько легко распознать на проекте РИД?
Общий контекст — команда делает сервис онлайн-записи в фитнес-клубы FitRoom. Это типичный продукт: лендинг для привлечения пользователей, личный кабинет для записи на тренировки и админка для клубов. Проект коммерческий, с планами на развитие и масштабирование.
Какие результаты интеллектуальной деятельности возникают в таком проекте?
Задача 1. Дизайнер Маша работает над интерфейсом FitRoom в Figma.
Маша использует готовый UI-кит и набор иконок Material UI Icons с лицензией MIT. Для лендинга берет изображения с Shutterstock — лицензия оформлена на агентство. При этом саму структуру экранов Маша продумывает с нуля. Она решает, как пользователь будет выбирать клуб, видеть расписание, записываться на тренировку, отменять или переносить запись. В техническом задании от заказчика есть только описание функций — никаких готовых визуальных решений.
Задача 2. Разработчик Миша делает фронтенд на React, использует Redux Toolkit, React Hook Form и date-fns.
Сам фреймворк Миша, конечно, не пишет. Но он реализует кастомную бизнес-логику: создает хук useBookingSlots, который рассчитывает доступные слоты, пишет алгоритм проверки пересечений записей, логику отмены и переноса тренировок. В ТЗ описано, что должно работать, но как — решает он сам.
Задача 3. Редактор Иван готовит контент с использованием AI.
Заказчик дает Ивану материалы: описание сервиса, список функций, ответы на частые вопросы. Тексты сырые, разрозненные и явно не готовы для публикации. Иван переписывает их, выстраивает структуру лендинга, выделяет преимущества, пишет тексты кнопок и подсказок в интерфейсе. Для FAQ он использует AI, но перерабатывает ответы, меняет формулировки, структуру и тон.
Задача 4. Команда продумывает архитектуру и пользовательские сценарии.
Архитектор предлагает разделить систему на сервисы — BookingService, UserService и ClubService, описывает взаимодействие между ними, продумывает кэширование расписаний и поведение системы при высокой нагрузке.
Собрав задачи вместе, становится видно, почему с РИД так много путаницы в реальных проектах. Каждый результат зависит от того, как было поставлено задание и какую свободу решений получил исполнитель. Но даже подробное ТЗ может как свести нашу работу к чистой реализации без возникновения РИД, так и оставить место для творческого вклада.
Из-за этого невозможно один раз выучить правило вроде «дизайн — это всегда РИД» или «код — всегда авторский». Любой проект приходится смотреть в динамике: что именно создается и кто принимает решения.
Ответственность за это несет PM. Как руководитель проекта, он должен выявить РИДы. После чего — передать инсайдерскую информацию специалисту по документообороту, который зафиксирует их письменно и юридически верно.
Документация, подтверждающая РИДы и передачу исключительных прав заказчику
В заказной разработке РИДы идут в неразрывной связи с отчуждением исключительных прав на них клиенту. Все оформляется через последовательную цепочку из договора, приложения и акта. В каждом документе свои нюансы. В одном мы прописываем общие положения и ответственность, во втором — подробный список работ. Третьим обозначаем факт создания РИДа и передачи прав.
1. В рамочный договор включаем раздел «Интеллектуальная собственность» или «Авторское право». Здесь закрепляем концептуальные положения.
Если вы планируете подключить к проекту искусственный интеллект, то не забудьте сразу урегулировать момент и со сгенерированным контентом. Необходимо зафиксировать, что при использовании ИИ:
- результат может не обладать признаком оригинальности;
- допускается частичное или полное совпадение продукта с результатами, сгенерированными для других лиц;
- существует риск непреднамеренного заимствования материалов, защищенных правами третьих лиц.
2. В приложении к договору включаем развернутое описание работ. Так и у нас, и у клиента есть детальная спецификация требований к конечному продукту. С помощью четкого определения видов работ в конце мы сможем однозначно идентифицировать созданные РИДы и отделить их от типовых задач.
3. Акт сдачи-приема работ — наш правоустанавливающий документ. Он фиксирует факт создания конкретных объектов, их передачу заказчику и момент перехода исключительного права. Наличие этого документа подтверждает, что права на код, дизайн и контент перешли к конечному владельцу в полном объеме.
Вот шаблоны дополнительного соглашения и акта, которые мы используем в своей работе.
Сегодня клиенты уже сами приходят с запросом на документы по РИД: юристы проверяют договоры, бизнес взрослеет, требования к прозрачности растут. При этом у крупных компаний есть свои правила оформления, под которые нужно подстраиваться.
Но даже если заказчик не задает детальных вопросов про итоговый результат, имеет смысл проговорить:
- какие объекты создаются в проекте,
- как на них передаются права,
- какими документами это фиксируется.
Здесь речь не про формальность, а про здоровую практику, которая вносит дополнительный бонус в спокойствие и уверенность клиента. Да, бумажная волокита — не самое интересное занятие, но именно она может стать одним из критериев выбора подрядчика. Особенно в В2G.
А как вы выявляете и оформляете РИДы на своих проектах? Сталкивались со специфическими требованиями клиентов?