Open-source AI

Open-source AI refers to artificial intelligence systems whose recipients have broad rights to use, study, modify, and share the system, together with access to the materials needed to exercise those rights. The phrase is contested because a machine-learning system is not a single source-code package. It may include data, data-processing code, training code, a model architecture, learned parameters, inference code, evaluation materials, and documentation, each under different access conditions and legal terms ^[1][2][6].

A release that makes trained parameters downloadable is more precisely described as open weights when the training data, training code, or required rights remain unavailable. Open weights can support local inference and fine-tuning, but access to weights alone does not establish that a system is open source, reproducible, transparent, safe, or lawful to use for every purpose ^[6][7][9].

The Open Source Initiative (OSI) published the Open Source AI Definition (OSAID) version 1.0 on 28 October 2024. At the research cutoff of 28 July 2026, version 1.0 remained OSI's stable published definition. It requires the freedoms to use, study, modify, and share, plus access to data information, complete training and running code, and model parameters under qualifying terms ^[2][3][27]. OSAID is an influential standard-setting definition, not the only descriptive framework and not a substitute for the legal rules of a particular jurisdiction.

Meaning and scope

Open-source software has a comparatively settled reference point. The Open Source Definition requires more than visible code: it addresses redistribution, source code in the preferred form for modification, derived works, non-discrimination, and technology-neutral licensing ^[1]. Machine learning complicates that model because important behavior is learned from data rather than written entirely as human-readable instructions.

The word "open" can therefore describe several different properties:

Scroll sideways for more →

These properties are related but not interchangeable. A repository can contain open-source inference code while serving a closed model. A model can expose weights under restrictive terms. A release can provide permissively licensed code and weights while omitting the data mixture or training recipe. Conversely, a research project may disclose extensive scientific detail while limiting commercial redistribution. Describing the individual layers avoids treating a marketing label as a technical or legal conclusion ^[6][7].

The article concerns both conventional machine-learning systems and foundation models, but the applicable "preferred form for modification" can vary with the kind of system. OSI's own checklist notes that it was developed around generative AI and is not yet an operating manual for every machine-learning technique ^[5].

Open Source AI Definition

Four freedoms

OSAID 1.0 defines Open Source AI by four freedoms that apply to a complete system and to its discrete elements:

1. Use the system for any purpose without asking permission.
2. Study how the system works and inspect its components.
3. Modify the system for any purpose, including changing its output.
4. Share the system, with or without modifications, for any purpose ^[2].

Access alone is insufficient. The release must also provide the preferred form in which a recipient can make modifications. This continues the principle in the software Open Source Definition that obfuscated or intermediate forms are not a substitute for source code intended for modification ^[1].

OSAID does not include restrictions against particular fields of use. Under the Open Source Definition, a license that prohibits commercial, military, surveillance, or other fields of endeavor is not an open-source license even if the restriction is intended to prevent harm ^[1]. Such a release may still be source-available, open-access, or responsibly licensed, but the restriction changes its classification under OSI's criteria.

Required materials

For a machine-learning system, OSAID identifies three required groups of material ^[2]:

Scroll sideways for more →

Code must be under OSI-approved licenses. Data information and parameters must be under OSI-approved terms. OSAID uses the broader word "terms" for parameters because the copyright and other legal status of model weights is not fully settled across jurisdictions. The definition does not prescribe one legal mechanism for making parameters free ^[2].

The related OSI checklist separates default-required and optional components. It treats preprocessing code, training and testing code, inference code, supporting tools, architecture, and parameters as required. Evaluation data, evaluation code, model cards, sample outputs, and some other artifacts are listed as optional in that checklist, even though they can be important for independent evaluation ^[5]. The checklist also warns that judgment is needed when a release supplies data information instead of the dataset itself.

Training data compromise

OSAID 1.0 does not require every training datum to be redistributed. It requires open training data to be shared and requires detailed information about public, obtainable, and unshareable data. OSI justified this approach by pointing to privacy, copyright, medical confidentiality, Indigenous knowledge, and jurisdiction-specific constraints that can make redistribution unlawful or inappropriate ^[4].

That choice remains controversial. Full data access can be important for auditing provenance, measuring representation, reproducing filtering, and investigating memorization or bias. A description may be incomplete, links can disappear, third-party data can be expensive, and an unshareable corpus may be impossible for outsiders to reconstruct exactly. OSAID instead sets a threshold of information sufficient for a skilled person to build a substantially equivalent system. OSI's FAQ explicitly says that this requirement enables rather than guarantees full reproducibility ^[4].

