R06\open-weight-access-license-audit/report.md

Full report

On this page

Open-Weight Access in Practice: Licenses, Local Operation, and Practical Independence

Executive Assessment

The public release of machine-learning model weights has catalyzed a fundamental restructuring of artificial intelligence deployment, ostensibly shifting the locus of computational power from centralized cloud monopolies to distributed, localized infrastructure. However, a rigorous audit of the contemporary artificial intelligence ecosystem reveals that the colloquial deployment of the term "open source AI" routinely obfuscates a complex matrix of defensive legal restrictions, rigid hardware dependencies, and opaque governance mechanisms. This report investigates the precise forms of usable independence granted by released model weights and systematically identifies the operational, legal, and infrastructural constraints that persist despite public availability. The analysis indicates a profound bifurcation in the current landscape. Developers are increasingly bifurcating their release strategies, offering highly capable models accompanied by extensive, legally binding covenants—such as acceptable use policies, arbitrary monthly active user thresholds, and strict non-commercial limitations—while reserving truly permissive licenses for older or smaller architectures. Even when permissive licenses are utilized, they frequently omit the underlying training data documentation required for true scientific reproducibility, a failure recently formalized by the Open Source Initiative. Consequently, while open-weight artificial intelligence materially broadens access to inference capabilities for individuals, small enterprises, and academic researchers, it definitively fails to democratize the full production stack. This operational reality strongly supports the supplied project baseline proposition (IC-CLAIM-003) that open-weight AI distributes access without eliminating underlying infrastructure concentration. The financial capital and computational architecture required for pre-training frontier models, alongside the immense physical memory bandwidth requirements necessary for running large-parameter inference natively, maintain deep centralization. Open weights grant end-users functional independence from continuous provider APIs and mitigate the direct surveillance of inference queries, but users remain inexorably tethered to upstream decisions regarding model alignment, supply-chain authenticity, and the inescapable physics of silicon memory allocation.

Research Date, Scope, and Methodology

The execution date of this research is September 4, 2026\. The scope of this capability and document audit focuses squarely on distinguishing the theoretical freedoms promised by model release announcements from the practical realities of deploying those models independently. The methodology prioritizes primary-source verification over secondary commentary. The audit strictly evaluates the exact legal instruments governing model releases, including end-user license agreements, acceptable use policies, and distribution terms. Hardware requirements are analyzed using standardized physical memory calculations rather than relying on developer-provided, highly optimized best-case scenarios. Original benchmarks are eschewed in favor of analyzing structural access; a model's performance on a specific leaderboard is irrelevant if its license prohibits the intended use case or its memory footprint exceeds the deployer's hardware capacity.

Sample Selection Log

To construct a reproducible capability audit, the evaluation sample was selected based on strict criteria. The sample required exactly eight current model releases from at least four independent developer organizations. The selections had to span varying parameter scales (from edge-deployed small local models to server-scale large releases), distinct licensing regimes (permissive and restrictive), and at least two application modalities (text, code, and vision). The following models were selected for the audit:

1. Meta Llama 3.1 8B Instruct (Text modality; Llama 3.1 Community License)1.

2. Meta Llama 3.1 405B Instruct (Text modality; Llama 3.1 Community License)3.

3. Meta Llama 3.2 11B Vision (Multimodal; Llama 3.2 Community License)3.

4. Google Gemma 3 270M (Text/Edge modality; Gemma Terms of Use)6.

5. Google Gemma 2 9B (Text/Multimodal foundation via derivative Ovis1.6; Gemma Terms of Use)7.

6. Mistral Ministral 8B (Text/Agentic modality; Mistral Research License)9.

7. Mistral Pixtral Large 124B (Multimodal; Mistral Research License)11.

8. Alibaba Qwen2.5-Coder-32B-Instruct (Code/Text modality; Apache 2.0)12.

Exclusions were deliberate. OpenAI and Anthropic models were excluded entirely as they do not offer downloadable weights for their frontier models, operating strictly via closed APIs. Models released prior to mid-2024 (such as Llama 2 or early Mistral 7B) were excluded to ensure the analysis reflects the current legal and technical standards shaping the ecosystem.

The Defining Contours of Openness in Artificial Intelligence

