Unpacking Open Source Artificial Intelligence: Toward a Framework for Openness in Foundation Models

Motivations: Why pursue AI openness?  In Figure 1, a non-exhaustive list of potential benefits sourced from workshop participants highlights a variety of motivations for AI openness. AI openness is rarely pursued for its own sake; it is motivated by diverse and sometimes conflicting goals. Our framework helps make these goals explicit by showing how different motivations map onto different forms of openness across the AI stack. For instance, advancing research and innovation often depends on openness of data or training code; promoting competition and efficiency tends to emphasize access to model weights; and ensuring accountability may require openness in documentation, licensing, and safeguards. These motivations may overlap, but they do not always align. A strategy that maximizes reproducibility, for example, may differ from one that maximizes market competition or system safety. In the free/libre tradition, “openness” is inseparable from user freedoms, and from ensuring protection against malicious features.²⁰ The user’s essential freedoms are to run, copy, distribute, study, change, and improve the technology;⁸ in AI systems, licensing and governance should be assessed on whether they preserve or effectively claw back these freedoms across components.

By situating motivations within the framework, we can move beyond abstract claims that “openness is good” or polarized debates that cast it as either inherently dangerous or inherently beneficial. Instead, the framework enables more precise evaluation of which forms of openness serve which objectives, and where trade-offs or complementarities exist. This creates a clearer basis for policymakers, researchers, and developers to debate not only whether to open AI systems, but how and for what purposes.

Binary approaches.   The Open Source Initiative (OSI) launched a process in June 2023 to draft a definition of open source AI, culminating in the release of an “Open Source AI Definition” in late 2024.¹⁵ It best exemplifies the binary approach, with a clear set of criteria on what counts as “open” versus “closed,” and references to OSI-approved licenses and terms to meet these criteria. Below, and as concrete illustrations for what open can mean in practice across weights, code, data, checkpoints, and licensing, we cite projects that exemplify a fully open approach.

EleutherAI released a suite of open models with full training checkpoints and tools to reconstruct training dataloaders,² advocating for standard open source licenses to ensure clarity and interoperability.

The LLM360 initiative¹⁰ promotes full transparency across model training, checkpoints, and data. The project argues that partial releases hinder scientific progress and reproducibility.

The Allen Institute for AI built on initiatives like Pythia and BLOOM by releasing an initial set of 1B and 7B models with 500-plus checkpoints from intermediate training, full datasets, training code, evaluation code, training logs, and comprehensive documentation.²⁵ The initiative aims to foster a growing “science of LLMs” and influence public AI discourse beyond transparency and openness goals.

Beyond a single open/closed label for a whole release, some efforts apply a binary rule, component by component. The Linux Foundation’s Model Openness Framework (MOF)²³ is the clearest instance: It evaluates whether each component is released under appropriate open terms. The MOF classifies models based on openness and completeness across 15 components of the model development lifecycle. The framework distinguishes between openness (binary classification of whether a component is released under an appropriate open license) and completeness (gradient approach with three tiers of model completeness, based on which components are released under appropriate open licenses). The framework includes a required MOF.JSON file detailing licenses and components, with classes ranging from Open Model (Class III) to Open Science (Class I), encouraging transparency, reuse, and reproducibility.

Criteria scoring approaches.   The Centre for Language Studies at Radboud University developed a project²⁶ to assess the openness, transparency, and accountability of instruction-tuned language models. The research highlights risks of proprietary software and provides comparative analysis of open source alternatives with similar architectures and capabilities.

Stanford CRFM created the Foundation Model Transparency Index,⁴ introducing 100 fine-grained indicators that capture transparency across the lifecycle of FMs—from upstream inputs (data sources, labor, and compute) to the model itself (size, capabilities, and risks) and downstream uses (distribution channels, usage policies, and affected geographies). The study emphasizes that AI release strategies are nonbinary and classifies models with widely downloadable weights as open. The research found that open models tend to outperform closed ones in transparency metrics, attributing this partly to lack of transparency among closed developers about critical upstream components.