The distinction matters when evaluating claims. "Training data documented" should not be rewritten as "training data released." "Substantially equivalent" is not necessarily bit-for-bit identical, behaviorally identical, or equally costly to produce. An evaluator should record which datasets are actually downloadable, which are merely identified, and which are described only in aggregate.

Version history

OSI's public process moved through numbered drafts during 2023 and 2024. Draft 0.0.9 and a release candidate refined the treatment of data information, code, and weights before the OSI board approved version 1.0. The stable release was announced at the All Things Open conference in Raleigh, North Carolina, on 28 October 2024 ^[3].

The stable text was presented as a starting point rather than a claim that all technical and legal questions had been resolved. OSI continued publishing explanatory material and evaluation guidance. Any future revision should be identified by version and date, because a later checklist or interpretation does not silently alter the text of version 1.0.

Other frameworks and uses of the word open

OSAID supplies a binary threshold for the OSI label, while research literature often treats openness as multidimensional. These approaches answer different questions rather than necessarily contradicting one another.

The Model Openness Framework (MOF) classifies releases in three tiers according to the openness and completeness of code, data, model, and documentation components. Its purpose is to help producers improve releases and help users determine which artifacts are available under appropriate licenses ^[8]. It can show that one release is more complete than another even when neither crosses a separate binary definition.

The Columbia Convening framework describes openness across an AI stack rather than reducing it to a single artifact. It asks which system and model components are accessible, to whom, under what conditions, and for what objectives ^[7]. This is useful for staged access, researcher-only access, public weights, hosted interfaces, and other arrangements that do not fit a simple open-or-closed pair.

A 2024 FAccT study evaluated more than 45 text and text-to-image systems across 14 dimensions. It found that many systems marketed as open source were open-weight at most, particularly because providers withheld training and fine-tuning data or documentation ^[6]. The study uses "open-washing" for claims that overstate actual openness.

A Nature perspective similarly distinguishes transparency, reusability, and extensibility. It argues that opening model artifacts can enable some oversight and experimentation but does not by itself remove concentration in compute, data, labor, cloud infrastructure, or distribution ^[9]. Thus "open source" should not be used as a shorthand for decentralized ownership, low resource requirements, ethical governance, or competitive equality.

Open source and open weight

The following labels are useful when the exact release bundle is known:

Scroll sideways for more →

"Open model" is ambiguous unless the author defines it. Some government reports deliberately use operational terms instead. The US National Telecommunications and Information Administration (NTIA), for example, analyzed "dual-use foundation models with widely available model weights." Its report called those systems open foundation models for convenience while expressly recognizing a spectrum of openness across weights, code, data, documentation, licenses, and access channels ^[21].

OSI's 2024 review illustrates why artifact-level descriptions matter. It reported that the reviewed versions of OLMo, Pythia, CrystalCoder, and T5 met its requirements; Llama 2, Phi-2, Mixtral, and Grok did not; and BLOOM, StarCoder2, and Falcon would need license changes ^[16]. This was an assessment of named releases at that time, not a permanent ranking or an exhaustive certification list. Model families, licenses, and release bundles can change between versions.

Historical development

Open-source AI predates the recent debate about model weights. Early work often opened software libraries, reference implementations, datasets, and research code rather than complete trained systems.

Google released TensorFlow under the Apache License 2.0 in November 2015. The release made a general machine-learning framework and related tools available for external research and production use ^[10]. PyTorch was publicly released in January 2017 as an open-source deep-learning framework. These projects opened important software infrastructure, but use of an open-source framework does not make every model trained with it open source ^[11].

The release of pretrained parameters expanded the practical meaning of openness. Google's BERT paper and associated code and checkpoints in 2018 allowed other researchers to adapt a pretrained language representation rather than repeat the entire pretraining process ^[12]. In 2019, OpenAI used a staged release for GPT-2, initially withholding the largest checkpoint and then releasing its 1.5-billion-parameter version with code and weights in November. The episode became an early case study in managing the claimed benefits and misuse risks of public model artifacts ^[13].