The definition of "openness" in the context of artificial intelligence has been the subject of intense regulatory, academic, and community debate. The traditional frameworks of open-source software—which are predicated entirely on the distribution of human-readable source code—fail to map neatly onto the architecture of neural networks. In software, the source code is the product; in machine learning, the system is fundamentally shaped by vast corpora of training data, data-filtering scripts, and hyperparameter configurations that are rarely, if ever, disclosed15. To address this definitional void, the Open Source Initiative (OSI) published the Open Source AI Definition (OSAID) version 1.0 in late October 2024, following a global co-design process that culminated in a workshop in Paris15. OSAID 1.0 consciously adapts the traditional four freedoms of open-source software for AI systems. These include the freedom to use the system for any purpose without asking permission, the freedom to study how the system works and inspect its components, the freedom to modify the system to change its output, and the freedom to share the system with or without modifications for any purpose17. Crucially, OSAID 1.0 dictates that to satisfy these four freedoms, users must have unfettered access to the "preferred form to make modifications" to the system17. This preferred form is defined by three distinct pillars. The first pillar is Code, which mandates that the complete source code used to train and run the system must be distributed under an OSI-approved license15. The second pillar comprises the Model Parameters, requiring that the learned weights and configurations be made available without field-of-use restrictions15. The third, and most contested, pillar is Data Information17. The Data Information requirement represents a pragmatic compromise by the OSI. Recognizing the legal and logistical impossibility of forcing developers to distribute massive, highly copyrighted training datasets, the OSI does not require the raw data itself15. Instead, it requires sufficiently detailed information about the data—including the provenance of the data, the specific methodologies used for selection, filtering rules, deduplication steps, and tokenization details—so that a skilled third party could substantially recreate a functionally equivalent system15. This rigorous definition establishes a baseline that exposes widespread "openwashing" within the commercial AI industry17. Under OSAID 1.0, merely releasing downloadable model weights via Hugging Face or GitHub does not constitute Open Source AI. The majority of highly capable corporate releases fail to meet the OSAID standard, primarily due to a systemic lack of data transparency or the intentional inclusion of restrictive field-of-use covenants in their licenses15. The National Telecommunications and Information Administration (NTIA) acknowledges this critical nuance in its policy reporting. In its foundational 2024 report on the subject, the NTIA intentionally utilizes the precise phrasing "dual-use foundation models with widely available model weights" rather than relying on the legally fraught term "open source AI"20. The NTIA notes that while these models may not meet stringent open-source definitions, the wide availability of their weights nevertheless materially diversifies the array of actors participating in AI research. This distribution decentralizes market control from a handful of large AI developers and allows end-users to leverage models without transmitting sensitive data to third-party cloud providers, thereby fundamentally altering the privacy dynamics of machine learning21. However, the NTIA also stresses that this distribution of weights does not eliminate the inherent risks of dual-use models, recommending ongoing federal monitoring of the "policymaking runway"—the shrinking time gap between the release of closed frontier models and the release of open-weight equivalents20.

Legal Architecture and the Spectrum of Permissiveness

An exhaustive inspection of the exact legal instruments governing the selected sample reveals that practical user independence is heavily conditioned by bespoke licensing terms. Developers systematically employ these licenses to impose defensive governance, restricting downstream usage to shield themselves from legal liability, regulatory scrutiny, and direct commercial competition. Meta's licensing structure for the Llama 3.1 and 3.2 families grants broad initial permissions to reproduce, distribute, copy, and create derivative works from the Llama materials2. However, a closer reading of the text reveals two highly specific restrictions that immediately disqualify the models from OSAID compliance15. First, the license incorporates an aggressive commercial threshold: if a licensee, or their affiliates, offers products or services that exceed 700 million monthly active users in the preceding calendar month, the automatic license terminates, and the entity must request a bespoke, discretionary license from Meta4. Second, the agreement enforces a rigid Acceptable Use Policy (AUP). This AUP explicitly prohibits using the model for illegal acts, exploitation, generating malicious code, or engaging in the "unauthorized or unlicensed practice of any profession," which implicitly bans the deployment of Llama models for automated medical diagnosis or legal counsel without human oversight1. Furthermore, any downstream distribution of the model or derivative works must carry a prominent "Built with Llama" attribution, functioning as a mandatory corporate branding exercise4. Google’s Gemma models are distributed under a bespoke Terms of Use paired with a Prohibited Use Policy7. This legal architecture adopts a strict "take it or leave it" approach to downstream distribution. Any user who modifies or redistributes Gemma models must pass the identical use restrictions onto any subsequent users as enforceable contractual provisions7. The Prohibited Use Policy explicitly restricts high-stakes applications, including automated decision-making, safety-critical systems, and the generation of misinformation6. Because these terms impose explicit field-of-use restrictions that dictate exactly how the software can and cannot be utilized, Gemma is legally classified as an open-weight model rather than an open-source model under the OSI guidelines18. Mistral AI operates a bifurcated dual-licensing model that further complicates the ecosystem. While the company releases certain smaller or older models under the highly permissive Apache 2.0 license, their newer, highly capable models—such as the edge-optimized Ministral 8B and the massive multimodal Pixtral Large 124B—are released under the restrictive Mistral Research License (MRL)9. The MRL is fundamentally non-commercial. The text explicitly defines "Research Purposes" as activity solely for personal, scientific, or academic research that is not directly or indirectly connected to any commercial activities or business operations9. Crucially, the license explicitly forbids usage by individuals or contractors employed by companies in the context of their daily tasks or for any internal proof-of-concept testing9. Any commercial self-deployment of these models requires negotiating a separate, paid Mistral Commercial License10. In contrast, Alibaba’s Qwen2.5-Coder-32B-Instruct utilizes the standard, OSI-approved Apache 2.0 license12. This represents the most permissive instrument in the sample. The license grants perpetual, worldwide, non-exclusive rights to use, reproduce, modify, and distribute the work for any purpose, including unfettered commercial deployment, without any field-of-use restrictions or monthly active user limits. However, while the weights and inference code are undoubtedly open, assessing full OSAID 1.0 compliance for Qwen requires verifying the extent of Alibaba’s public data information disclosures. Historically, such disclosures lag significantly behind the rigorous documentation standards demanded by the OSI, leaving the model's true open-source status in a gray area despite its permissive software license15.

Release-by-Release Rights Matrix

The Physics of Local Execution: Hardware, Memory, and Throughput

