HIF / Документация / Управление правами

Право, интеллектуальная собственность и платформенные референсы

Статус: нормативная основа governance

Версия: 0.1

1. Назначение и граница

Этот документ определяет, как продукт HIF учитывает правовые обязанности, интеллектуальную собственность, референсы сторонних платформ и доказательства прав до выпуска дизайна или реализации.

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

Основной принцип:

Изучение соглашения не даёт права копировать его выражение.

Публичная видимость, техническая доступность, включение в SDK, руководство по дизайну, публикация в app store, open-source-лицензия на код, образовательная цель или отсутствие знака copyright MUST NOT считаться разрешением.

2. Неизменяемые требования

Каждый продукт MUST:

  1. определить юридические лица, целевые рынки и каналы распространения;
  2. вести актуальный профиль правовых и платформенных обязанностей;
  3. вести записи о происхождении и правах на каждый сторонний input;
  4. отдельно очищать права на код, визуальные assets, шрифты, текст, данные, звук, motion, бренды и ресурсы платформ;
  5. сохранять точные тексты лицензий, разрешения, версии и даты получения;
  6. реализовывать обязательные notices, attribution, предоставление исходников и раскрытия;
  7. отделять функциональные требования от скопированного визуального выражения;
  8. останавливать непроверенные референсы высокого риска до реализации;
  9. получать проверку специалиста, когда документ требует решения юриста;
  10. хранить доказательства выпуска в течение сроков поддержки и давности продукта.

Ни дизайнер, ни разработчик, ни аудитор, ни клиент, ни автоматический инструмент MAY самостоятельно одобрить собственное high-risk исключение.

3. Стек прав

Один интерфейс может одновременно затрагивать несколько независимых режимов. Очистка по одной строке не очищает остальные.

СлойПримеры в интерфейсной работеВопрос, на который нужен ответ
Copyrightкод, экранная графика, тексты, иконки, фотографии, иллюстрации, animation, audio, документацияВладеем ли мы этим выражением или имеем разрешение именно на такое использование?
Зарегистрированные и незарегистрированные designs; design patentsвнешний вид GUI, иконки, переходы, ornamentation, layoutМожет ли общий визуальный образ или заявленный дизайн охраняться на целевом рынке?
Trade marks и service marksназвания, логотипы, продуктовые иконки, badges, slogansРазрешено ли использование, является ли оно референсным и исключает ли впечатление об источнике, связи или одобрении?
Trade dress, passing off и unfair competitionузнаваемый вид продукта, упаковки, сайта или семейное сходствоМогут ли люди решить, что продукт выпущен, одобрен или связан с другой организацией?
Utility patentsтехнические способы взаимодействия, обработки и поведения системыРеализует ли продукт действующий patent claim в соответствующей территории?
Договорусловия SDK, API, store, beta, design resources, marketplace и serviceПриняла ли организация ограничения, которые строже того, что само по себе могло бы допускаться copyright law?
Open-source и source-available лицензиибиблиотеки, темы, компоненты, templates и build toolsСовместимы ли условия использования, изменения, notices, attribution, исходников и распространения?
Лицензии шрифтовdesktop-установка, web-раздача, embedding в app или документ, изменение и subsettingРазрешает ли точная лицензия каждый формат, канал, число пользователей и модель распространения?
Права на данные и базынаборы данных, карты, каталоги, поисковые результаты, аннотации и обучающие корпусаРазрешены ли сбор, извлечение, повторное использование и распространение; нужна ли атрибуция?
Приватность и права личностипользовательские данные, лица, голоса, подписи, отзывы и образы людейЕсть ли правовое основание, полномочие, согласие или разрешение для этой цели и территории?
Moral rights и целостностьподписанные artwork, photography, тексты и adaptationsНужно ли указывать автора и допустимо ли менять работу?
Защита потребителей, доступность и отраслевые правилаархитектура выбора, цены, отмена, банки, здравоохранение, дети и государственные услугиВыполняет ли интерфейс применимые обязанности по поведению, раскрытию и равному доступу?

Проект MUST записать не применимо с причиной; пустая запись не является решением.

4. Функция, соглашение и выражение

Интерфейсам нужны общие соглашения. Действие назад, scrolling, окно, текстовое поле или список могут выполнять функциональную и interoperable-задачу. Это не создаёт универсальную safe harbour для конкретного рисунка, расположения, перехода, звука, названия или сочетания деталей.

Команда MUST различать:

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

Требования и design rationale SHOULD описывать первые три уровня, не предписывая выражение другого продукта. Новое решение MUST выводить своё выражение из контекста продукта, доказательств и принадлежащей ему дизайн-системы.

