Legal, IP and Platform-Reference Governance

Status: normative governance baseline

Version: 0.1

1. Purpose and boundary

This document defines how an HIF product handles legal obligations, intellectual property, third-party platform references and evidence of rights before design or implementation is released.

It is an operational control, not legal advice and not a declaration that any particular use is lawful. Laws, contracts, platform rules and remedies differ by jurisdiction, market, product, distribution channel and date. A qualified lawyer MUST decide questions reserved for legal judgement.

The governing principle is:

Learning a convention does not grant a right to copy its expression.

Public visibility, technical access, inclusion in an SDK, a design guideline, an app-store listing, an open-source code licence, an educational purpose or the absence of a copyright notice MUST NOT be treated as permission.

2. Non-negotiable requirements

Every product MUST:

1. identify the legal entities, target markets and distribution channels;
2. maintain a current legal and platform-obligation profile;
3. maintain provenance and rights records for every third-party input;
4. clear code, visual assets, typefaces, text, data, audio, motion, brands and platform resources separately;
5. preserve exact licence texts, permissions, versions and retrieval dates;
6. implement required notices, attribution, source offers and disclosure;
7. separate functional requirements from copied visual expression;
8. stop unreviewed high-risk references before implementation;
9. obtain specialist review where this document defines a counsel gate;
10. retain release evidence for the product's support and limitation periods.

No individual designer, developer, auditor, client or automated tool MAY approve its own high-risk legal exception.

3. The rights stack

An interface can engage several independent regimes at once. Clearance under one row does not clear another.

The project MUST record not applicable with a reason; an empty record is not a decision.

4. Function, convention and expression

Interfaces need shared conventions. A back action, scroll behaviour, a window, a text field or a list can serve a functional and interoperable purpose. That does not establish a universal safe harbour for a particular drawing, arrangement, transition, sound, name or collection of details.

The team MUST distinguish:

• need — what a person is trying to achieve;
• function — what the system must do;
• convention — an expectation needed for learning or interoperability;
• expression — the specific visual, textual, sonic or behavioural form;
• asset — a concrete file or extract;
• brand signal — a feature that may indicate commercial source;
• implementation — code, algorithms and technical mechanisms.

Requirements and design rationale SHOULD describe the first three without prescribing another product's expression. New work MUST derive its expression from product context, evidence and an owned design system.

There is no HIF rule that a particular percentage of difference makes copying safe. Pixel distance, colour changes, mirroring, redrawing, converting formats or replacing a few components do not by themselves resolve infringement, confusion, contract or platform risk.

5. Default decision zones

These zones are internal risk controls, not legal conclusions.

5.1 Green — proceed with recorded evidence

A product MAY normally proceed when all relevant records are complete and the work is:

• independently created from an owned brief and documented requirements;
• a conventional behaviour expressed through the product's own visual system;
• implemented through an authorised public platform API;
• an exact version of a third-party component or asset under a verified, compatible licence;
• a truthful plain-text compatibility reference permitted by current brand guidance;
• commissioned under a written agreement that assigns or adequately licenses the required rights;
• in the public domain under an applicable, documented legal basis.

Green status expires when the artefact, licence, product use, territory, channel or ownership changes.

5.2 Amber — stop implementation pending review

The following require documented rights review and may require qualified counsel:

• close structural or visual similarity to one identifiable product;
• a distinctive combination of layout, typography, iconography, colour, material, motion, sound and terminology;
• recreation of a current or historical operating system, device or app;
• vendor screenshots, device frames, badges, product imagery or UI kits;
• compatibility, certification, partnership or endorsement language;
• a font, icon set, theme, template or design file with unclear scope;
• reverse engineering, interoperability research or protocol emulation;
• generated content based on a protected or confidential reference;
• reference material obtained through a login, subscription, beta or NDA;
• third-party code with no licence, a custom licence or incompatible obligations;
• biometric, health, financial, child, precise-location or other high-risk data;
• a new interaction mechanism in a patent-sensitive domain;
• a proposed exception based on fair use, fair dealing, quotation, parody, interoperability or another jurisdiction-specific limitation.

No commercial deadline turns amber into green.

5.3 Red — prohibited by HIF without written permission and legal approval

An HIF-conforming project MUST NOT:

• ship a pixel clone or deliberately confusing imitation of another product;
• use another organisation's logo, badge, product icon, slogan or typeface as its own identity;
• imply affiliation, certification, sponsorship or endorsement that does not exist;
• extract, trace, redistribute or embed proprietary design resources outside their licence;
• use a proprietary font or symbol set because it is installed on one team member's device;
• copy code, copy, artwork, sound, animation or data from a source without an identified permission or legal basis;
• remove or hide copyright, attribution, trade mark or licence notices;
• use “found online”, “free download”, “abandonware”, “educational” or “fan project” as a rights status;
• treat a Git repository without a licence as open source;
• rely on app-store acceptance as proof of rights;
• route restricted material through AI, tracing, conversion or redrawing to conceal its source;
• use client-supplied material without recording the client's authority and the project's reliance on that representation;
• bypass access controls, contractual restrictions or a rejected permission request;
• publish a legal-conformance claim that has not been approved for the stated scope.

6. Platform-reference rule

Platform design guidance is evidence about conventions for that platform. It is not a general licence to reproduce platform assets, branding or trade dress.

Before using any named ecosystem, the project MUST create a platform record covering:

• current developer and programme agreements;
• store and distribution rules;
• design-resource and template licences;
• font and icon licences;
• trade mark and marketing guidance;
• screenshot, device-image and badge rules;
• API and data terms;
• territory, product and channel restrictions;
• version, retrieval date, owner and next review date.

6.1 Apple

The default HIF interpretation is:

• Human Interface Guidelines explain platform conventions but do not grant a general asset or branding licence.
• Apple's Design Resources licence limits the supplied resources to interface mock-ups for software products running only on specified Apple operating systems. It restricts non-Apple mock-ups, embedding, redistribution and other work products.
• San Francisco fonts and other Apple fonts have separate terms. Access to a download is not permission for a Linux, Windows, web-branding or general redistribution use.
• Apple's trade mark guidance allows limited, truthful referential use of certain word marks for compatibility under stated conditions. It does not generally authorise the Apple logo or Apple-owned graphic symbols.
• Apple's App Review Guidelines separately reject copycats, require rights for product materials and prohibit confusing similarity to named Apple products and interfaces.

Therefore, an “iOS-like” shell for a non-Apple operating system is amber by concept and red for unlicensed Apple resources. It requires independent expression, a recorded similarity review and qualified legal approval before public or commercial distribution. Exact Apple resources MUST NOT enter that workstream unless a written licence expressly covers that use.

6.2 Google and Android

The default HIF interpretation is:

• much Google Developers documentation is available under stated content and code licences, but page-level exceptions, third-party material and Google brand features remain separate;
• Google brand guidance prohibits false endorsement and imitation of its distinctive visual identity;
• the Android name, logo, Google Play brand and other Google marks are not automatically part of the Android Open Source Project;
• the Android robot has a specific Creative Commons attribution route, while the Android wordmark and custom typeface require separate authority;
• an official repository may license a particular icon set, such as Material Symbols, without licensing Google product icons, names or overall brand identity;
• Google Fonts contains open-licensed families, but the exact family, files and licence MUST still be recorded. A visually related Google corporate font is not presumed to be in Google Fonts.

Therefore, “based on Material” does not mean “copy Google”. A product MAY adopt documented interaction principles or licensed components while maintaining its own brand, verifying each asset and avoiding a misleading overall identity.

6.3 Microsoft and other systems

Microsoft's public guidance illustrates the same separation:

• truthful referential use of word marks may be possible under stated conditions;
• logos, product icons, illustrations, designs, fonts, sounds, emoji and trade dress can require express authority;
• the Fluent UI code repository and the Fluent System Icons repository have their own licences, while referenced fonts, icons and branded assets may have different terms.

The same analysis MUST be repeated for every other source. A design system name, open-source library and corporate brand are different legal objects even when the same organisation maintains them.

7. Independent-creation protocol

For amber references, the project MUST use the following protocol unless counsel approves another:

1. write the user need, task, constraints and required platform conventions before collecting visual references;
2. list multiple independent references rather than treating one product as the specification;
3. extract abstract principles in words: hierarchy, state, feedback, navigation, reach, density and error recovery;
4. exclude proprietary files and restricted resources from the implementation repository;
5. create the product's information architecture, geometry, tokens, typography, icons, motion, sounds, names and copy from owned inputs;
6. record authors, dates, design history and source-control evidence;
7. perform a similarity review against the reference set;
8. remove unnecessary similarities and document similarities required for function or interoperability;
9. run rights and legal gates before external review, marketing or release;
10. archive the evidence and approval with the release.