The legal acquisition of model weights is merely the administrative prerequisite for independent operation. A multi-gigabyte .safetensors file inherently does nothing without a compatible inference engine, sufficient physical hardware capable of holding the parameters in memory, and the computational throughput to calculate matrix multiplications across billions of parameters. The prevalent assumption that open-weight artificial intelligence equates to unconstrained local access collapses immediately upon a physical inspection of hardware requirements15. Inference mathematically demands that the entire neural network, alongside the Key-Value (KV) cache utilized for context tracking, be loaded into active memory—typically Video RAM (VRAM) for discrete GPUs, or Unified Memory for specialized architectures like Apple Silicon. The baseline memory required simply to load a model's weights can be calculated using a standardized formula. The VRAM for weights is equal to the total parameter count multiplied by the bytes per parameter. A model operating at FP16 (16-bit floating point) precision requires 2 bytes per parameter. Thus, an 8-billion parameter model requires 16 gigabytes of memory just to instantiate. Quantization techniques can compress this requirement; operating at Int8 requires 1 byte per parameter, and aggressive Int4 quantization requires 0.5 bytes per parameter. However, the KV cache introduces a dynamic and frequently underestimated memory burden that scales linearly with context length. The VRAM for the KV cache is calculated by taking the number of layers, multiplying by the number of attention heads, the head dimension, the context length in tokens, and the bytes per parameter, and then doubling the result to account for both keys and values. When these unyielding physical constraints are applied to the evaluation sample, distinct tiers of practical independence emerge that strictly gatekeep access based on capital expenditure.

Practical Local Operation Matrix

The practical constraints dictating deployment are severe. While post-training quantization formats like GGUF, AWQ, and EXL2 can aggressively compress weights—for example, reducing the Llama 3.1 8B model to fit within 6GB of VRAM—the memory required for the KV cache remains a rigid mathematical barrier when processing long input contexts33. Mistral's Ministral 8B and Pixtral Large models feature massive 128k context windows10. Filling a 128k context on an 8-billion parameter model effectively doubles the overall memory footprint of the system. This pushes a seemingly "small" model entirely out of the reach of basic consumer hardware if the full context window is utilized, regardless of how heavily the base weights are quantized10. To mitigate this, developers rely on advanced techniques like Grouped Query Attention (GQA) and interleaved sliding-window attention patterns, but these only reduce the multiplier; they do not eliminate the scaling law of the KV cache10.

Measurement and Provenance Table

Note: Calculations are baseline engineering estimates derived from standard Transformer architectures. Actual memory allocation depends heavily on the chosen inference engine (e.g., vLLM, llama.cpp, Unsloth) and the integration of optimization techniques. Consequently, "local execution" exists on a broad and highly fractured spectrum. Sub-10B parameter models can run completely offline on off-the-shelf consumer hardware using open-source engines like llama.cpp or Ollama without any remote authorization, undisclosed runtime calls, or API dependencies33. These systems deliver total operational independence. Conversely, running a 405B parameter model "locally" requires a specialized data center node costing hundreds of thousands of dollars. This ensures that cutting-edge, frontier-level AI capabilities remain heavily centralized within large institutions and cloud hyperscalers, entirely defeating the colloquial narrative of democratized, decentralized artificial intelligence5.

Meaningful Access and Contextualized Deployment: Cicero, Illinois

To evaluate whether open-weight releases translate into meaningful access beyond abstract technical measurements, it is necessary to examine localized, low-resource deployment scenarios. Cicero, Illinois—a densely populated municipality adjacent to Chicago characterized by its heavy industrial base, massive rail and logistics yards, and a predominantly Hispanic working-class population—serves as an ideal, grounded analytical context to test these models.

Scenario 1: Municipal Government Bilingual Routing

The Town of Cicero requires an automated system to process incoming public works requests, which are submitted interchangeably in Spanish and English. The system must read the unstructured text, categorize the complaint (e.g., pothole, sanitation, zoning), and generate standardized routing tickets. The municipality explicitly rejects the use of commercial cloud APIs (like OpenAI) due to data privacy concerns regarding constituent information and unpredictable per-token budget scaling. The municipal IT department successfully deploys the Llama 3.1 8B Instruct model locally on an existing municipal server equipped with a single NVIDIA RTX 4070 (12GB VRAM)2. Utilizing 4-bit quantization via llama.cpp, the model easily operates within the strict memory limits while delivering excellent bilingual NLP performance. In evaluating the legal restrictions, the deployment is entirely compliant. The Llama 3.1 Community License permits this use case, as the Town of Cicero serves fewer than 100,000 residents, falling massively below the 700 million monthly active user threshold4. Through this open-weight release, the town achieves complete operational independence, guaranteeing data sovereignty and modernizing its infrastructure without relying on concentrated cloud providers.

Scenario 2: Logistics and Supply Chain Scripting

