Rights Clearance and Release Record

Status: controlled operational template

Version: 0.1

Use this template with Legal, IP and Platform-Reference Governance. It records evidence and decisions; it does not replace legal advice.

1. Product legal profile

Product:
Version:
Owning legal entity:
Product owner:
Rights/compliance owner:
Security/privacy owner:
Accessibility owner:
Qualified counsel/contact:
Target markets:
User groups and age ranges:
Regulated sectors:
Distribution channels:
Platform programmes:
Commercial model:
Record date:
Next review:

Applicable-domain matrix

Allowed status values:

• NOT APPLICABLE — reason recorded;
• OPEN — evidence not complete;
• CLEAR — use approved as recorded;
• CLEAR WITH CONDITIONS — conditions are implemented and testable;
• COUNSEL REQUIRED — work or release blocked pending legal decision;
• REJECTED — use prohibited;
• EXPIRED — previous decision no longer supports the current use.

2. Third-party artefact record

Create one record for each external file, component, dataset, typeface, icon set, image, sound, video, template, design resource, text extract or generated asset. Grouping is allowed only when ownership, licence, version, acquisition and intended use are identical.

RIGHTS-ID:
Name:
Category:
Description:
Product feature:
Exact version/revision:
File paths/package identifiers:
Hash or immutable identifier:

Creator:
Copyright holder:
Other rightsholders:
Supplier:
Canonical source URL:
Acquisition method:
Acquisition date:
Access conditions:

Licence/permission name:
SPDX expression where applicable:
Canonical licence URL:
Saved licence/permission location:
Licence version/effective date:
Proof of purchase or grant:

Intended purpose:
Modification:
Adaptation/derivatives:
Subsetting/conversion:
Embedding:
Hosting/CDN:
Internal sharing:
Client transfer:
Redistribution:
Sublicensing:
Source/notice offer:
Attribution:
Territories:
Channels:
Audience/user limits:
Term/expiry:

Embedded third-party material:
Trade marks/brand elements:
Personal data/likeness/property:
Moral-rights requirements:
Patent grant or restriction:
AI processing restrictions:
Other contractual restrictions:

Decision status:
Conditions:
Reviewer:
Approver:
Decision date:
Next review:
Review triggers:
Replacement/rollback asset:
Release versions using the artefact:
Notes:

Mandatory checks

• The canonical source, not a repost, is recorded.
• The exact artefact and licence versions are reproducible.
• The rightsholder is distinguishable from the distributor.
• The intended commercial and white-label uses are covered.
• Modification, embedding and redistribution have been checked separately.
• Trade marks and brand features have been checked separately.
• Embedded and transitive material has been checked.
• Attribution and notices are implemented in the required location.
• Expiry and change triggers are monitored.
• The release build contains only the approved artefact.

3. Platform record

Create one record for each ecosystem whose SDK, APIs, store, design guidance, resources, device imagery, marks or compatibility claims affect the product.

PLATFORM-ID:
Platform/ecosystem:
Products and OS versions:
Target territories:
Distribution route:
Developer account/entity:

Developer agreement:
SDK/tool agreement:
Store/review rules:
Design-resource licence:
Font licence:
Icon/symbol licence:
Trade mark guidance:
Marketing/device-image guidance:
API/data terms:
Additional programme terms:

Exact versions/effective dates:
Saved evidence locations:
Retrieval dates:
Account-specific accepted terms:

Permitted uses:
Prohibited uses:
Required notices:
Compatibility wording:
Approval/request route:
Known change schedule:

Owner:
Reviewer:
Status:
Decision:
Decision date:
Next review:
Release impact:

Platform review questions

• Does guidance describe convention, or does it grant an asset licence?
• Does an open-source code licence cover the associated visual assets?
• Does an asset licence restrict the target operating system or product?
• Are fonts and symbols under separate terms?
• Are product icons or logos excluded?
• Does referential use require exact wording, relative prominence or attribution?
• Could the overall product imply source, endorsement or certification?
• Are screenshots, badges, device frames and marketing uses separately governed?
• Does store approval impose a stricter copycat rule than applicable law?
• Have living terms been checked for this release?

4. Reference and independent-creation record

REFERENCE-ID:
Design area:
Functional problem:
User need:
Constraints:
Required conventions/interoperability:

Reference owner/product:
Reference URL/version/date:
Access condition:
Material viewed:
Reason for viewing:
Extracted abstract principles:
Elements explicitly excluded:

Other independent references:
Owned research/evidence:
Implementation brief:
Implementers:
Reference access available to implementers:
Clean-room arrangement if any:

Original decisions:
Design-history links:
Distinctive product expression:
Similarity review:
Residual similarities:
Reason each similarity remains:

Reviewer:
Status:
Counsel decision where required:
Date:
Release:

Similarity comparison

The table MUST NOT be converted into a numerical legal-safe score.

5. Commissioned-work record