Large collaborative projects then made more of the development process visible. BigScience presented BLOOM, a 176-billion-parameter multilingual model, as an open-access project built by hundreds of researchers. It released models and code under a Responsible AI License rather than an OSI-approved unrestricted-use license ^[14]. That distinction is why BLOOM can be important to open research while still requiring qualification under the OSAID test.

The Allen Institute for AI's OLMo project, first released in 2024, included training data, training and evaluation code, parameters, checkpoints, and logs. Its paper framed the project as infrastructure for studying language-model development rather than only consuming a final checkpoint ^[15]. OLMo became a prominent example in OSI's version 1.0 evaluation ^[16].

These milestones show a change in the unit being shared: first software frameworks, then pretrained checkpoints, and later fuller model-development workflows. They do not establish a one-way progression toward complete openness. Projects can open some layers and close others, and later versions of a family may use different data disclosures or terms.

Licensing

Separate artifacts, separate rights

An AI release may need a licensing map rather than a single license label. Source code, documentation, datasets, database structure, model parameters, evaluation data, trademarks, and hosted services can implicate different rights. A licensor can grant only rights it controls, and an open license does not erase third-party copyright, privacy, contract, patent, trademark, publicity, or database-right obligations.

Common software licenses such as Apache-2.0, MIT, and GPL were drafted for software. Applying one to a repository can clearly license the included code, but it does not prove that every training datum was lawfully acquired or that the same license is legally effective for every model artifact. Creative Commons advises against applying its licenses to software because they do not contain software-specific source-code and patent provisions, while noting that Creative Commons tools can be used for documentation and databases where relevant rights exist ^[18].

A usable release should state which files each license covers. It should also identify third-party components, attribution notices, patent terms where applicable, data-use constraints, and whether outputs have separate terms. A single badge or repository-level metadata field is not a substitute for reading the governing documents.

Permissive and copyleft terms

Permissive open-source licenses generally allow modification and redistribution with limited conditions such as preserving notices. Copyleft licenses additionally require some redistributed derivatives to remain under the same or compatible terms. Both can satisfy the Open Source Definition when their exact terms meet its criteria ^[1].

OSAID permits conditions that require modified versions to be released under the same terms as the original. It does not permit restrictions that deny the four freedoms to particular users or fields of endeavor ^[2]. Therefore, an acceptable-use policy incorporated as a condition of the artifact license can change an OSI classification even if the prohibited uses are widely considered harmful.

Responsible AI licenses

Responsible AI Licenses (RAIL) add behavioral-use restrictions intended to prevent specified harmful applications and generally require those restrictions to follow downstream derivatives ^[17]. They can facilitate access and research while preserving a licensor's chosen controls. However, restrictions on fields of use conflict with the OSI rule that an open-source license allow use for any purpose ^[1].

"Open RAIL" should not be interpreted as equivalent to OSI-approved open source. The RAIL project's use of "open" describes royalty-free access and redistribution subject to continuing use restrictions ^[17]. An article or model card should name the exact license rather than infer permissions from the family name.

Warranty and compliance

Open availability normally comes without a warranty that a model is accurate, secure, non-infringing, unbiased, or fit for a particular purpose. The right to redistribute an artifact also does not transfer responsibility for a downstream deployment. Operators still need to evaluate applicable sector rules, data-protection duties, consumer-protection law, product-safety requirements, and the terms of all dependencies.

The copyright status of learned parameters and the reach of contract terms can differ between jurisdictions. OSAID acknowledges this uncertainty by allowing OSI-approved "terms" for parameters rather than insisting that one copyright license always supplies the legal mechanism ^[2]. Encyclopedic descriptions should therefore avoid categorical statements that all weights are copyrightable, uncopyrightable, or controlled identically worldwide.

Reproducibility, transparency, and documentation

Reproducibility has several levels. A recipient might be able to run a checkpoint, fine-tune it, repeat an evaluation, reconstruct a dataset, repeat pretraining within statistical tolerance, or reproduce an exact sequence of bits. These tasks require different artifacts and resources.

Weights plus inference code can be sufficient for local execution but not for tracing why the system learned a behavior. Training code without the data mixture cannot reproduce pretraining. Data without preprocessing rules can produce a materially different corpus. Even a complete recipe may be difficult to repeat because of unavailable hardware, nondeterministic operations, undocumented failures, or the cost of compute.