EleutherAI offered a contrasting perspective,⁷ cautioning that score-based transparency frameworks risk treating transparency as an end in itself rather than as a means to uphold ethical values such as accountability.

Gradient/spectrum approaches.   In “The Gradient of Generative AI Release: Methods and Considerations,”¹⁹ Solaiman introduces a template for understanding different levels of access to generative AI systems, from fully closed to fully open. The paper defines six release levels—fully closed, staged access, hosted access, API/cloud access, downloadable access, and fully open—framing them as points along a gradient. It highlights the trade-offs at each level, particularly the balance between risk mitigation and power concentration.

The Princeton Center for Information Technology Policy and Stanford Center for Research on Foundation Models hosted a 2023 workshop¹⁷ to discuss key benefits and risks of specific properties of open FMs. They proposed a risk assessment framework for analyzing their marginal risk (i.e., using closed source and preexisting technologies as a baseline). They identify that more research is needed to assess the marginal risks of open FMs.

The Digital Public Goods Alliance developed a gradient approach framework²⁷ that acknowledges that access to AI testing and training data is not the same as having access to source code; put another way, open sourcing data alone does not enable full model reproducibility. It recognizes varying degrees of openness across AI systems (training data, model, and code), without further detailing sub-components. The framework seeks to balance the benefits of AI openness, such as transparency and inclusivity, against potential risks of misuse or harm, and includes the concept of “aspirational openness,” defining various levels of openness for AI components to qualify as digital public goods, taking into account factors like ethical use and data rights issues.

Gradient approaches commonly ground marginal-risk analyses of openness; we review some key examples below.

In “Considerations for Governing Open Foundation Models,”³ Bommasani et al. from the Stanford Institute for Human-Centered Artificial Intelligence examine how release strategies of open FMs relate to governance risks and regulation consequences. A key takeaway from the brief is to invite practitioners to think in terms of marginal risk of open foundation models “relative to (a) closed models or (b) pre-existing technologies.” The paper also discusses some of the benefits of open FMs such as competition, accelerating innovation, and distributing power. The brief acknowledges that the release of FMs is a gradient across various dimensions, and encourages policymakers to explore downstream intervention points that would be more effective for mitigating AI risks.

In the paper “What Does It Mean to Open Source AI?”¹¹ Luccioni et al. analyze the risks and benefits of open FMs. Benefits include innovation, competition, the distribution of decision-making power, and transparency. The authors also present a risk-assessment framework for evaluating the marginal risk of open FMs, and survey the current evidence for the risks of open FMs, which, in many cases, the authors find lacking.

Summary.  While these existing frameworks have made valuable contributions to the emerging scholarship around defining openness in the context of AI, they also present key limitations that we are seeking to address. Binary approaches may oversimplify the complex, multi-dimensional nature of AI systems, and thus the different pathways that may lead to openness, while gradient approaches often lack specificity about what constitutes meaningful differences along the spectrum. Scoring approaches, though comprehensive, risk treating transparency as an end in itself rather than as a means to achieve broader goals such as accountability and safety. Additionally, many existing frameworks focus primarily on model-level considerations, potentially overlooking the broader system-level components that significantly impact user freedoms. To bridge these gaps, we make explicit which system-level components and cross-cutting attributes (documentation, licensing, safeguards) matter for specific goals, rather than treating openness as a single axis.

Building on these prior efforts, we propose a unified framework that distinguishes between the AI model stack and the broader AI system stack, while incorporating cross-cutting attributes such as documentation, safeguards, and licensing. Our approach aims to provide greater granularity and practical applicability by mapping different dimensions of openness to their corresponding benefits and use cases.

The full proceedings write-up includes three appendices that offer additional depth: (i) Benefits of Openness across the Foundation Model Stack, (ii) Key Areas of Debate, and (iii) Alignment with the Linux Foundation’s Model Openness Framework. These are available in the full version of the article.¹

