Open Source AI Compliance Checklist

How to Use This Checklist

Start with the inventory. List every AI model in production, development and pilot, with its licence, its base model and the date someone read the licence.
Apply the three-tier policy. Classify each model and component as Permitted, Restricted or Prohibited. Restricted items need legal sign-off and a named owner before use.
Generate the SBOM. Every pipeline produces a machine-readable bill of materials that includes model weights and their lineage.
Track the dates. Fill the regulatory table for the places you sell into, and check each date against the Regulation Tracker before you plan against it.
Add the sector addendum. Healthcare, financial services and government each add duties on top.
Plan the work. Assign owners and dates in the eight-week planner.

Open source is not a regulatory exemption. The EU AI Act's open-source relief is narrow. AI systems under a free and open-source licence fall outside the Act unless they are high-risk, prohibited or covered by Article 50 (Article 2(12)). Open general-purpose models skip only the technical-documentation and EU-representative duties (Articles 53(2) and 54(6)), and only when the licence qualifies. The Commission reads a licence with a user cap or a research-only clause as not open source for this purpose.

Every date and term here is a snapshot. Licences change between versions of the same model family, and regulatory dates move. Re-read the licence at each new version and re-check dates before each policy review.

Section 1: Model and Component Inventory

Open Source AI Inventory

Document every AI model and open source component in use. Record the base model and its licence as well as the model in hand: fine-tunes and distilled models can carry their base model's terms.

Model Inventory

Model / Component	Licence (version)	Base model and its licence	Date licence read	Use case	Deployment	Policy tier

Inventory Completeness Check

All production AI models documented with licence name and version?

All development and pilot models documented, including proofs of concept?

Base model identified for every fine-tune and distilled model, from the model card rather than the repository tag?

Acceptable use or prohibited use policy read wherever the licence incorporates one?

Open weight versus open source checked for each model (code, parameters and training-data information all available under OSI-approved terms)?

Training data provenance documented where the developer publishes it?

Components with no licence file flagged for legal review?

Section 2: Three-Tier Licence Policy

Licence Classification Policy

Classify every licence into one of three tiers, for the model and for its whole lineage. Enforce through automated scanning plus human review of custom model licences.

Permitted: OSI-approved permissive licences such as Apache 2.0, MIT and BSD, for the model and every model it was built from. Keep the notices. No legal review required.

Restricted: custom model licences with user caps, use policies or naming rules (for example the Llama Community Licenses, the Gemma Terms of Use, the Qwen License), and copyleft licences (GPL, LGPL, MPL). Legal sign-off, a named owner, and a record of the licence version and the date it was read.

Prohibited: research-only and non-commercial licences in any revenue-linked work, proofs of concept included; components with no licence; AGPL code in a product you run as a service, unless legal has cleared it.

Policy Configuration

Licence	Tier	Key obligation	Patent grant	Copyleft
MIT	Permitted	Keep the copyright notice	Not explicit	No
Apache 2.0	Permitted	NOTICE file; mark changed files. The FSF treats it as incompatible with GPLv2	Yes, with defensive termination	No
BSD 2/3-Clause	Permitted	Keep the copyright notice; 3-clause adds non-endorsement	Not explicit	No
GPL v2 / v3	Restricted	Source for distributed derivatives	v3 explicit	Strong
LGPL / MPL 2.0	Restricted	Changes to the library or file stay under the licence	Varies	Weak / file-level
Llama 3.3 / Llama 4 Community License	Restricted	Acceptable use policy; "Built with Llama"; derivative names start with "Llama"; licence request if over 700 million monthly active users on the release date. Llama 4 multimodal models: no grant to EU-based companies	Custom	Custom
Gemma Terms of Use (Gemma 3 and earlier)	Restricted	A hosted service counts as distribution: your terms must carry Google's use restrictions; Google may restrict use it believes breaches the terms; reaches distilled models	Custom	Custom
Qwen License (e.g. Qwen2.5 72B)	Restricted	Licence request above 100 million monthly active users; "Built with Qwen" on distributed derivatives	Custom	Custom
Mistral AI Research License; Qwen Research License	Prohibited for commercial work	Research or non-commercial use only; Mistral's excludes revenue-linked tests and proofs of concept	Custom	Custom
AGPL v3	Prohibited in services unless cleared	Source offer to users who interact with it over a network	Explicit	Network
No licence	Prohibited	All rights reserved by default	None	n/a

Compatibility and Lineage Check

No Apache 2.0 code combined into a GPLv2-only work?

No GPLv2-only and GPLv3 code combined without an "or later" grant?

No AGPL components in a product run as a service without legal clearance?

For each fine-tune or distillation, the strictest term anywhere in its lineage recorded and applied?

User caps (monthly active users) in custom licences checked against your numbers, including affiliates, on the date the licence specifies?