В HIF нет правила, по которому определённый процент отличий делает копирование безопасным. Pixel distance, смена цветов, mirroring, перерисовка, конверсия формата или замена нескольких компонентов сами по себе не устраняют риски infringement, confusion, договора или платформы.

5. Зоны решений по умолчанию

Эти зоны — внутренние risk controls, а не юридические выводы.

5.1 Зелёная — можно двигаться при наличии доказательств

Продукт MAY обычно продолжать работу, если заполнены все применимые записи, а результат:

  • независимо создан по собственному brief и документированным требованиям;
  • реализует привычное поведение через собственную визуальную систему продукта;
  • использует авторизованный публичный API платформы;
  • является точной версией стороннего компонента или asset с проверенной совместимой лицензией;
  • содержит правдивую текстовую ссылку на совместимость, разрешённую текущими brand rules;
  • заказан по письменному договору с передачей или достаточной лицензией нужных прав;
  • находится в public domain по применимому и документированному основанию.

Зелёный статус истекает при изменении artefact, лицензии, способа использования, территории, канала или ownership.

5.2 Жёлтая — остановить реализацию до проверки

Следующее требует документированной проверки прав и может требовать квалифицированного юриста:

  • близкое структурное или визуальное сходство с одним узнаваемым продуктом;
  • отличительное сочетание layout, typography, iconography, colour, material, motion, sound и терминологии;
  • воссоздание современной или исторической OS, устройства или приложения;
  • vendor screenshots, device frames, badges, product imagery или UI kits;
  • заявления о compatibility, certification, partnership или endorsement;
  • шрифт, набор значков, тема, шаблон или файл дизайна с неясными границами;
  • reverse engineering, исследование interoperability или protocol emulation;
  • generated content на основе защищённого или конфиденциального референса;
  • материал, полученный через login, subscription, beta или NDA;
  • сторонний код без лицензии, с custom license или несовместимыми обязательствами;
  • biometric, health, financial, child, precise-location и другие high-risk данные;
  • новый interaction mechanism в patent-sensitive domain;
  • предлагаемое исключение на основании fair use, fair dealing, quotation, parody, interoperability или другой зависящей от юрисдикции нормы.

Коммерческий срок не превращает жёлтый статус в зелёный.

Проект, соответствующий HIF, MUST NOT:

  • выпускать pixel clone или намеренно confusing imitation другого продукта;
  • использовать логотип, badge, product icon, slogan или typeface другой организации как собственную identity;
  • создавать ложное впечатление об affiliation, certification, sponsorship или endorsement;
  • извлекать, обводить, распространять или встраивать proprietary design resources за пределами лицензии;
  • использовать proprietary font или symbol set потому, что он установлен на устройстве одного участника;
  • копировать code, copy, artwork, sound, animation или data без установленного разрешения или правового основания;
  • удалять или скрывать copyright, attribution, trade mark или licence notices;
  • считать found online, free download, abandonware, educational или fan project статусом прав;
  • считать Git repository без лицензии open source;
  • считать одобрение app store доказательством прав;
  • пропускать restricted material через AI, tracing, conversion или redrawing, чтобы скрыть источник;
  • использовать материал клиента без записи о его полномочии и зависимости проекта от этого заявления;
  • обходить access controls, contractual restrictions или отказ в разрешении;
  • публиковать заявление о юридическом соответствии без одобрения для указанной области.

6. Правило платформенных референсов

Platform design guidance является доказательством соглашений своей платформы. Это не общая лицензия на воспроизведение assets, branding или trade dress.

До использования любой именованной экосистемы проект MUST создать platform record, включающий:

  • актуальные developer и programme agreements;
  • правила store и distribution;
  • лицензии design resources и templates;
  • лицензии fonts и icons;
  • trade mark и marketing guidance;
  • правила screenshots, device images и badges;
  • условия API и данных;
  • ограничения по территории, продукту и каналу;
  • версия, дата получения, ответственный и дата следующей проверки.

6.1 Apple

Интерпретация HIF по умолчанию:

  • Human Interface Guidelines описывают платформенные соглашения, но не дают общей лицензии на ресурсы или фирменное оформление.
  • Лицензия Apple Design Resources ограничивает поставляемые ресурсы макетами интерфейсов для software products, работающих только на указанных Apple OS. Она ограничивает non-Apple mock-ups, embedding, redistribution и другие work products.
  • San Francisco и другие Apple fonts имеют отдельные условия. Доступ к download не разрешает использование для Linux, Windows, web branding или общего redistribution.
  • Trademark guidance Apple допускает ограниченное правдивое referential use некоторых word marks для совместимости при выполнении условий. Оно в общем случае не разрешает Apple logo и принадлежащие Apple graphic symbols.
  • App Review Guidelines отдельно запрещают копирование, требуют права на материалы продукта и запрещают confusing similarity с названными продуктами и интерфейсами Apple.