AI model stack.  Reaching an agreement on a definition for AI openness has proven complicated.¹⁴ AI models are not just code; they are trained on massive datasets, deployed on intricate computing infrastructure, and accessed through diverse interfaces and modalities. To effectively depict an AI system stack, we initially focus on the AI model tech stack. Figure 2 presents the core components that are particularly relevant for considerations around openness of a general-purpose AI model (GPAIM).

At the model level, there are three main artifacts: datasets, code, and model weights, each of which also includes sub-components. It is important to note that not all sub-components are mandatory or applicable in every configuration (e.g., some models may have the reward model’s weights or preference dataset; others do not), and the taxonomy of sub-components may vary based on the specific model type. Given this variability, it is crucial to tailor the AI model stack to accommodate different modalities, such as input and output types. Figure 2 illustrates these various layers at the model level.

AI system stack.  It is important to distinguish between open models and fully open AI systems or products. Open AI systems often incorporate more than just the model, including interfaces, telemetry, safety layers, and orchestration tools. For example, an open chatbot might rely on external moderation systems, while a RAG application could add components like langChain or Redis for orchestration and caching. This structure differs from traditional software, where code, compilers, and licenses are clearly separated. In AI, components such as data, hardware, and algorithms jointly shape behavior, making openness harder to define. For instance, opinions diverge on whether model weights, code, or datasets count as the “source” for modification. (Despite these differences between building AI models and traditional software, some initiatives are trying to study to what extent FMs could be built as “open source software”—especially given the technical ability to efficiently update the weights of the models. This would allow contributors to be able to submit patches to fix potential identified vulnerabilities in the model; then maintainers would need to be able to merge the patches to quickly integrate updates into the model.)

Lastly, the infrastructure layer plays a key part, as many scholars have already underlined: The high costs⁶ associated with developing AI models could hinder¹⁹ widespread adoption, even using open approaches, due to the expensive hardware and infrastructure requirements, such as GPUs. While openness in AI provides organizational control for customization, adapting large models to specific domains poses challenges without substantial investments in GPUs, so this does not necessarily solve the challenges of concentrated access and influence in well-resourced labs.⁴ See Figure 3 for a visual representation of the tech stack required for a general-purpose AI system (GPAIS).

Common attributes across the AI system stack.   It is crucial to differentiate between the components of the tech stack, such as model weights, and their attributes, such as the license for model weights. For instance, in this article we consider many AI safety measures to be better understood as attributes of the system rather than features of the model. Consequently, we represent an AI system as comprising three cross-cutting sets of attributes—documentation, safeguards, and licensing—that may apply across the entire stack rather than being tied to any single component (see Figure 3 for attribute categories integrated into the system stack).

For example, safety guardrails can be integrated at the level of individual components, recognizing their diversity and the need to address different types of harms and risks that may arise across the stack. This approach allows for targeted mitigations that are best suited to each component’s specific role and vulnerabilities.¹³ Entrusting safety assessments solely to models is insufficient, especially regarding concerns of potential misuse, as models lack crucial contextual information necessary for making accurate safety assessments.

An openness in AI framework.  As a whole, the framework presents a tech stack described across its different dimensions: AI artifacts (e.g., model weights), to which correspond different attributes such as licensing (e.g., choice of model’s weights license) or documentation (e.g., model cards). Each of the dimensions is composed of categories and subcategories that can be released more or less openly. As illustrated in Figure 3, these components correspond to different benefits of openness at each layer of the stack. Further work is needed to understand what is required to open different parts of the stack, which components are essential for reproducibility or evaluation, and how openness needs may shift with future AI systems beyond today’s LLMs.

We hope a meaningful contribution of this framework can be its explicit distinction between the model stack and the broader system stack in the context of evaluating openness, combined with the mapping of cross-cutting attributes like documentation, licensing, and safeguards that apply across both levels. This work seeks to unify previously fragmented approaches into a coherent descriptive framework that can be systematically applied by policymakers evaluating regulatory approaches and practitioners making release decisions.