For models under a custom licence, documentation requested from the provider (the AI Act's Article 53(1)(b) duty applies unless the model qualifies as open source)?

Licence re-read at each new model version (families such as Gemma, Mistral and Qwen have changed licence between releases)?

Section 3: SBOM and Vulnerability Monitoring

Software Bill of Materials

Generate a machine-readable bill of materials in every CI/CD pipeline, and extend it to model weights, base models and training-data sources. Check whether your customers or government buyers require one.

SBOM Coverage Assessment

Pipeline / Product	SBOM format	Generation	Frequency	Storage	Status

SBOM Completeness Checklist

SBOM generation automated in the CI/CD pipeline?

Standard format used (SPDX or CycloneDX)?

Transitive dependencies included as well as direct ones?

Model weights, base model and training-data lineage recorded?

SBOMs stored and versioned with each release?

SBOM review part of the deployment gate?

Vulnerability Monitoring

Severity	Response SLA	Escalation to	Patch process	Current tool
Critical (CVSS 9.0+)
High (CVSS 7.0 to 8.9)
Medium (CVSS 4.0 to 6.9)
Low (CVSS 0.1 to 3.9)

Scanning Tool Coverage

Licence scanning in the pipeline (for example FOSSA, Black Duck or FOSSology)?

Transitive dependency analysis switched on?

Secrets scanning active alongside vulnerability scanning?

CVE monitoring with alerts (for example Dependabot, Snyk or OSV-Scanner)?

Human review for custom model licences and dual-licensed components, since scanners read tags rather than lineage?

Section 4: Regulatory Dates

Multi-Jurisdiction Tracker

Build one governance core to the strictest regime you sell into, then add what each other market needs. Dates below were read on 6 October 2026; check them against the Regulation Tracker before planning.

Key Regulatory Dates

Where	Rule	Date	What it means for open models
EU	AI Act: prohibited practices and AI literacy	2 Feb 2025	No open-source exclusion for prohibited practices
EU	AI Act: general-purpose AI model duties	2 Aug 2025 (models already on the market: 2 Aug 2027)	Open licences skip only documentation and representative duties, and not for systemic-risk models
EU	AI Act: Commission fines for GPAI providers; Article 50 transparency	2 Aug 2026	Article 50 systems are not excluded by an open licence
EU	AI Act: high-risk systems, Annex III (Regulation (EU) 2026/1744)	2 Dec 2027	No open-source exclusion for high-risk systems
EU	AI Act: high-risk AI in Annex I products	2 Aug 2028	As above
EU	Cyber Resilience Act, Regulation (EU) 2024/2847	Reporting 11 Sep 2026; main duties 11 Dec 2027	Duties for open-source software stewards (Article 24)
US	Export controls on AI model weights (Jan 2025 rule)	Rescission announced 13 May 2025	The rule covered closed-weight models only; check BIS for the current rule
US	NIST AI RMF and Generative AI Profile	Jan 2023; Jul 2024	Voluntary
US	State AI laws	See the Regulation Tracker	Disclosure and human-review duties apply whatever the licence
China	Interim Measures for Generative AI Services	15 Aug 2023	Filing for public-facing services, whatever the model's origin
China	Network Data Security Management Regulations	1 Jan 2025	Article 19: security management of generative AI training data
India	Digital Personal Data Protection Rules 2025	Notified Nov 2025; phased	Check the current phase before relying on it

Jurisdiction Applicability Check

Users in the EU: AI Act and GDPR duties mapped, including whether the licence qualifies as free and open-source under the Act?

Releasing a modified general-purpose model: training compute for the modification compared with a third of the original model's (the Commission's indicative test for becoming its provider)?

Llama 4 multimodal models: is your company's principal place of business in the EU?

US federal customers: NIST AI RMF expectations and current export rules checked?

Service offered to the public in China: filing route confirmed?

Regulatory monitoring assigned to a named person, with a quarterly review?

Section 5: Sector Addenda

Complete the addendum for each sector you operate in. Sector duties stack on top of the licence and regulatory baseline above, and they apply to an open-weight model exactly as they do to a bought one.

Healthcare: FDA, HIPAA, IEC 62304

An open model in a medical device or clinical workflow needs the same dependency documentation, reproducible builds and vulnerability response as any other component. If you cannot produce the documentation, you cannot use the component.

AI that contributes to medical decisions reviewed against FDA's draft guidance on AI-enabled device software functions (January 2025, docket FDA-2024-D-4488)?

Predetermined Change Control Plan in place for model version updates, following FDA's final PCCP guidance for AI-enabled device software functions?

Training data provenance checked: could the model have been trained on protected health information, and can you document it?

Business associate agreements in place for every vendor that processes PHI for the AI system?

