Ownership and license ledger
Create one ledger across six asset classes
Unknown is an acceptable temporary status; invented certainty is not. Record the artifact, source, applicable permission and verification evidence.
Application source
- Origin
- Repository history, exports, contractors and generated changes
- Permission needed
- Contractual and applicable rights to use, modify, deliver and sublicense where required
- Verify
- Repository ownership, contributor agreements or contracts and a reviewed change history
- Failure
- A source archive exists but transfer rights and contributors are unclear
Packages and copied code
- Origin
- Package managers, snippets, templates and vendor SDKs
- Permission needed
- Each applicable open-source or commercial license and notice obligation
- Verify
- Locked dependency inventory, notices and review of non-registry code
- Failure
- Generated imports are assumed safe because the build installs them
Images, icons and illustrations
- Origin
- Client files, stock libraries, generators, screenshots and scraped references
- Permission needed
- Rights for the intended channels, territories, edits and client transfer
- Verify
- Source link, receipt or license record connected to the final asset
- Failure
- A visually similar generated or downloaded image has no provenance record
Fonts
- Origin
- Hosted service, local files, theme or design tool
- Permission needed
- Web embedding, traffic, domain and distribution terms
- Verify
- Font file source, active license and deployment method
- Failure
- A desktop font file is copied into the web build without checking embedding rights
Content and data
- Origin
- Client, model output, public sources, users and datasets
- Permission needed
- Rights and lawful basis appropriate to publication and processing
- Verify
- Attribution, approval, source notes and data-use documentation
- Failure
- Generated copy repeats unsupported claims or protected source material
Operational accounts
- Origin
- Domain, hosting, email, analytics, database and AI providers
- Permission needed
- Organization ownership, authorized use and transferable administration
- Verify
- Account register, current terms, billing owner and recovery access
- Failure
- The buyer owns code but the seller controls the accounts required to run it
Generation does not erase provenance
Treat unknown inputs as a diligence question
A model may produce commonplace code, imitate a familiar pattern or suggest a package. The output alone does not reliably document where every element originated or which obligations apply. That is why the delivery process should preserve dependency, asset and contract evidence instead of attempting forensic certainty at the end.
Use standard identifiers and machine-readable inventories where practical, then attach human decisions for custom assets and commercial terms. A software bill of materials improves transparency but does not itself grant permission.
- Record source and license when the asset enters the project
- Keep notices and license files with the delivered product
- Review copied snippets outside the package inventory
- Separate account ownership from intellectual-property rights
Production standard
A delivery gate for provenance
The gate protects a client from receiving an attractive product that cannot be lawfully or independently operated.
Inventory
PassMaterial code, packages, fonts, images, content and vendors are listed.
FailOnly direct package dependencies are recorded.
Permission
PassEach material item has an applicable permission or an explicit unresolved status.
FailUnknown origin is silently treated as owned.
Transfer
PassThe delivered rights and accounts match the client’s intended use and operating model.
FailPersonal or non-transferable access is required after handoff.
Reproducibility
PassThe client can rebuild the version from the recorded source and dependencies.
FailCritical output exists only inside an unavailable workspace.
Applied example
Provenance failure: the redesign uses a mystery font
A generated landing page includes a local font file copied from a designer’s laptop. The client receives the repository and launches a large campaign, but no one can identify the web license.
- Possession of the file does not document web-embedding permission.
- The dependency scanner does not cover the font asset.
- The uncertainty should have appeared in the asset ledger before handoff.
- The team can replace the font or obtain the appropriate rights before distribution expands.
Plain answers
Ownership and license questions
Do I own code produced by an AI coding tool?+
That depends on applicable law, provider terms, contracts and the inputs and output involved. Review current terms and obtain legal advice for material decisions.
Does open source mean no obligations?+
No. Open-source licenses grant permissions subject to their terms, which can include notices, source or other conditions.
Is an SBOM proof that every component is licensed correctly?+
No. It improves component transparency. Permission and compliance still require accurate inventory and license analysis.