Where exposure is material, counsel MAY require a clean-room split: one group documents functional requirements; a separate group implements without access to protected source material. HIF does not claim that this procedure alone eliminates liability.

8. Similarity review

Similarity MUST be reviewed as an overall experience, not only element by element.

The review covers:

• product and feature name;
• information architecture and screen sequence;
• proportions, geometry and spatial composition;
• colour relationships and distinctive combinations;
• typeface, metrics, hierarchy and text treatment;
• icon silhouettes and families;
• control shapes and states;
• materials, depth, borders and effects;
• motion choreography and transition timing;
• sound and haptic signatures;
• terminology, microcopy and error language;
• onboarding, marketing imagery and device framing;
• the combined impression on an ordinary user.

The reviewer records which similarities are conventional, functional, platform-required, licensed or unnecessary. HIF does not define a numerical similarity score as a legal test.

9. Asset and code clearance

Every external artefact MUST have a record in the Rights Clearance and Release Record.

The record MUST identify:

• the exact artefact, version and cryptographic hash where practical;
• author, rightsholder, source URL and acquisition date;
• original licence text or written permission;
• permitted purpose, territory, media, audience, term and distribution model;
• rights to modify, adapt, subset, embed, host and redistribute;
• attribution, notice, source, patent and copyleft obligations;
• trade mark, publicity, privacy, moral-rights and data restrictions;
• transitive dependencies and embedded third-party material;
• status, approver, expiry and review trigger.

Package metadata, a marketplace badge or a search-engine licence label is evidence to investigate, not the final record.

Open-source software MUST use exact SPDX expressions where available. The distribution process SHOULD produce an SPDX software bill of materials and a complete notices/source-offer bundle. A mature programme SHOULD align its process with OpenChain ISO/IEC 5230.

10. Fonts, icons, imagery, audio and motion

10.1 Fonts

The team MUST clear desktop use, designer-seat use, web serving, application embedding, document embedding, server generation, subsetting, conversion, modification, redistribution, backup and client transfer as separate uses where the licence distinguishes them.

System availability is not redistribution authority. Metrics-compatible substitution does not authorise copying font files or outlines.

10.2 Icons

Generic meaning does not make every drawing free. Clear the exact icon files, the set licence, any embedded brand marks and the resulting product identity. Brand and payment icons MUST use the owner-approved asset and rules when such use is required.

10.3 Images, video, voice and likeness

Copyright permission does not automatically provide model, property, personality, privacy or location permission. Synthetic media MUST retain input, model, operator and output provenance and MUST NOT be used to launder a restricted reference.

10.4 Sound, motion and haptics

Short duration is not a rights status. Signature sounds, animation sequences and haptic patterns enter the same clearance process as static visuals and may also raise brand or patent questions.

11. AI-assisted design and implementation

AI use MUST NOT reduce provenance requirements.

Before supplying material to a model, the operator MUST have authority for that processing and MUST consider confidentiality, personal data, trade secrets and the provider's terms. The project MUST record:

• model and service version;
• account and data-retention mode;
• prompt or task record appropriate to the sensitivity;
• source material and authority to process it;
• generated artefact and human editor;
• similarity and rights review;
• disclosures or attribution required by law, contract or policy.

Prompts such as “copy this exactly”, “make an iOS clone” or “redraw this logo so it is legally different” are prohibited for production work. A generated output does not carry a presumption of originality, ownership or non-infringement.

12. Regulatory interface baseline

The product's legal profile MUST evaluate, at minimum:

Privacy and accessibility MUST be designed from the beginning, not added after visual completion. Legal text MUST NOT be used to contradict actual interface behaviour.

13. Manipulative design prohibition

An HIF product MUST NOT use interface asymmetry to obtain money, data, consent or continued engagement that a person did not freely intend.

Prohibited patterns include:

• hidden material terms or fees;
• preselection that defeats an expected neutral choice;
• a prominent acceptance action and obscured refusal;
• false scarcity, urgency, popularity or progress;
• disguised advertising or sponsored ranking;
• accidental purchase, consent or disclosure through misleading labels;
• cancellation or account deletion materially harder than enrolment;
• repeated obstruction after a clear refusal;
• shame, threat or loss framing unrelated to the actual consequence;
• defaults that collect or disclose more data than necessary;
• interference targeted at a person's vulnerability.

This is both an ethical invariant and a legal-risk control. Applicable law may impose additional or differently defined duties.

14. Client work

An audit or remediation provider MUST establish written authority to inspect, capture and modify the stated scope. The engagement SHOULD state:

• which environments, accounts, content and third-party systems may be used;
• who owns and may provide code, content, data and assets;
• confidentiality, personal-data, security and evidence-handling rules;
• whether production testing, crawling or recording is allowed;
• ownership and licensing of deliverables and reusable pre-existing material;
• client warranties and dependencies on client-supplied rights information;
• approval, acceptance, indemnity, liability and insurance terms appropriate to the engagement;
• who obtains specialist legal advice.

An HIF auditor who is not acting as qualified legal counsel MUST NOT report that a product is “legal”, “illegal” or immune from a claim. The auditor MAY report an observed design or evidence condition, identify the potentially applicable rule, state confidence and recommend specialist review.

Example:

The tested cancellation path required six steps while subscription required two. This asymmetry creates consumer-protection exposure in the named markets. Legal applicability and remedy require counsel review.

15. Decision and release gates

Gate L0 — legal profile

Before design:

• legal entity, product owner and target markets are recorded;
• users, age groups, sectors and distribution channels are recorded;
• applicable platform programmes and agreements are identified;
• legal owner and external counsel route are named.

Gate L1 — reference intake

Before reference material enters design:

• every source has an owner, URL, date and access condition;
• restricted, confidential and client material is segregated;
• intended learning is stated as needs and principles;
• amber and red sources are labelled.

Gate L2 — design approval

Before implementation:

• expression is independently derived;
• platform and brand records are current;
• similarity review is complete;
• assets, fonts, icons, copy, audio and motion have records;
• counsel-required items have a written decision.

Gate L3 — build and distribution

Before external distribution:

• dependency and asset inventory matches the build;
• notices, attribution, source and permissions are packaged;
• store, SDK, API and marketing terms are satisfied;
• privacy, accessibility, consumer and sector controls are tested;
• screenshots and store metadata use cleared material;
• unresolved items block release or have an approved, dated risk decision.

Gate L4 — maintenance

After release:

• complaints and takedown requests have an owner and response process;
• expiring permissions and living platform terms are monitored;
• replacements can be shipped without losing critical function;
• each release retains its exact evidence bundle.

16. Escalation triggers

Qualified legal review is mandatory under HIF when any of the following is material to release:

• deliberate resemblance to an identifiable commercial interface;
• use of Apple, Google, Microsoft or another platform's restricted resources;
• unclear ownership or a missing licence;
• a brand, trade dress, design or patent search with potentially relevant results;
• an exception or defence is the primary basis for use;
• reverse engineering or interoperability beyond documented public APIs;
• distribution in multiple legal regimes with different obligations;
• children, biometrics, high-risk personal data, regulated services or safety;
• a cease-and-desist, takedown, store rejection or infringement allegation;
• a client asks for a guarantee of legality or non-infringement.

When triggered, status is COUNSEL REQUIRED; silence is not approval.

17. Official English-language sources

Intellectual property and design protection

• WIPO, Industrial Designs.
• UK Intellectual Property Office, Graphical user interfaces and digital designs.
• UK Intellectual Property Office, Using somebody else's intellectual property.
• US Copyright Office, Circular 61: Copyright Registration of Computer Programs.
• USPTO, Digital designs and non-fungible tokens.
• USPTO, Trademark basics.
• EUIPO, Design reform: terminology and procedural changes.

Platform and asset terms

• Apple, Guidelines for Using Apple Trademarks and Copyrights.
• Apple, Apple Design Resources License.
• Apple, App Review Guidelines.
• Apple, Developer Agreements and Guidelines.
• Google, Brand Resource Center guidance.
• Google, Android brand guidelines.
• Google, Google Developers Site Policies.
• Google, Google Fonts FAQ.
• Google, Material Design Icons repository and licence.
• Microsoft, Trademark and Brand Guidelines.
• Microsoft, Fluent UI System Icons repository and licence.

Compliance systems and interface regulation

• SPDX, Handling licence information and SPDX specifications.
• OpenChain, ISO/IEC 5230 — Open Source License Compliance.
• ICO, Data protection by design and by default.
• European Commission, European Accessibility Act.
• US Department of Justice, Guidance on Web Accessibility and the ADA.
• US Federal Trade Commission, Bringing Dark Patterns to Light.
• EUR-Lex, General Data Protection Regulation, Digital Services Act, European Accessibility Act and Artificial Intelligence Act.

Official pages and licences are living sources. The saved terms applicable to the actual acquisition and release dates remain part of the product evidence.