WORK-ID:
Supplier/creator:
Engagement:
Deliverables:
Creation dates:
Contributors:
Use of subcontractors:
Use of stock/open-source/third-party material:
Use of AI tools:

Pre-existing supplier material:
Rights assigned:
Rights licensed:
Territory:
Media/channels:
Term:
Exclusivity:
Modification and derivative rights:
Sublicensing/client transfer:
Moral-rights treatment:
Warranties:
Indemnity/liability:
Attribution:
Confidentiality:
Personal-data obligations:

Signed agreement:
Acceptance record:
Source/design files received:
Dependency and asset manifest received:
Status:
Approver:

Payment or delivery alone does not prove assignment or a sufficient licence.

6. Open-source distribution record

Release:
SBOM format/version:
SBOM location:
Scanner/tool and version:
Manual reviewer:
Dependency lockfile:
Source revisions:
SPDX expressions:
Custom/unknown licences:
Copyleft review:
Patent clauses reviewed:
Notices bundle:
Source-offer/source-delivery bundle:
Modification notices:
Installation information if applicable:
Exported artefacts checked:
Container/base-image check:
Client redistribution model:
Exceptions:
Approval:

Open-source release gate

• Direct, development, optional and transitive dependencies are distinguished.
• Actual shipped files, not only manifests, were inspected.
• Licence expressions are exact and exceptions are recorded.
• Incompatible or unknown licences block release.
• Required notices and copyright statements are preserved.
• Required source and modification information is deliverable.
• Assets and data bundled with code are separately cleared.
• The SBOM represents the released build.

7. AI-assisted artefact record

AI-ID:
Artefact:
Purpose:
Provider/service:
Model/version:
Account/data-control mode:
Terms version:
Operator:
Date:

Input sources:
Authority to process each source:
Personal/confidential/restricted material:
Prompt/task record:
Output:
Human modifications:
Similarity search/review:
Rights review:
Required disclosure/attribution:
Known limitations:
Status:
Approver:

8. Legal-review request packet

The product team SHOULD send counsel a bounded question, not an unstructured folder of screenshots.

REVIEW-ID:
Decision required:
Release deadline:
Business purpose:
Product and feature:
Entities:
Territories:
Distribution:
Users:

Facts:
Exact third-party material:
How it was obtained:
Proposed use:
Alternatives considered:
Similarity analysis:
Relevant agreements/licences:
Search results:
Known communications/permissions:

Questions:
Requested decision status:
Conditions that engineering can test:
Required notices/wording:
Expiry or review trigger:

Counsel:
Advice date:
Privilege/confidentiality handling:
Decision:
Conditions:
Residual risk owner:

Legal advice and privileged material MUST be stored with appropriate access, not copied into a public issue or documentation site. The public register MAY record the resulting operational decision without disclosing protected advice.

9. Client authority and evidence record

ENGAGEMENT-ID:
Client legal entity:
Authorised contact:
Scope:
Environments:
Accounts:
Allowed test methods:
Production restrictions:
Recording/screenshot permission:
Personal-data handling:
Confidential material:
Third-party services:
Client-supplied assets and code:
Client representation of authority:
Deliverable ownership/licence:
Reusable provider material:
Legal-advice boundary:
Evidence retention/deletion:
Incident contact:
Signed authority:
Start/end:

10. Release rights manifest

One manifest MUST be produced for every external release.

Release:
Build identifier/hash:
Date:
Products/channels:
Territories:
Legal profile version:
Platform record versions:
SBOM:
Third-party artefact records:
Reference records:
AI records:
Notices/attribution bundle:
Permissions:
Store/marketing assets:
Privacy/accessibility/consumer evidence:
Counsel decisions:
Exceptions:
Expiries:
Rollback/replacement plan:
Approved by:

Final gate

• Every shipped external artefact maps to an approved record.
• Every named platform maps to a current platform record.
• Every amber reference maps to an independent-creation and similarity record.
• No item is OPEN, COUNSEL REQUIRED, REJECTED or EXPIRED.
• Conditions are implemented and verified in the released build.
• Notices and attribution are visible where required.
• Marketing, screenshots, store copy and packaging are included in scope.
• Legal and platform terms have not changed since approval.
• The evidence bundle is immutable, access-controlled and retrievable.

11. Minimum issue fields

If the organisation uses a tracker rather than these full records, every rights issue MUST still contain:

12. Retention and change control

Records MUST be versioned with the product. A new review is required when:

• the artefact or dependency changes;
• a licence, platform term or brand rule changes;
• the product adds a territory, channel or use;
• the commercial model or legal entity changes;
• the work is transferred to a client or distributor;
• a permission expires or a rightsholder changes;
• a complaint, rejection, takedown or claim is received;
• implementation changes the similarity or data processing;
• a material fact in the original decision was incomplete or wrong.

Do not overwrite prior evidence. Preserve what supported each historical release and append the new decision.