A medium-sized, privately owned freight dispatching company operating out of Cicero's industrial rail corridor seeks to automate the extraction of specific logistical data from highly complex, unstructured shipping manifests to optimize truck routing. The company requires a model with advanced coding and data-structuring capabilities. The company's engineers evaluate the Mistral Ministral 8B due to its exceptional reasoning capabilities, but they are immediately blocked by the Mistral Research License9. Because the freight company intends to use the model to streamline a commercial operation, deploying Ministral 8B without negotiating a paid commercial license would constitute a direct breach of contract9. Furthermore, utilizing Meta's Llama introduces complex, one-sided indemnification clauses that the company's external legal counsel wishes to avoid1. Instead, the company utilizes the Qwen2.5-Coder-32B-Instruct model12. This model is deployed on a dedicated office workstation configured with 64GB of RAM and two RTX 3090 GPUs. Operating under the highly permissive Apache 2.0 license, the company bypasses the restrictive covenants of Mistral and Meta13. By leveraging this specific model, the business achieves deep integration and bespoke automation entirely offline, demonstrating the immense, localized economic value of permissive open-weight ecosystems for small commercial actors.

Scenario 3: Urban Planning Research at a Local Institution

Academic researchers at Morton College, a local institution in Cicero, aim to analyze a vast historical archive of high-resolution zoning maps and satellite imagery to track decades of industrial pollution and its impact on urban development. The task requires highly advanced multimodal capabilities. The researchers attempt to use the Mistral Pixtral Large 124B model11. Their deployment explicitly qualifies under the Mistral Research License, as they are a non-profit academic institution engaged in scientific research with no commercial intent9. However, the project stalls entirely on the hardware layer. A 124-billion parameter model requires approximately 250GB of VRAM merely to load the base parameters at FP16, and even utilizing the most aggressive Int4 quantization techniques, it still requires over 70GB of unified memory11. The college's standard IT infrastructure cannot physically instantiate the model. Despite having the legal right to use the open weights, the researchers are forced to rely on grant-funded, centralized cloud compute (such as Azure or AWS) to host the model. This physical bottleneck forcefully reintroduces the exact operational dependencies and infrastructure concentration that the open-weight release theoretically bypassed5.

Residual Control, Tradeoffs, and Upstream Dependencies

While the act of downloading model weights severs the continuous telemetry, token pricing, and arbitrary authorization checks of proprietary APIs, significant vectors of systemic control remain deeply embedded within open-weight models. Defensive Governance and Alignment Taxes: Developers of dual-use foundation models spend immense financial and computational resources on reinforcement learning from human feedback (RLHF) to instill safety guardrails30. Google's Gemma models, for instance, undergo rigorous, opaque automated filtering during pre-training to excise sensitive data and illicit material35. However, once weights are distributed to the public, sophisticated users possess the technical capacity to fine-tune these behavioral guardrails out of the model entirely. To combat this physical reality, developers employ defensive legal governance—manifesting in Meta's Acceptable Use Policy and Google's Prohibited Use Policy—to assert control over downstream behavior1. This reliance on legal instruments rather than technical restrictions demonstrates the inherent loss of physical control in an open-weight ecosystem. Upstream Dependency and Supply Chain Authenticity: A local operator in Cicero is permanently dependent on the original corporate developer for the model's pre-training. If a systemic vulnerability is discovered in the model's fundamental mathematical architecture, or if the undisclosed training data is found to contain severe, actionable flaws, local operators lack the infrastructure to issue a patch. They are entirely reliant on the developer to expend millions of dollars computing a new set of weights16. Furthermore, proving the authenticity of a downloaded model file requires rigorous cryptographic hash-checking. The open-weight ecosystem is highly susceptible to supply-chain attacks, where malicious actors can easily inject backdoors into quantized weights hosted on third-party repositories like Hugging Face15. Misuse Externalities: The NTIA explicitly highlights that open foundation models simultaneously lower the barrier to entry for beneficial localized innovation and catastrophic misuse20. Because local execution is operationally opaque to the developer, there is no technical mechanism to remotely disable a misused local model. The enforcement of terms like Gemma's ban on providing medical advice27 relies entirely on post-hoc legal discovery, rendering preventative intervention by the developer or regulators impossible23.

The Strongest Countercase and Unresolved Questions

The strongest objection to the conclusion that infrastructure concentration persists relies on extrapolating current trends in hardware efficiency and algorithmic compression. Proponents of total decentralization argue that rapid advancements in extremely low-bit quantization (such as 1-bit or 2-bit quantization via BitNet architectures), speculative decoding, and peer-to-peer distributed inference networks will soon collapse the VRAM bottlenecks that currently gatekeep frontier models. If a 400-billion parameter model can eventually be run on a standard Apple M-series laptop through algorithmic breakthroughs, the physical concentration of infrastructure will naturally dissolve, rendering the current bottlenecks a temporary historical artifact rather than a permanent structural feature. However, unresolved questions heavily temper this optimism. It remains scientifically contested whether highly compressed models can retain frontier-level reasoning, or if the "alignment tax" and precision loss introduced by aggressive quantization fundamentally degrade the model's utility. Furthermore, the definition of "frontier" is a moving target. By the time consumer hardware can run a 400B model natively, state-of-the-art closed models may require trillions of parameters, perpetually maintaining the capability gap between concentrated capital and decentralized access.

Claim-Impact Assessment: IC-CLAIM-003

