This article maps the open-source foundation model landscape, examines the licence and usage restrictions that govern them, and describes the additional governance investment that open-source consumption requires.
Why “Open-Source” Is a Spectrum
The phrase “open-source AI” is contested. The Open Source Initiative (OSI) Open Source AI Definition at https://opensource.org/ai sets a high bar: open weights, open training data sufficient to reproduce the model, and open code under permissive licences. By this definition, very few of the popular “open” models qualify.
In practice, the released models occupy a spectrum:
- Open weights, restricted licence (Llama 3 family, Gemma): weights downloadable, but licence imposes acceptable-use restrictions and may exclude certain commercial scenarios.
- Open weights, permissive licence (Mistral 7B, Qwen 2.5, Falcon 180B): weights downloadable under Apache 2.0 or similar; broad commercial use permitted.
- Open weights, copyleft (Bloom under RAIL licence variants): use permitted but with conditions that propagate to derivatives.
- Source-available (some research models): weights or code accessible but with non-commercial restrictions.
The Stanford Center for Research on Foundation Models tracks transparency across these dimensions in its Foundation Model Transparency Index at https://crfm.stanford.edu/fmti/, with most major releases scoring well below the OSI threshold even when described as “open.”
The governance implication: the licence and the transparency level must be evaluated per model, not assumed from the “open-source” label.
The Obligation Shift
When an organisation consumes a closed-source AI service through an API, the provider retains many obligations: model evaluation, safety alignment, compliance with applicable AI regulations as a provider, ongoing improvement. The customer is typically a deployer under regulatory frameworks like the European Union AI Act.
When the same organisation downloads an open-source foundation model and deploys it internally, the regulatory categorisation changes. The European Union AI Act Article 25 at https://artificialintelligenceact.eu/article/25/ describes the conditions under which a deployer becomes a provider — including substantial modification and rebadging. Operating an open-source model often constitutes substantial enough modification (through fine-tuning, prompt engineering, or system-prompt definition) that the consuming organisation takes on provider obligations for the resulting system.
This is a non-trivial obligation set. Provider responsibilities include risk management, data governance, technical documentation (Module 1.23), record-keeping (Module 1.21), transparency to deployers, accuracy and robustness testing, human oversight design, and post-market monitoring. Many organisations are unprepared for the shift and have inherited the obligation without realising it.
Licence Analysis Framework
A defensible open-source AI consumption practice begins with structured licence analysis. The framework should answer:
1. What does the licence allow? Specifically: training derivatives, fine-tuning, redistribution of derivatives, commercial use, use in specific industries or for specific purposes.
2. What restrictions does the licence impose? Examples: monthly active user thresholds (Llama 2’s 700 million MAU clause, modified in Llama 3 family), prohibited use cases, attribution requirements, copyleft propagation.
3. What does the licence require? Notice retention, modification disclosure, disclosure of limitations, attestation of acceptable use.
4. What is the licence’s compatibility with downstream stack? A model under a restrictive licence consumed by an application under a permissive licence creates a licence boundary that the software bill of materials must reflect.
The Software Package Data Exchange (SPDX) format at https://spdx.dev/ provides standard identifiers; the Linux Foundation’s BlueOak Council at https://blueoakcouncil.org/ provides curated licence rationale that translates to AI licences.
Acceptable Use Policy Considerations
Most open-weight licences include acceptable-use policies that bind downstream consumers. Common prohibitions include:
- Use in violence-promoting content generation.
- Use in disinformation campaigns.
- Use that violates local law or third-party rights.
- Use in critical infrastructure without specific safeguards.
- Use in biometric identification without consent.
The consuming organisation’s own use policy must be at least as restrictive as the upstream model’s policy, with explicit mapping. The European Commission AI Pact voluntary commitments at https://digital-strategy.ec.europa.eu/en/policies/ai-pact and similar industry-level frameworks provide language that translates well.
Operational Governance Additions
Open-source consumption requires governance investments beyond the API-consumer pattern.
Model Evaluation
The deployer must evaluate the model itself, not rely on provider evaluation. Evaluation should cover safety, fairness, robustness, hallucination rates, and any use-case-specific quality dimensions. The Stanford HELM evaluation framework at https://crfm.stanford.edu/helm/ provides reusable benchmarks; the EleutherAI Language Model Evaluation Harness at https://github.com/EleutherAI/lm-evaluation-harness provides tooling.
Safety Alignment
Open-weight models vary in how aggressively they have been safety-tuned. Some are released with minimal alignment to enable research; others have full alignment included. The deployer must understand the alignment level and supplement as needed through input filtering, output filtering, or further fine-tuning.
Watermarking and Attribution
Where applicable, the deployer must implement watermarking or provenance signalling for generated content. The Coalition for Content Provenance and Authenticity (C2PA) at https://c2pa.org/ has published standards for this purpose.
Vulnerability Monitoring
Open-source models are subject to vulnerability disclosure (jailbreak techniques, training data extraction, model inversion). The deployer must monitor sources such as the Hugging Face Hub security advisories, sectoral information sharing organisations (FS-ISAC, H-ISAC), and academic preprint servers, and apply mitigations as new vulnerabilities emerge.
Provenance Documentation
The model’s provenance (where it came from, what licence applies, what version) must be tracked in the model registry and propagate into model cards (Module 1.23) and AI Bill of Materials documents.
Continuous Re-Evaluation
Unlike a proprietary API where the provider may re-evaluate behind the scenes, the deployer of a frozen open-source model is responsible for re-evaluation as deployment context evolves. This includes evaluation against new fairness benchmarks, new adversarial techniques, and new use cases.
Specific Open-Source Considerations
Training data opacity. Most “open” models do not release training data, only weights. Downstream legal exposure for copyright, privacy, and other training data issues sits with the original trainer — but the deployer may be exposed to derivative claims. The U.S. Copyright Office Report on Copyright and AI at https://www.copyright.gov/ai/ describes the unsettled legal terrain.
Quantisation and distillation. Open-weight models are commonly quantised (reduced precision) or distilled (smaller models trained to mimic larger ones) for cost efficiency. These derivations must be re-evaluated; quality, safety, and bias characteristics can shift materially.
Fine-tuning data sensitivity. Fine-tuning on proprietary or sensitive data can leak that data through model outputs. Mitigation requires careful data preparation and post-training privacy testing.
Long-term support. Open-source models do not come with vendor support. The deployer must plan for in-house expertise to operate, debug, and upgrade.
When Open-Source Is the Right Choice
Open-source consumption is well-suited when:
- Data sensitivity prohibits external API calls.
- Cost predictability matters more than capability frontier.
- Latency requirements demand co-located inference.
- The use case is high-volume and the unit economics favour self-hosting.
- The organisation already has platform engineering capability for AI workloads.
- Optionality and lock-in mitigation are strategic priorities (per the previous article).
Open-source consumption is poorly suited when:
- The use case requires the absolute capability frontier and a closed model leads.
- The organisation cannot invest in the additional governance overhead.
- The use case is occasional and the API economics are favourable.
Looking Forward
The next article in Module 1.25 turns to use-case intake — the upstream process that decides what AI work the organisation will undertake at all. Open-source vs closed-source is one decision in the procurement layer; intake is the decision about whether to undertake the work in the first place.
© FlowRidge.io — COMPEL AI Transformation Methodology. All rights reserved.