Следовательно, оболочка «как iOS» для non-Apple OS жёлтая уже на уровне концепции и красная для нелицензированных Apple resources. До публичного или коммерческого распространения она требует независимого выражения, документированной проверки сходства и одобрения квалифицированного юриста. Точные ресурсы Apple MUST NOT попадать в этот рабочий процесс, если письменная лицензия явно не покрывает такое использование.

6.2 Google и Android

Интерпретация HIF по умолчанию:

  • значительная часть Google Developers documentation доступна по указанным content и code licences, но page-level exceptions, third-party material и Google brand features остаются отдельными;
  • Google brand guidance запрещает ложное endorsement и imitation её distinctive visual identity;
  • название Android, логотип, Google Play brand и другие Google marks не становятся автоматически частью Android Open Source Project;
  • Android robot имеет отдельный маршрут Creative Commons attribution, а Android wordmark и custom typeface требуют самостоятельного разрешения;
  • официальный repository может лицензировать конкретный icon set, например Material Symbols, не лицензируя Google product icons, названия или всю brand identity;
  • Google Fonts содержит open-licensed families, но точные family, files и licence всё равно MUST фиксироваться. Визуально родственный corporate font Google не считается частью Google Fonts по умолчанию.

Поэтому based on Material не означает copy Google. Продукт MAY применять документированные interaction principles или лицензированные components, сохраняя собственный brand, проверяя каждый asset и избегая misleading overall identity.

6.3 Microsoft и другие системы

Публичное руководство Microsoft показывает то же разделение:

  • правдивое referential use word marks может быть допустимо при указанных условиях;
  • logos, product icons, illustrations, designs, fonts, sounds, emoji и trade dress могут требовать прямого разрешения;
  • Fluent UI code repository и Fluent System Icons repository имеют собственные licences, тогда как упомянутые fonts, icons и branded assets могут иметь другие условия.

Такой анализ MUST повторяться для каждого источника. Название дизайн-системы, open-source library и corporate brand — разные правовые объекты, даже если их поддерживает одна организация.

7. Протокол независимого создания

Для жёлтых референсов проект MUST применять следующий протокол, если counsel не одобрил иной:

  1. записать user need, task, constraints и необходимые platform conventions до сбора визуальных референсов;
  2. перечислить несколько независимых референсов, не превращая один продукт в specification;
  3. извлечь абстрактные принципы словами: hierarchy, state, feedback, navigation, reach, density и error recovery;
  4. исключить proprietary files и restricted resources из implementation repository;
  5. создать information architecture, geometry, tokens, typography, icons, движение, звуки, названия и текст продукта из собственных исходных данных;
  6. фиксировать авторов, даты, историю дизайна и доказательства из системы управления версиями;
  7. провести проверку сходства по всему набору референсов;
  8. удалить необязательные сходства и документировать сходства, требуемые функцией или interoperability;
  9. пройти контрольные этапы прав и юридической проверки до внешней проверки, маркетинга или выпуска;
  10. архивировать доказательства и утверждение вместе с выпуском.

При существенной экспозиции counsel MAY потребовать clean-room split: одна группа документирует функциональные требования, другая реализует их без доступа к защищённому исходному материалу. HIF не утверждает, что одна эта процедура устраняет liability.

8. Проверка сходства

Сходство MUST оцениваться как целостный experience, а не только по отдельным элементам.

Проверка охватывает:

  • название продукта и функции;
  • information architecture и последовательность screens;
  • proportions, geometry и spatial composition;
  • colour relationships и distinctive combinations;
  • typeface, metrics, hierarchy и treatment текста;
  • silhouettes и families иконок;
  • shapes и states controls;
  • materials, depth, borders и effects;
  • motion choreography и transition timing;
  • sound и haptic signatures;
  • terminology, microcopy и error language;
  • onboarding, marketing imagery и device framing;
  • совместное впечатление обычного пользователя.

Reviewer фиксирует, какие сходства conventional, functional, platform-required, licensed или unnecessary. HIF не определяет numerical similarity score как юридический тест.

9. Очистка assets и кода

Каждый внешний artefact MUST иметь запись в Реестре очистки прав и выпуска.