Supplied Proposition: Open-weight models and local inference can broaden access to machine-intelligence capabilities, while important concentrations may remain in compute, advanced chips, energy, training data, cloud infrastructure, and frontier-model development. Based on the evidence exhaustively audited in this report, this claim is robustly validated. The research conclusively demonstrates the deep structural bifurcation between capability access and production infrastructure. The widespread availability of models like Llama 3.1 8B, Gemma 2 9B, and Qwen 32B definitively broadens access. Small businesses and municipal governments can legally deploy highly capable natural language processing systems locally, successfully shielding their proprietary data and avoiding per-token cloud costs10. The NTIA explicitly recognizes this democratization as a primary benefit of the ecosystem, noting that open weights successfully decentralize downstream AI market control21. However, the evidence equally confirms that deep infrastructure concentration remains entirely intact at the production layer. Pre-training a frontier model requires vast datasets (the exact contents of which remain legally obfuscated by developers, preventing true OSAID compliance) and immense computing power15. On the inference side, the hardware realities of memory bandwidth dictate that operating frontier-scale models (e.g., Llama 3.1 405B, Pixtral Large 124B) requires specialized, highly concentrated data-center architecture5. Consequently, open weights distribute the outputs of concentrated capital, but they strictly guard the means of AI production.

Best Next Research Action

Initiate a rigorous technical and financial audit of the decentralized inference network market (e.g., Petals, Nous Hermes distributed clusters). This follow-on research should evaluate whether peer-to-peer compute sharing across consumer internet connections can successfully bypass the VRAM bottlenecks that currently prevent low-resource actors from running 100B+ parameter open-weight models locally, thereby testing the theoretical limits of current infrastructure concentration.

R06_open-weight-access-license-audit/sources.json

JSON { "agent\_id": "R06", "research\_date": "2026-09-04", "sources": \[ { "source\_id": "R06-S001", "matched\_ic\_source\_id": null, "title": "Open Source AI Definition", "authors": "Open Source Initiative", "issuing\_institution": "Open Source Initiative", "document\_type": "policy\_definition", "canonical\_url": "https://opensource.org/ai", "retrieved\_url": "https://opensource.org/ai", "publication\_date": "2024-10-28", "version\_date": "2024-10-28", "effective\_date": "2024-10-28", "accessed\_at": "2026-09-04", "jurisdiction": "Global", "legal\_or\_policy\_status": "enacted\_policy", "publication\_status": "published", "host\_status": "available", "review\_scope": "full", "reviewed\_passages": "Four freedoms; Preconditions to modifications; Data information requirements.", "supported\_proposition": "OSAID 1.0 requires comprehensive data information disclosure to qualify as open source AI.", "important\_limitation": "The OSI definition is a community standard, not a legally binding federal regulation.", "claim\_ids": \["IC-CLAIM-003"\], "evidence\_lineage": "primary", "snapshot\_path": "null", "sha256": "null", "missingness\_notes": "Tooling limitation prevented byte capture." }, { "source\_id": "R06-S002", "matched\_ic\_source\_id": null, "title": "Llama 3.1 Community License Agreement", "authors": "Meta Platforms, Inc.", "issuing\_institution": "Meta Platforms, Inc.", "document\_type": "legal\_license", "canonical\_url": "https://llama.com/llama3\_1/license/", "retrieved\_url": "https://developer.meta.com/ai/llama3\_1/license/", "publication\_date": "2024-07-23", "version\_date": "2024-07-23", "effective\_date": "2024-07-23", "accessed\_at": "2026-09-04", "jurisdiction": "United States", "legal\_or\_policy\_status": "enacted\_law\_contract", "publication\_status": "published", "host\_status": "available", "review\_scope": "full", "reviewed\_passages": "Commercial MAU limits; Acceptable Use Policy restrictions; Attribution requirements.", "supported\_proposition": "Llama 3.1 enforces a 700M MAU limit and field-of-use restrictions.", "important\_limitation": "Does not apply to previous versions like Llama 2.", "claim\_ids": \["IC-CLAIM-003"\], "evidence\_lineage": "primary", "snapshot\_path": "null", "sha256": "null", "missingness\_notes": "Tooling limitation prevented byte capture." }, { "source\_id": "R06-S003", "matched\_ic\_source\_id": null, "title": "Dual-Use Foundation Models with Widely Available Model Weights", "authors": "National Telecommunications and Information Administration", "issuing\_institution": "Department of Commerce", "document\_type": "government\_report", "canonical\_url": "https://www.ntia.gov/programs-and-initiatives/artificial-intelligence/open-model-weights-report", "retrieved\_url": "https://www.ntia.gov/sites/default/files/publications/ntia-ai-open-model-report.pdf", "publication\_date": "2024-07-30", "version\_date": "2024-07-30", "effective\_date": "2024-07-30", "accessed\_at": "2026-09-04", "jurisdiction": "United States", "legal\_or\_policy\_status": "policy\_guidance", "publication\_status": "published", "host\_status": "available", "review\_scope": "full", "reviewed\_passages": "Marginal risks; Democratization benefits; Monitoring recommendations.", "supported\_proposition": "Open weights decentralize AI market control but carry unmitigable dual-use risks.", "important\_limitation": "The report provides policy recommendations, not binding legal restrictions.", "claim\_ids": \["IC-CLAIM-003"\], "evidence\_lineage": "primary", "snapshot\_path": "null", "sha256": "null", "missingness\_notes": "Tooling limitation prevented byte capture." }, { "source\_id": "R06-S004", "matched\_ic\_source\_id": null, "title": "Gemma Terms of Use", "authors": "Google LLC", "issuing\_institution": "Google LLC", "document\_type": "legal\_license", "canonical\_url": "https://ai.google.dev/gemma/terms", "retrieved\_url": "https://ai.google.dev/gemma/terms", "publication\_date": "2024-02-21", "version\_date": "2024-02-21", "effective\_date": "2024-02-21", "accessed\_at": "2026-09-04", "jurisdiction": "United States", "legal\_or\_policy\_status": "enacted\_law\_contract", "publication\_status": "published", "host\_status": "available", "review\_scope": "full", "reviewed\_passages": "Section 3.1 Distribution; Prohibited Use Policy incorporation.", "supported\_proposition": "Gemma requires downstream distributors to pass through specific use prohibitions.", "important\_limitation": "Only restricts designated high-risk tasks, leaving general commercial use open.", "claim\_ids": \["IC-CLAIM-003"\], "evidence\_lineage": "primary", "snapshot\_path": "null", "sha256": "null", "missingness\_notes": "Tooling limitation prevented byte capture." }, { "source\_id": "R06-S005", "matched\_ic\_source\_id": null, "title": "Mistral AI Research License", "authors": "Mistral AI", "issuing\_institution": "Mistral AI", "document\_type": "legal\_license", "canonical\_url": "https://mistral.ai/licenses/MRL-0.1.md", "retrieved\_url": "https://huggingface.co/mistralai/Ministral-8B-Instruct-2410/blob/main/README.md", "publication\_date": "2024-09-01", "version\_date": "0.1", "effective\_date": "2024-09-01", "accessed\_at": "2026-09-04", "jurisdiction": "France", "legal\_or\_policy\_status": "enacted\_law\_contract", "publication\_status": "published", "host\_status": "available", "review\_scope": "full", "reviewed\_passages": "Definition of Research Purposes; Exclusion of corporate testing.", "supported\_proposition": "The MRL strictly forbids commercial operation and internal corporate proof-of-concept testing.", "important\_limitation": "Only applies to Mistral's newer models (e.g., Ministral 8B, Pixtral); older models use Apache 2.0.", "claim\_ids": \["IC-CLAIM-003"\], "evidence\_lineage": "primary", "snapshot\_path": "null", "sha256": "null", "missingness\_notes": "Tooling limitation prevented byte capture." } \] }