IEC 62304 "software of unknown provenance" (SOUP) handled: each open component identified, with its version and known anomalies?

Reproducible builds documented for every open source AI component?

CVE response process defined, with timeframes your regulatory filings commit to?

Healthcare Notes

Financial Services: Model Risk, SOX, PCI DSS, SEC

A free model still needs controls. With an open model you own the whole model lifecycle, including the gap between a vulnerability's disclosure and its fix, which a commercial vendor would otherwise manage.

Model risk management applied to open models used in credit, trading or risk decisions, under the Federal Reserve, OCC and FDIC Revised Guidance on Model Risk Management (SR 26-2, 17 April 2026, which replaced SR 11-7)?

Validation covers the base model and every fine-tune you run?

SOX Section 404 internal controls cover open source governance: licence compliance, security review and change control?

PCI DSS requirements applied to payment systems that use open source components?

Patch SLA defined for open source vulnerabilities in scope for PCI DSS?

Marketing and disclosure claims about AI checked against what the models actually do (the SEC has brought "AI washing" cases)?

Financial Services Notes

Government: FedRAMP, Section 508, CMMC

Selling to the US government adds authorisation, accessibility and supply-chain duties, and an open source component is in scope for each of them.

FedRAMP authorisation at the right impact level for cloud-hosted AI services, with open source provenance documented for the assessor?

Section 508 accessibility (the revised standards incorporate WCAG 2.0 Level AA) met by citizen-facing AI applications?

Accessibility tested at each stage of development and again at release?

CMMC requirements applied to the open source supply chain for defence work?

SBOM produced in the form federal buyers ask for (Executive Order 14028 put software supply-chain security, including SBOMs, into federal procurement)?

Contribution policy defined for staff who contribute to open source projects?

Government Notes

Section 6: Governance Maturity Scorecard

Rate your current state for each area. Ad-hoc: no inventory, individuals decide. Policy-driven: tiers defined, scanning in the pipeline, legal review for non-standard licences. Governed: continuous monitoring, lineage and training data recorded, cross-functional owners, audit-ready.

Section 7: Eight-Week Planner

A suggested sequence from ad-hoc to policy-driven. Adjust the pace to the size of your inventory.

Notes and Action Items

Glossary

Open weight. A model whose trained parameters are published under a licence its developer wrote. Training code and data may not be released, and the licence may limit who can use the model or for what.

Open source AI (OSI definition 1.0, October 2024). An AI system anyone may use for any purpose without asking permission, with its code, parameters and detailed training-data information available under OSI-approved terms.

Model lineage. The chain of base models, fine-tunes and distillations behind a model. Custom model licences such as Llama, Gemma and the Qwen License attach terms to derivatives, so the strictest term anywhere in the chain governs the model.

Three-tier policy. Permitted (permissive OSI-approved licences across the whole lineage), Restricted (custom model licences and copyleft; legal sign-off and a named owner), Prohibited (research-only licences in revenue-linked work, unlicensed components, AGPL in services unless cleared).

SBOM. A machine-readable inventory of every component in a software artefact. An AI SBOM adds model weights, base models and training-data sources. Standards: SPDX and CycloneDX.

General-purpose AI model (EU AI Act, Chapter V). A model trained on broad data that can perform a wide range of tasks. Duties apply from 2 August 2025; a model trained with more than 10²⁵ FLOPs is presumed to have systemic risk (Article 51(2)) and gets no open-source relief.

AGPL. A copyleft licence that extends the source-sharing duty to users who interact with the software over a network, which matters for any AI service.

PCCP. A Predetermined Change Control Plan, the FDA route for authorising planned changes to an AI-enabled device in advance.

EU AI Act penalty tiers (Article 99). Up to EUR 35 million or 7% of worldwide turnover for prohibited practices; up to EUR 15 million or 3% for most other breaches, including high-risk duties; up to EUR 7.5 million or 1% for incorrect information to authorities. Fines on general-purpose model providers sit in Article 101. An open licence does not reduce them.

Evidence Base

The checklist is the working layer of a sourced article. The licence terms, the audit and the AI Act provisions behind it are set out and linked there.

Companion article: Open Weight Is Not Open Source, and Nobody Read the Licence, with each licence's terms read at source on 6 October 2026.

Related on AskAjay.ai:

Regulation Tracker: current AI rules and dates by jurisdiction
Minimum Viable Governance (MVG): the 90-day governance baseline this checklist plugs into
The AI That Hurts You Is Not the AI You Own: the same questions for AI you buy from vendors
EU AI Act guide: the Act's risk tiers in depth

Primary sources: OSI Open Source AI Definition · AI Act and Regulation (EU) 2026/1744 · Commission GPAI guidelines · Cyber Resilience Act · SR 26-2 · FDA AI-enabled device software guidance · NIST AI RMF