Open-source AI for responsible commercial use
Open-source AI can improve portability and inspectability, but source, weights, runtime, dataset and service rights are different things. Review each licence and replacement path before production.
Open does not mean obligation-free
Start by naming which artefact is open, who published it, what licence applies and what your team must operate or replace.
Open source
Code is published under a licence with rights and obligations. Review notice, modification, distribution and support terms.
Open weights
Model weights may be downloadable while code, training data, use restrictions or commercial rights remain separate.
Source-available
Source visibility does not automatically grant open-source rights. Follow the specific licence and usage boundary.
Portability is tested
A model is replaceable only when API contract, evaluation, runtime, hardware and rollback paths are preserved.
Provenance and version stay attached to the claim.
Open-source AI decision matrix — rights and operations together
Compare portability and control with the obligations they create. No licence or runtime choice removes the need for security patches and acceptance evidence.
| Constraint | Open-source implication | Alternative to compare | Decision question |
|---|---|---|---|
| Latency | Runtime and hardware can be tuned or moved | Managed API for a different performance boundary | What versioned benchmark must remain true after replacement? |
| Privacy | Self-hosting may keep payload in the agreed boundary | Cloud/hybrid for named external capabilities | Which telemetry, update and support paths remain external? |
| Connectivity | Offline packages and mirrors can be planned | Vendor service for managed updates | Who signs, mirrors, patches and recovers dependencies? |
| Cost | Licence can be zero-priced but operations are not | Subscription or token cost with vendor support | Who budgets engineering, security patch and replacement effort? |
| Operations | SBOM, provenance and upstream health need active review | Managed component lifecycle | Who owns CVEs, model updates, support and exit? |
Reference architecture for portable AI
Keep a stable contract around the model so a replacement can be evaluated without silently changing data, security or acceptance behaviour.
- 01
Data and purpose
Define allowed payload, dataset provenance, consent, retention and decision purpose before selecting a model.
- 02
Model and runtime
Record model/weights, runtime, precision, hardware, version, licence and checksums in the component inventory.
- 03
Stable API contract
Separate application inputs/outputs from a provider-specific model so replacement can be tested against the same contract.
- 04
SBOM and security patch
Track dependencies, CVEs, upstream releases, patch owner and offline/connected update path with approval.
- 05
Evaluation and exit
Run the same evaluation, acceptance, rollback and handover checks before declaring a replacement supported.
Evidence cards — provenance before portability claims
A model card or repository is not a production guarantee. Attach licence, source, version, method, workload and review date to each evidence state.
Internal test
Record model, runtime, hardware, dataset/provenance, evaluation method and known limitations in a reproducible test.
Status: proposed · provenance and review date required
Customer pilot
Validate the API contract, data boundary, support path and acceptance metric with the customer's operators and owner.
Status: tested · customer scope and acceptance required
Supported operation
Support only the versions, components, licences, patches and replacement paths listed in the delivery inventory.
Status: supported · SBOM and owner required
What is delivered and what must be operated
Commercial delivery separates source, weights, configuration, runbook and third-party obligations. Do not imply that every artefact transfers by default.
Model and dataset
Record source, weights, training/evaluation context, provenance, licence and data rights; name the owner of future use.
Code and runtime
Deliver or license custom code separately from third-party code, runtime and notices; keep versions reproducible.
Configuration and secrets
Provide redacted templates and a safe rotation path; the customer controls credentials and environment values.
SBOM and security
Name who reviews dependency health, CVEs, upstream changes, patch windows and exceptions.
Handover and exit
List inventory, API contract, evaluation, rollback, runbook and acceptance evidence with a receiving owner.
Open-source AI limitations to make visible
- Open-source, open weights and source-available licences can grant different commercial and redistribution rights
- Upstream projects, model publishers, runtimes and datasets can change, pause or stop support
- A downloadable model is not automatically portable across hardware, runtime, precision or workloads
- SBOM and security patch work remains an operating responsibility even when the licence has no fee
- A replacement needs the same API contract, evaluation method, acceptance decision and rollback evidence
- Customer ownership of every model, component or dependency is not implied without a delivery and licence agreement
Open-source AI questions buyers ask
Is every open model free for commercial use?
No. Review the exact model, code and dataset licences, restrictions, notices and redistribution duties before use.
Does open source remove vendor lock-in?
It can improve options, but runtime, hardware, data format, skills and support can still lock a system. Test a replacement path.
Who patches an open-source dependency?
The delivery inventory names the owner, review cadence, CVE process, update approval and fallback when upstream stops.
Do customers receive weights and source code?
Only the artefacts and rights named in the agreement transfer. Third-party terms and data rights remain separate.
What does an architecture review return?
A bounded licence, provenance, portability and replacement-risk view with an SBOM/evaluation checklist, not a guarantee.