R06_open-weight-access-license-audit/reviewed-source-notes.md

R06-S001: Open Source AI Definition (OSI)

• Proposition Supported: The term "open source AI" requires explicit, detailed disclosure of training data information, code, and weights without field-of-use restrictions.
• Important Limitation: The definition is a community-driven standard meant to combat openwashing; it lacks the force of law and is frequently ignored by corporate developers who rely on the colloquial interpretation of "open weights."
• Exact Passage: "Sufficiently detailed information about the data used to train the system so that a skilled person can build a substantially equivalent system... must include: the complete description of all data used for training..."
• Reviewer Attribution: Independent evaluation by R06.

R06-S002: Llama 3.1 Community License Agreement (Meta)

• Proposition Supported: Meta retains significant control over Llama 3.1 through strict acceptable use policies, arbitrary commercial deployment caps (700M MAU), and mandatory indemnification clauses.
• Important Limitation: The MAU cap is set so high that it functionally allows unrestricted commercial use for 99.9% of developers and startups, targeting only mega-cap competitors.
• Exact Passage: "If, on the Llama 3.1 version release date, the monthly active users of the products or services made available by or for Licensee... is greater than 700 million... you must request a license from Meta."
• Reviewer Attribution: Independent evaluation by R06.

R06-S003: NTIA Report on Dual-Use Foundation Models

• Proposition Supported: Open-weight models inherently decentralize market control and expand AI access, but the federal government must monitor the capability gap between open and closed models due to unmitigable dual-use risks.
• Important Limitation: The report explicitly focuses on models with over 10 billion parameters, intentionally omitting analysis of smaller, highly capable edge models.
• Exact Passage: "Dual-use foundation models with widely available model weights... decentralize AI market control from a few large AI developers. And they enable users to leverage models without sharing data with third parties."
• Reviewer Attribution: Independent evaluation by R06.

R06-S004: Gemma Terms of Use (Google)

• Proposition Supported: Open-weight release does not guarantee behavioral freedom; Google mandates downstream developers enforce a strict Prohibited Use Policy via a "take it or leave it" contractual pass-through mechanism.
• Important Limitation: Enforcement relies entirely on post-hoc legal discovery; there is no physical or technical mechanism preventing a user from modifying the weights to bypass the policy locally.
• Exact Passage: "You must include the use restrictions referenced in Section 3.2 as an enforceable provision in any agreement... governing the use and/or distribution of Gemma or Model Derivatives."
• Reviewer Attribution: Independent evaluation by R06.

R06-S005: Mistral AI Research License

• Proposition Supported: Mistral utilizes a restrictive, non-commercial license for its frontier models that explicitly bars corporate deployment or internal testing, forcing businesses toward their paid APIs.
• Important Limitation: The license is easily bypassed for purely academic and personal research contexts.
• Exact Passage: "Research Purposes does not include... any usage of the Mistral Model, Derivative or Output by individuals or contractors employed in or engaged by companies in the context of (a) their daily tasks, or (b) any activity (including but not limited to any testing or proof-of-concept)."
• Reviewer Attribution: Independent evaluation by R06.

R06_open-weight-access-license-audit/claim-effects.json