Model cards were proposed to document intended uses, performance characteristics, evaluation procedures, limitations, and results across relevant groups ^[19]. Datasheets for datasets document motivation, composition, collection, processing, recommended uses, maintenance, and known concerns ^[20]. These practices complement licensing: a license grants permissions, while documentation helps a recipient understand what was built and how it was evaluated.

Useful technical records include:

• exact artifact versions, checksums, and dependency locks;
• architecture and tokenizer definitions;
• dataset provenance, licenses, exclusions, and filtering;
• training stages, hyperparameters, random seeds, compute, and checkpoints;
• fine-tuning and alignment data;
• evaluation code, prompts, datasets, and known contamination;
• intended uses, excluded uses, limitations, and failure modes;
• security reporting, maintenance, and deprecation procedures.

Publication of these records does not prove their accuracy. Independent verification can compare hashes, rebuild code, reproduce evaluations, inspect samples, and test claims against the specified version. A live model repository should be versioned because replacing weights or a model card can otherwise change the object being evaluated.

Benefits and limitations

Open artifacts can let researchers inspect implementation choices, test hypotheses, adapt a system to a domain, run it without sending prompts to a remote provider, and preserve access to a particular version. Organizations may deploy models on infrastructure they control, subject to hardware, licensing, and legal constraints. Public checkpoints can also support independent safety research and comparison of mitigation techniques ^[21].

These are capabilities, not guaranteed outcomes. Local deployment can improve control over data flows, but it does not by itself create secure storage, access controls, audit logs, or legal compliance. Fine-tuning can improve domain performance, but it can also introduce bias, regressions, memorization, or safety failures. Public source can permit inspection, but reviewers still need expertise, time, compute, and representative tests.

Economic claims require similar care. Open weights can lower the cost of acquiring a pretrained model and reduce dependence on one API provider. They do not remove inference costs, accelerator scarcity, electricity use, integration work, data acquisition, or the advantage held by organizations with large-scale infrastructure. NTIA concluded in 2024 that evidence was insufficient either to justify restrictions on then-available widely available weights or to rule out future restrictions, and recommended ongoing evidence collection and risk monitoring ^[21]. A Nature analysis likewise argued that artifact openness alone does not dissolve concentration across the AI supply chain ^[9].

For maintainers, openness also creates operational obligations. Public releases benefit from reproducible builds, signed or hashed artifacts, vulnerability reporting, versioned evaluation reports, dependency review, and clear governance. Without maintenance, a downloadable model can remain available while its software dependencies become vulnerable or incompatible.

Safety and security

Open-source status is not a safety certification. OSAID intentionally defines freedoms and preferred forms for modification rather than prescribing ethical behavior or a risk-management process ^[4]. Safety must be evaluated for the model, release method, deployment context, and downstream use.

Changes to safeguards

Parameter access can allow recipients to alter fine-tuning, system prompts, filters, refusal behavior, and inference code. This is useful for research and customization, but it also means safeguards packaged with one deployment may not survive redistribution.

Controlled studies support a narrow version of this concern. An ICLR 2024 paper found that fine-tuning aligned language models with a small set of adversarial examples could substantially degrade refusal behavior; it also observed smaller safety degradation from some benign fine-tuning datasets ^[23]. A separate study used low-rank adaptation to reduce refusal rates in tested Llama 2-Chat and Mixtral variants while retaining performance on selected general benchmarks ^[24]. These results concern tested models, data, and metrics. They do not show that every open model is unsafe or that closed APIs cannot be customized or bypassed.

Release risks and benefits

NTIA organized the marginal risks of widely available weights around misuse, oversight, accountability, national security, privacy, equity, and civil rights. It also identified potential benefits for research participation, competition, customization, confidentiality, and independent assessment ^[21]. The report emphasized comparison with existing closed models and other technologies rather than attributing every AI risk uniquely to openness.

Risk can vary by capability and release layer. Publishing evaluation code or a model card generally has a different risk profile from publishing a highly capable checkpoint. Structured or staged access can give selected researchers time to test a system before broader distribution, as the GPT-2 release illustrated ^[13]. Once weights are widely mirrored, later withdrawal cannot reliably remove all copies.

NIST's Generative AI Profile recommends managing risks throughout the lifecycle, including governance, content provenance, pre-deployment testing, incident disclosure, information security, and monitoring ^[22]. These practices can apply to both open and closed systems. For public releases, useful controls include:

• pre-release capability and misuse evaluations;
• documentation of test scope, limitations, and unresolved risks;
• secure build and artifact-signing processes;
• checksums and provenance for weights and datasets;
• a channel for vulnerability and incident reports;
• versioned fixes and notices rather than silent replacement;
• downstream guidance that distinguishes technical advice from license conditions;
• evaluation of whether a staged, gated, or full release is appropriate for the specific capability.

No single release strategy is always safest. Closed access can support rate limits, monitoring, rapid server-side updates, and account-level controls, but it reduces independent access to internals and concentrates oversight in the provider. Public artifacts expand inspection and adaptation, but some deployment controls can be removed. The relevant comparison is empirical and capability-specific.

European Union AI Act

The European Union's AI Act uses its own legal language and should not be assumed to incorporate OSAID. Regulation (EU) 2024/1689 distinguishes AI systems from general-purpose AI models and creates several open-source provisions ^[25].

Article 2(12) states that the Regulation does not apply to AI systems released under free and open-source licenses unless they are placed on the market or put into service as high-risk systems, systems involving prohibited practices under Article 5, or systems subject to Article 50 transparency duties. This is a scope rule for AI systems, not a blanket exemption from all Union law and not the specific rule for providers of general-purpose AI models ^[25].

For general-purpose AI models, Article 53(1) requires technical documentation for authorities, information for downstream system providers, a policy for compliance with Union copyright law, and a public summary of training content. Article 53(2) exempts qualifying free and open-source models from only the first two duties, points (a) and (b), when the license allows access, use, modification, and distribution and when parameters including weights, architecture information, and usage information are public. The exception does not apply to general-purpose AI models with systemic risk ^[25].

The copyright policy and training-content summary in Article 53(1)(c) and (d) therefore remain applicable to qualifying open-source general-purpose models. Article 54(6) provides a related exception from appointing an EU authorized representative, again excluding systemic-risk models. Providers of systemic-risk models remain subject to model evaluation, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity duties under Article 55 ^[25].

Recitals 102 to 104 explain the Act's concept of a free and open-source license. They refer to rights to run, copy, distribute, study, change, and improve, and treat public weights, architecture, and usage information as relevant to transparency. Recital 103 also limits the benefit of exceptions where components are monetized, while clarifying that availability through an open repository is not by itself monetization ^[25].

The European Commission's 2025 guidelines interpret the general-purpose-model exemptions as applying when the model is released under a genuinely free and open-source license, the required information is public, and the model is not systemic-risk. The Commission also states that its guidelines are not legally binding and that authoritative interpretation belongs to the Court of Justice of the European Union ^[26].

The Act's test and OSAID overlap but are not identical. Article 53(2) expressly lists weights, architecture, and usage information, while OSAID additionally specifies complete training and running code and detailed data information as part of the preferred form for modification. A release may therefore need separate assessments for OSAID classification and for a claimed statutory exception.

Evaluating a release

A defensible assessment identifies a specific version and records evidence for each layer:

1. Identity: Record the developer, model name, version, release date, hashes, and upstream dependencies.
2. Access: Determine whether access is public, gated, staged, research-only, API-only, or limited to selected artifacts.
3. Parameters: Confirm which checkpoints, adapters, optimizer states, and configuration files are available.
4. Code: Check inference, preprocessing, training, validation, evaluation, and dependency code rather than only a demonstration script.
5. Data: Separate downloadable data from public links, purchasable sources, aggregate descriptions, and unshareable data.
6. Documentation: Review model cards, data documentation, training reports, evaluation methods, limitations, and change history.
7. Legal terms: Map each artifact to its exact license or terms and note use, redistribution, derivative, attribution, patent, and field-of-use conditions.
8. Reproducibility: State what was actually rerun or rebuilt, on which hardware and software, and with what tolerance.
9. Safety and security: Examine release evaluations, artifact integrity, reporting channels, known bypasses, and update practices.
10. Definition: Name the standard being applied, such as OSAID 1.0 or a MOF tier, rather than declaring a release simply "open."

The conclusion should match the evidence. If only weights and inference code are confirmed, "open-weight model" is the accurate description. If the code is under an open-source license but the model is hosted remotely, "open-source software using a hosted model" may be accurate. OSAID-conformant should be reserved for a version-specific assessment of the required freedoms, data information, code, parameters, and legal terms.

A version-scoped example of applying these distinctions to downloadable checkpoints is the DeepSeek vs Llama vs Qwen comparison, which separates weight access, license, architecture, context claims, and evaluation conditions.