Запись MUST содержать:

  • точный artefact, version и cryptographic hash, где это возможно;
  • author, rightsholder, source URL и acquisition date;
  • оригинальный licence text или written permission;
  • разрешённые purpose, territory, media, audience, term и distribution model;
  • права на modify, adapt, subset, embed, host и redistribute;
  • attribution, notice, source, patent и copyleft obligations;
  • trade mark, publicity, privacy, moral-rights и data restrictions;
  • transitive dependencies и embedded third-party material;
  • статус, утверждающее лицо, срок действия и условие пересмотра.

Package metadata, marketplace badge или поисковая licence label — основания для проверки, а не финальная запись.

Open-source software MUST использовать точные SPDX expressions, где они существуют. Distribution process SHOULD выпускать SPDX software bill of materials и полный bundle notices/source offers. Зрелая программа SHOULD выравнивать процесс с OpenChain ISO/IEC 5230.

10. Шрифты, иконки, изображения, звук и motion

10.1 Шрифты

Команда MUST отдельно очищать desktop use, designer-seat use, web serving, application embedding, document embedding, server generation, subsetting, conversion, modification, redistribution, backup и client transfer, если лицензия их различает.

System availability не является redistribution authority. Metrics-compatible substitution не разрешает копировать font files или outlines.

10.2 Иконки

Общее значение не делает любой рисунок свободным. Проверяются точные icon files, лицензия набора, встроенные brand marks и итоговая identity продукта. Brand и payment icons MUST использовать одобренный владельцем asset и rules, когда такое использование необходимо.

10.3 Изображения, видео, голос и likeness

Copyright permission не предоставляет автоматически model, property, personality, privacy или location permission. Synthetic media MUST сохранять provenance input, model, operator и output и MUST NOT использоваться для отмывания restricted reference.

10.4 Звук, motion и haptics

Короткая длительность не является статусом прав. Signature sounds, animation sequences и haptic patterns проходят тот же clearance, что статические визуальные элементы, и могут также затрагивать brand или patent.

11. Дизайн и реализация с применением ИИ

Использование AI MUST NOT ослаблять требования к provenance.

До передачи материала модели оператор MUST иметь полномочие на такую обработку и учитывать confidentiality, personal data, trade secrets и provider terms. Проект MUST фиксировать:

  • model и service version;
  • account и data-retention mode;
  • prompt или task record, соответствующий чувствительности;
  • source material и authority to process;
  • generated artefact и human editor;
  • проверка сходства и прав;
  • disclosures или attribution, требуемые законом, договором или policy.

Prompts вроде copy this exactly, make an iOS clone или redraw this logo so it is legally different запрещены для production work. Generated output не имеет презумпции originality, ownership или non-infringement.

12. Регуляторная основа интерфейса

Правовой профиль продукта MUST оценивать как минимум:

ОбластьИнтерфейсные вопросы
Конфиденциальность и защита данныхПравдиво ли реализованы цели, правовое основание, минимизация данных, настройки по умолчанию, согласие, хранение, удаление, доступ и возражение? Нужна ли DPIA?
Доступность и недискриминацияКакие продукты, услуги и лица охвачены на каждом рынке? Какой технический стандарт и доказательства применимы?
Защита потребителейЯсно и недвусмысленно ли показаны цены, регулярные платежи, пробные периоды, существенные условия, ранжирование, реклама, отмена и возвраты?
Manipulative designОдинаково ли понятны и доступны accept/reject, enter/exit, subscribe/cancel и disclose/withhold?
Children и age assuranceМожет ли сервис быть доступен детям? Соответствуют ли возрасту defaults, profiling, geolocation, nudges и disclosures?
ИИ и автоматические решенияРаскрывается ли участие ИИ там, где это требуется? Может ли человек понять решение, оспорить его и получить проверку человеком?
Sector regulationПрименяются ли health, finance, employment, education, communications, transport, public-sector или safety rules?
Управление содержанием и платформойПопадают ли в область обязанности по уведомлениям, обжалованию, модерации, продавцам, рекламе и рекомендательным системам?
InternationalisationМеняют ли интерфейс правила целевой страны о consumer, language, tax, records, sanctions, export или local representative?

Конфиденциальность и доступность MUST проектироваться с начала, а не добавляться после визуального завершения. Юридический текст MUST NOT противоречить фактическому поведению интерфейса.

13. Запрет манипулятивного дизайна

Продукт HIF MUST NOT использовать асимметрию интерфейса, чтобы получить деньги, данные, consent или продолжение engagement, которого человек свободно не намеревался давать.