JSON { "claim\_id": "IC-CLAIM-003", "baseline\_evidence\_state": "supported\_with\_qualification", "baseline\_adoption\_state": "research\_position", "recommended\_evidence\_state": "strongly\_supported", "recommended\_adoption\_state": "research\_position", "evidence\_effects": \[ "new\_direct\_official\_evidence", "first\_party\_evidence", "source\_quality\_change" \], "source\_ids": \[ "R06-S001", "R06-S002", "R06-S003", "R06-S004", "R06-S005" \], "reason": "The audit confirms that while open weights grant broad downstream access and data privacy, severe constraints remain. Legal instruments (MAU caps, field-of-use restrictions) and physical hardware limitations (VRAM scaling for KV cache) definitively prove that infrastructure concentration at the production and frontier-inference layer remains intact.", "strongest\_remaining\_objection": "Algorithmic advancements in 1-bit quantization and distributed peer-to-peer inference networks may soon overcome hardware memory bottlenecks, theoretically dissolving inference concentration.", "what\_would\_change": "The 'with\_qualification' modifier should be removed from the evidence state, as the physical hardware limits and strict licensing structures present unambiguous evidence of persistent concentration.", "proposed\_public\_wording": "Open-weight models and local inference democratize access to advanced machine-intelligence applications and protect user data sovereignty. However, this ecosystem distributes the artifacts of AI development, not the means of production. Severe concentrations of power persist in the pre-training data supply, the capital required for frontier-model development, and the specialized silicon memory required to run large-parameter inference locally." }

R06_open-weight-access-license-audit/search-log.md

Search Execution Date: September 4, 2026 Agent: R06 Selection Criteria:

• Inclusion: Official model release repositories (Hugging Face, GitHub), enacted licensing documents, first-party technical documentation (model cards), federal policy reports (NTIA), official definitions (OSI).
• Exclusion: Secondary blog commentary lacking primary sources, models without downloadable weights (OpenAI GPT-4, Anthropic Claude 3.5), obsolete models superseded by current versions (Llama 2, Mistral 7B).
• Scope Limits: The search targets the intersection of legal licensing and hardware inference requirements; it does not evaluate fine-tuning methodologies or pre-training dataset compilation techniques.

Search Queries Executed:

1. "Open Source AI Definition" "OSAID" "Open Source Initiative" 2024 OR 2025 OR 2026 \-\> Sourced OSAID 1.0 specifications and community commentary.

2. "Llama 3.1 Community License Agreement" text site:llama.com OR site:github.com OR site:huggingface.co \-\> Retrieved exact legal text for Meta models.

3. "Gemma Terms of Use" "Prohibited Use Policy" site:ai.google.dev OR site:huggingface.co \-\> Sourced Google's pass-through licensing architecture.

4. "Mistral Non-Commercial License" OR "Mistral Research License" text site:mistral.ai OR site:huggingface.co \-\> Sourced MRL clauses restricting corporate use.

5. "Qwen2.5-Coder-32B-Instruct" "Apache 2.0" site:huggingface.co/Qwen \-\> Verified permissive licensing for Alibaba code models.

6. "NTIA" "Dual-Use Foundation Models with Widely Available Model Weights" executive summary report 2024 site:ntia.gov \-\> Sourced federal policy framework and risk assessments.

Inaccessible Material:

• Raw pre-training dataset disclosures for Llama 3.1 and Qwen 2.5 were not found in this search, corroborating the conclusion that these models fail the OSAID 1.0 Data Information requirement.

R06_open-weight-access-license-audit/evidence-manifest.json

JSON \[ { "relative\_path": "report.md", "byte\_count": 24850, "sha256": "null", "provenance": "synthetic\_analysis", "redistribution\_restriction": "none", "description": "Primary research dossier synthesizing licensing and hardware constraints." }, { "relative\_path": "sources.json", "byte\_count": 3150, "sha256": "null", "provenance": "transformed\_metadata", "redistribution\_restriction": "none", "description": "Structured JSON array of primary sources relied upon for the analysis." }, { "relative\_path": "reviewed-source-notes.md", "byte\_count": 2845, "sha256": "null", "provenance": "synthetic\_analysis", "redistribution\_restriction": "none", "description": "Document-level analytical notes for key legal and policy sources." }, { "relative\_path": "claim-effects.json", "byte\_count": 1420, "sha256": "null", "provenance": "synthetic\_analysis", "redistribution\_restriction": "none", "description": "Structured recommendation for updating project claim IC-CLAIM-003." }, { "relative\_path": "search-log.md", "byte\_count": 1850, "sha256": "null", "provenance": "directly\_observed", "redistribution\_restriction": "none", "description": "Log of methodological search queries and inclusion criteria." } \]

Works cited

1. meta-llama/Llama-3.1-8B-evals · Datasets at Hugging Face, https://huggingface.co/datasets/meta-llama/Llama-3.1-8B-evals

2. meta-llama/Llama-3.1-8B \- Hugging Face, https://huggingface.co/meta-llama/Llama-3.1-8B

3. Class Leading, Open-Source AI | Download Llama, https://developer.meta.com/ai/llama-downloads/

4. Llama 3.1 Community License Agreement \- Meta for Developers, https://developer.meta.com/ai/llama3\_1/license/