See also

• Open weights
• Open-Weight LLM License Comparison
• Foundation Models
• Large language model
• Model card
• Fine-tuning
• AI safety
• Responsible AI

References

1. ^Open Source Initiative. "The Open Source Definition." Version 1.9. opensource.org/osd
2. ^Open Source Initiative. "The Open Source AI Definition - 1.0." 2024. opensource.org/...open-source-ai-definition
3. ^Open Source Initiative. "The Open Source Initiative Announces the Release of the Industry's First Open Source AI Definition." 28 October 2024. opensource.org/...-first-open-source-ai-definition
4. ^Open Source Initiative. "OSAID FAQs." opensource.org/...faq
5. ^Open Source Initiative. "Checklist to evaluate machine learning systems." opensource.org/...checklist
6. ^Andreas Liesenfeld and Mark Dingemanse. "Rethinking open source generative AI: open-washing and the EU AI Act." Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency, 2024. pure.mpg.de/...item_3588217_3
7. ^Adrien Basdevant et al. "Towards a Framework for Openness in Foundation Models: Proceedings from the Columbia Convening on Openness in Artificial Intelligence." 2024. arxiv.org/...2405.15802
8. ^Matt White et al. "The Model Openness Framework: Promoting Completeness and Openness for Reproducibility, Transparency, and Usability in Artificial Intelligence." 2024. arxiv.org/...2403.13784
9. ^David Gray Widder, Meredith Whittaker, and Sarah Myers West. "Why 'open' AI systems are actually closed, and why this matters." Nature 635, 827-833, 2024. nature.com/...s41586-024-08141-1
10. ^Jeff Dean and Rajat Monga. "TensorFlow - Google's latest machine learning system, open sourced for everyone." Google Research, 9 November 2015. research.google/...ystem-open-sourced-for-everyone
11. ^PyTorch Team. "PyTorch, a year in." 19 January 2018. pytorch.org/...a-year-in
12. ^Jacob Devlin et al. "BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding." 2018. arxiv.org/...1810.04805
13. ^OpenAI. "GPT-2: 1.5B release." 5 November 2019. openai.com/...gpt-2-1-5b-release
14. ^BigScience Workshop et al. "BLOOM: A 176B-Parameter Open-Access Multilingual Language Model." 2022. arxiv.org/...2211.05100
15. ^Dirk Groeneveld et al. "OLMo: Accelerating the Science of Language Models." 2024. arxiv.org/...2402.00838
16. ^Open Source Initiative. "2024 end-of-year review: Open Source AI Definition v1.0." 17 December 2024. opensource.org/...w-open-source-ai-definition-v1-0
17. ^Responsible AI Licenses. "Responsible AI Licenses." licenses.ai
18. ^Creative Commons. "Frequently Asked Questions." creativecommons.org/faq
19. ^Margaret Mitchell et al. "Model Cards for Model Reporting." Proceedings of the Conference on Fairness, Accountability, and Transparency, 2019. arxiv.org/...1810.03993
20. ^Timnit Gebru et al. "Datasheets for Datasets." Communications of the ACM 64(12), 86-92, 2021. arxiv.org/...1803.09010
21. ^National Telecommunications and Information Administration. "Dual-Use Foundation Models with Widely Available Model Weights." July 2024. ntia.gov/...ntia-ai-open-model-report.pdf
22. ^National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." NIST AI 600-1, July 2024. nist.gov/...ork-generative-artificial-intelligence
23. ^Xiangyu Qi et al. "Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!" International Conference on Learning Representations, 2024. proceedings.iclr.cc/...8eedf35-Abstract-Conference
24. ^Simon Lermen, Charlie Rogers-Smith, and Jeffrey Ladish. "LoRA Fine-tuning Efficiently Undoes Safety Training in Llama 2-Chat 70B." 2023. arxiv.org/...2310.20624
25. ^European Parliament and Council of the European Union. "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence." Official Journal of the European Union, 12 July 2024. eur-lex.europa.eu/...eng
26. ^European Commission. "Guidelines on obligations for General-Purpose AI providers." Last updated 11 November 2025. digital-strategy.ec.europa.eu/...pose-ai-providers
27. ^Open Source Initiative. "Open Source AI Fellowship Announced at UN Open Source Week." 23 June 2026. opensource.org/...announced-at-un-open-source-week