Запрещены:

  • скрытые material terms или fees;
  • preselection, нарушающий ожидаемую нейтральность выбора;
  • заметное acceptance action и скрытый отказ;
  • ложные scarcity, urgency, popularity или progress;
  • disguised advertising или sponsored ranking;
  • случайные purchase, consent или disclosure из-за misleading labels;
  • cancellation или account deletion, существенно более сложные, чем enrolment;
  • повторные препятствия после ясного отказа;
  • shame, threat или loss framing, не связанный с реальным последствием;
  • defaults, собирающие или раскрывающие больше данных, чем необходимо;
  • interference, нацеленная на уязвимость человека.

Это одновременно ethical invariant и legal-risk control. Применимое право может устанавливать дополнительные или иначе определённые обязанности.

14. Работа с клиентами

Поставщик аудита или исправлений MUST получить письменное полномочие исследовать, фиксировать и изменять указанную область. Заказ SHOULD определять:

  • какие environments, accounts, content и third-party systems можно использовать;
  • кто владеет и вправе передать код, содержание, данные и ресурсы;
  • правила конфиденциальности, персональных данных, безопасности и обращения с доказательствами;
  • разрешены ли production testing, crawling и recording;
  • ownership и licensing deliverables и reusable pre-existing material;
  • client warranties и зависимости от предоставленной клиентом информации о правах;
  • approval, acceptance, indemnity, liability и insurance terms, соответствующие engagement;
  • кто получает specialist legal advice.

Аудитор HIF, не действующий как квалифицированный юрист, MUST NOT утверждать, что продукт законен, незаконен или защищён от претензий. Аудитор MAY описать наблюдаемое состояние дизайна или доказательства, указать потенциально применимое правило, уровень уверенности и рекомендовать проверку специалиста.

Пример:

Проверенный путь отмены потребовал шесть шагов, а подписка — два. Такая асимметрия создаёт риск нарушения защиты потребителей на названных рынках. Применимость права и способ устранения требуют проверки юриста.

15. Контрольные этапы принятия решения и выпуска

Этап L0 — правовой профиль

До дизайна:

  • записаны юридическое лицо, ответственный за продукт и целевые рынки;
  • записаны users, age groups, sectors и distribution channels;
  • определены применимые platform programmes и agreements;
  • назначены ответственный за правовые вопросы и порядок обращения к внешнему юристу.

Этап L1 — приём референсов

До поступления reference material в дизайн:

  • каждый источник имеет ответственного, URL, дату и условие доступа;
  • restricted, confidential и client material изолированы;
  • цель изучения записана как needs и principles;
  • жёлтые и красные источники помечены.

Этап L2 — утверждение дизайна

До реализации:

  • expression независимо выведено;
  • platform и brand records актуальны;
  • проверка сходства завершена;
  • assets, fonts, icons, copy, audio и motion имеют записи;
  • counsel-required позиции имеют письменное решение.

Этап L3 — сборка и распространение

До внешнего распространения:

  • перечень зависимостей и ресурсов соответствует сборке;
  • notices, attribution, source и permissions упакованы;
  • store, SDK, API и marketing terms выполнены;
  • меры конфиденциальности, доступности, защиты потребителей и отраслевого права протестированы;
  • screenshots и store metadata используют очищенные материалы;
  • нерешённые позиции блокируют выпуск или имеют одобренное датированное решение о риске.

Этап L4 — сопровождение

После выпуска:

  • у жалоб и требований об удалении есть ответственный и процесс ответа;
  • expiring permissions и living platform terms отслеживаются;
  • replacements можно выпустить без потери critical function;
  • каждый выпуск сохраняет свой точный пакет доказательств.

16. Триггеры эскалации

Проверка квалифицированного юриста обязательна по HIF, если для выпуска существенно любое из следующего:

  • намеренное сходство с узнаваемым коммерческим интерфейсом;
  • restricted resources Apple, Google, Microsoft или другой платформы;
  • unclear ownership или missing licence;
  • brand, trade dress, design или patent search с потенциально релевантными результатами;
  • exception или defence является основным основанием использования;
  • reverse engineering или interoperability за пределами документированных public APIs;
  • distribution в нескольких правовых режимах с разными обязанностями;
  • children, biometrics, high-risk personal data, regulated services или safety;
  • cease-and-desist, takedown, store rejection или allegation of infringement;
  • запрос клиента гарантировать legality или non-infringement.

При срабатывании статус — COUNSEL REQUIRED; молчание не является approval.

17. Официальные англоязычные источники

Интеллектуальная собственность и охрана дизайна

Условия платформ и assets

Compliance systems и interface regulation

Официальные страницы и лицензии являются изменяемыми источниками. Сохранённые условия, применимые на даты приобретения и выпуска, остаются частью доказательств продукта.