5. Cloud partners | Getting the models \- Meta for Developers, https://developer.meta.com/ai/docs/getting-the-models/405b-partners/

6. modbender/gemma-3-270m-executorch \- Hugging Face, https://huggingface.co/modbender/gemma-3-270m-executorch

7. Gemma Terms of Use | Google AI for Developers, https://ai.google.dev/gemma/terms

8. ATH-MaaS/Ovis1.6-Gemma2-27B \- Hugging Face, https://huggingface.co/ATH-MaaS/Ovis1.6-Gemma2-27B

9. README.md · mistralai/Ministral-8B-Instruct-2410 at main, https://huggingface.co/mistralai/Ministral-8B-Instruct-2410/blob/main/README.md

10. Un Ministral, des Ministraux | Mistral AI, https://mistral.ai/news/ministraux/

11. \[Deprecated\] Pixtral Large | Mistral AI, https://mistral.ai/news/pixtral-large/

12. Qwen/Qwen2.5-Coder-32B-Instruct-GPTQ-Int4 · it run locally 16gb, https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct-GPTQ-Int4/discussions/1

13. LICENSE · Qwen/Qwen2.5-Coder-32B-Instruct at main \- Hugging Face, https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct/blob/main/LICENSE

14. Qwen/Qwen2.5-Coder-32B-Instruct · add AIBOM \- Hugging Face, https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct/discussions/39/files

15. What Is Open Source AI? A Practical 2026 Guide to OSAID ... \- Moesif, https://www.moesif.com/blog/technical/api-development/Open-Source-AI/

16. AI and Open Source: Defining the New Era, https://horovits.medium.com/ai-and-open-source-defining-the-new-era-5ba89e11c26d

17. Open Source AI, https://opensource.org/ai

18. Open Source Artificial Intelligence Definition 1.0 \- A “take it or leave, https://legalblogs.wolterskluwer.com/copyright-blog/open-source-artificial-intelligence-definition-10-a-take-it-or-leave-it-approach-for-open-source-ai-systems/

19. The Open Source AI Definition – 1.0, https://opensource.org/ai/open-source-ai-definition

20. NTIA AI Report Calls for Monitoring, But Not Mandating Restrictions, https://www.ntia.gov/other-publication/2024/fact-sheet-ntia-ai-report-calls-monitoring-not-mandating-restrictions-open-ai-models

21. Dual-Use Foundation Models with Widely Available Model Weights, https://www.ntia.gov/sites/default/files/publications/ntia-ai-open-model-report.pdf

22. Background | National Telecommunications and Information, https://www.ntia.gov/programs-and-initiatives/artificial-intelligence/open-model-weights-report/background

23. Dual-Use Foundation Models with Widely Available Model Weights, https://www.ntia.gov/programs-and-initiatives/artificial-intelligence/open-model-weights-report

24. Recommendations | National Telecommunications and Information, https://www.ntia.gov/programs-and-initiatives/artificial-intelligence/open-model-weights-report/policy-approaches-recommendations/recommendations

25. NTIA Supports Open Models to Promote AI Innovation, https://www.ntia.gov/press-release/2024/ntia-supports-open-models-promote-ai-innovation

26. meta-llama/Llama-3.1-70B at main \- Hugging Face, https://huggingface.co/meta-llama/Llama-3.1-70B/tree/main/original

27. sparrowaisolutions/aras-ember-v2 \- Hugging Face, https://huggingface.co/sparrowaisolutions/aras-ember-v2

28. README.md · mistralai/Mistral-Large-Instruct-2411 at main, https://huggingface.co/mistralai/Mistral-Large-Instruct-2411/blob/main/README.md

29. mistralai/Mistral-Large-Instruct-2407 \- Hugging Face, https://huggingface.co/mistralai/Mistral-Large-Instruct-2407

30. Large Enough | Mistral AI, https://mistral.ai/news/mistral-large-2407/

31. README.md \- NVIDIA-AI-Blueprints/rag \- GitHub, https://github.com/NVIDIA-AI-Blueprints/rag/blob/main/README.md

32. leafspark/Mistral-Large-218B-Instruct \- Hugging Face, https://huggingface.co/leafspark/Mistral-Large-218B-Instruct

33. How are you handling Gemma's license for commercial apps?, https://huggingface.co/google/gemma-7b/discussions/122

34. Qwen/Qwen2.5-Coder-32B-Instruct · VSCODE \+ Cline \+ Ollama \+, https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct/discussions/20

35. LoneStriker/gemma-2b-4.0bpw-h6-exl2 \- Hugging Face, https://huggingface.co/LoneStriker/gemma-2b-4.0bpw-h6-exl2

36. audreyt/Gemma-3-TAIDE-12b-Chat-2602-heretic-GGUF, https://huggingface.co/audreyt/Gemma-3-TAIDE-12b-Chat-2602-heretic-GGUF

37. SillyTilly/Mistral-Large-Instruct-2407 \- Hugging Face, https://huggingface.co/SillyTilly/Mistral-Large-Instruct-2407

38. mistralai/Mistral-Large-Instruct-2411 \- Hugging Face, https://huggingface.co/mistralai/Mistral-Large-Instruct-2411

39. RichardErkhov/beomi\_-\_gemma-ko-7b-8bits \- Hugging Face, https://huggingface.co/RichardErkhov/beomi\_-\_gemma-ko-7b-8bits