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