Copyright and open source AI: legal asymmetry blocking transparency
Copyright and open source AI: legal asymmetry blocking transparency
Reproduction of copyright-protected data for AI training is legal, but their distribution is not - this asymmetry blocks true open source AI.
Critical legal asymmetry: why true open source AI is impossible
We have a fundamental problem: copyright law allows me to train a model on protected data (fair use), but I cannot publish that data as a dataset. This is the difference between reproduction and distribution – and this asymmetry is killing true open source in AI.
When you train a model in your data center, you reproduce data locally. This is typically legal. But when you want to share a dataset publicly? You must meet the legal requirements of all jurisdictions from which that dataset can be downloaded[1]. In practice: impossible. Developers often assume data is in the public domain and publish it as open source, but in many jurisdictions the same data is protected by copyright[1].
The Open Source Initiative defines "true" open source AI as three components: training data, architecture code, and model parameters – all under a license guaranteeing four freedoms (use, study, modify, share)[2]. Without the complete dataset you only have "open access AI", not open source. This isn't semantics – it's a difference that in the context of the EU AI Act can cost millions in compliance.
The U.S. Copyright Office confirmed in a report from January 29, 2025, that output generated exclusively by AI is not subject to legal protection because it lacks "human authorship"[2]. Sounds like good news? Not necessarily. This means that code generated by LLMs cannot be licensed under open source (because licenses are based on copyright), unless a human significantly modifies it[2].
Consider the MongoDB case from 2025: they used AI (Cursor) to rewrite thousands of lines of code from an LGPL project and re-licensed it under MIT[2]. The original author demanded reversion, because copyleft requires preserving the license in derivative works. The question is: can AI legally "launder" a copyleft license? The debate continues, but the precedent is dangerous.
Consequences? You cannot replicate a model without the dataset. You cannot verify biases. You cannot audit what the model "saw" during training. We call this "open source", but it's a facade – you have weights and code, but you don't have the crucial element: data. It's like getting a recipe for a drug without the list of ingredients.
The current legal state structurally prevents meeting the definition of open source for AI. We can pretend, publishing "open weights models" and calling it transparency. But as long as reproduction is legal and distribution is not – true open source AI remains a legal fiction.
Definition of Open Source AI: three components and four freedoms
The AI industry has a nomenclature problem. What most companies call "open source AI" is in practice only open access – access to model weights without the fundamental freedoms that define true open source.
The Open Source Initiative is working on a standard that makes things clear: true open source AI requires three publicly available components[6]:
1. Training data – complete datasets, preparation methodologies, preprocessing techniques 2. Code – model architecture, PyTorch/TensorFlow implementation, training scripts 3. Model parameters – weights, coefficients, checkpoints
Without any of these elements you only have "open access AI" – a downloadable model, but without the ability to truly understand, modify, or reproduce it.
Four fundamental freedoms
OSI adapts classic open source freedoms to the AI world[6]:
- Use – deploy in any context, without restrictions
- Study – access to architecture, data, training processes
- Modify – fine-tuning, architecture changes, retraining
- Share – distribution of original and modified model
This isn't academic pedantry. The EU AI Act provides concrete exemptions for AI systems released under free and open source licenses[6]. If your model meets the definition, you avoid part of compliance requirements, which translates to savings of months of legal and engineering work.
The data problem: legal asymmetry
The biggest pain point: you can train a model on copyright-protected data (fair use), but you cannot publish it in an open dataset. The U.S. Copyright Office in its January 2025 report confirmed: reproduction for training is one thing, distribution is another[4].
Practical effect? Even if you want to do true open source, you legally cannot share training data. This blocks the fundamental freedom of "studying" – you cannot reproduce a model without access to the original dataset.
Classification matters
I've seen teams lose weeks on EU AI Act compliance analysis because someone marked a model as "open source" while only having public weights. Proper classification isn't marketing – it's a legal decision with real impact on roadmap and budget.
If you're planning a model release, first answer: can you share all three components? If not – call it "open weights" or "open access", not "open source". You'll save yourself problems with audits and regulatory.
Copyrightability of AI-generated code
Copyright law in the USA has one fundamental requirement: a work must "owe its origin to a human author"[2]. This seemingly simple criterion breaks down against the reality of generative AI. Code written exclusively by a language model does not meet this condition and is not subject to copyright protection[2]. Sounds like a technical detail? It's the foundation on which the entire construction of open source licenses rests.
The problem is deeper than it seems. Licenses like MIT, Apache, or GPL require the existence of copyright to work at all. You grant rights to something you own. If AI generates code that has no owner in the legal sense, you cannot license it[5]. You hit a legal void: the code exists, works, but its licensing status is undefined.
The U.S. Copyright Office in its January 2025 report closed one loophole that practitioners tried to exploit: prompt engineering does not make you an author[2]. You can write the best prompts in the world, but if the model controls the final output, you don't meet the human authorship requirement. This is a blow to the growing "AI-first development" ecosystem, where developers use Cursor, Copilot, or similar tools as their primary way of writing code.
There's another trap: short phrases. A significant portion of AI-generated code consists of snippets – a few lines, helper functions, standard implementations. In U.S. copyright law, sufficiently short phrases are not protected[3]. Even if a human modifies them, they may be too short to be considered a protected work. In practice, this means that a large part of an AI-generated codebase exists in a legal gray area.
MongoDB showed in 2025 how this works in practice. They took thousands of lines of code from an LGPL project, ran it through Cursor, and re-licensed it under MIT[8]. Copyleft requires that derivative works maintain the original license. But is AI-rewritten code a derivative work? MongoDB bet on "no". The original author bet on "yes" and demanded reversion[8]. The case shows that AI can be used to strip restrictive licenses – you rewrite the code, claim it's a new work, change the license.
Where is the human in all this? Modification and integration are the only certain anchor points for copyright[2]. If you take AI-generated code and edit it, add your own logic, refactor the architecture – you create a composite work in which your contributions are protected. Problem: where is the boundary? Changing a variable name is too little. Rewriting a function is too much (because then it's already your code). Somewhere in between is the point where "modification" becomes "authorship", but the law doesn't define this precisely.
In practice, developers apply a pragmatic approach: they treat AI-generated code as source material that always requires human review and modification. This isn't just a quality issue – it's a legal strategy. If you can prove that every line went through human hands, you have an argument for copyright. But this costs time and undermines AI's promise: automation.
The asymmetry is brutal. Training on copyright-protected data? Fair use, legal[2]. Publishing the same data in an open dataset? Copyright infringement[1]. You can use someone else's code to train a model, but you cannot share it in a form that would allow others to replicate your model. Open source AI requires data transparency, but copyright law prohibits that transparency. This isn't a bug – it's a feature of a legal system designed for a different era.
Case study: MongoDB vs. copyleft - can AI change a license?
In January 2025, MongoDB sparked a storm in the open source community by using the AI tool Cursor to rewrite thousands of lines of code from a project under the LGPL (copyleft) license and re-releasing it under the permissive MIT license[8]. The original author immediately demanded reversal of the changes, arguing that derivative works must preserve the original license terms, and copyright holders cannot change licenses without unanimous consent of all co-authors[8].
This case exposed a fundamental problem: can AI be a tool for "laundering" copyleft licenses? From a technical standpoint, code generated exclusively by AI is not subject to copyright protection and theoretically cannot be licensed under open source terms, which are based precisely on copyright[2]. However, in practice, MongoDB used AI to create functionally identical code that was formally a "new" work.
The legal conflict runs deeper than just the license change. Copyleft licenses (like LGPL or GPL) work on a "viral" basis – any derivative code must inherit the same terms. If AI can circumvent this principle by "rewriting" code, the entire philosophy of copyleft is called into question. The problem is further complicated by the fact that in open source projects with multiple contributors, changing the license requires the consent of all copyright holders – practically impossible in large projects[8].
The open source community is divided. Some developers see AI as a tool to circumvent "viral" licenses that, in their view, hinder innovation. Others warn that accepting such "AI laundering" will destroy the foundations of code sharing on which the open source ecosystem was built. This debate has direct implications for the future of copyleft projects – if AI can legally convert code between licenses, the value of licenses protecting software freedom drastically decreases[8].
The MongoDB case shows that current legal frameworks are not keeping pace with AI capabilities. While the U.S. Copyright Office clearly states that output entirely generated by AI is not protected[2], there are no precedents regarding situations where AI "rewrites" existing, protected code. This is a legal gray area in which both large corporations and individual developers operate – with potentially destructive consequences for the entire open source ecosystem.
Jurisdictional challenges: publishing datasets on a global network
When you publish a dataset online, you enter a jurisdictional legal trap that most ML teams simply don't understand. The difference between reproduction rights and distribution rights is not an academic detail – it's a fundamental problem blocking open source AI transparency.
Reproduction vs. distribution: the asymmetry that kills openness
You can legally reproduce copyright-protected content for model training in your jurisdiction (fair use, TDM exceptions). But when you publish that dataset online, you must comply with the law of all countries from which it can be accessed[1]. This is not the same legal process – reproduction is subject to the law of the country where it occurs, but online distribution must be legal everywhere[1].
Concrete example: you train a model on a collection of press articles in the EU (where the TDM exception works). The dataset weighs 50GB. You publish it on GitHub as "open source training data". Problem? Someone from the USA downloads it – there those articles may be protected differently. Someone from Japan – different regulations again. Suddenly you're liable for violations in 190+ jurisdictions.
Public domain doesn't exist globally
Developers massively assume that data is public domain and throw it into open datasets. In practice, the same material may be protected by copyright in some jurisdictions[1]. There is no "global public domain" – it's a local legal category. A dataset "safe" in Germany may generate lawsuits in the UK or Canada.
This creates an absurd situation: you have an open source model (code, parameters), but you cannot legally share the training data. OSI requires all three components (data, code, parameters) for true open source AI[6], but copyright law physically makes it impossible to meet this condition for most real applications.
EU AI Act: trial-and-error in practice
The EU AI Act offers exemptions for software under FOSS licenses – potentially saving millions in compliance[4]. But implementation is "trial-and-error"[1] – nobody knows exactly how to interpret these exemptions in the context of datasets. You publish, wait to see if someone sues, learn from mistakes. For startups, this is legal Russian roulette.
Solution: metadata-first approach
Practical workaround: publish metadata instead of complete datasets[1]. Data information (statistics, distributions, provenance, preprocessing steps) vs. copyright-protected raw data. You describe the dataset in a way that allows reproduction of the process, but you don't distribute protected materials.
Example: instead of 10M scraped images you publish:
- List of source URLs (not the images themselves)
- Scripts for downloading and preprocessing
- Checksums and validation logic
- Class distribution statistics
Someone can reproduce your dataset in their jurisdiction, taking legal responsibility themselves. This isn't ideal open source, but it's the maximum that copyright law currently allows. The alternative is closed models with "trust us" transparency – exactly what open source was supposed to solve.
U.S. Copyright Office position and fair use doctrine
The U.S. Copyright Office just closed one of the most intensive consultation processes in its history. In August 2023, a Notice of Inquiry on AI and copyright was launched – over 10,000 comments came in from companies, lawyers, scientists, and developers[2]. This shows the scale of uncertainty: everyone wants to know where they stand legally.
The result is two reports from 2024-2025. Part 1 (July 31, 2024) addressed digital replicas – how to protect images and voices from AI-generated deepfakes[7]. Part 2 (January 29, 2025) hit the core: copyrightability of GenAI outputs. The conclusion is brutal: entirely AI-generated outputs are not subject to copyright protection[2][7]. No human author – no copyright. Period.
This principle has fundamental consequences for open source. Code generated exclusively by AI cannot be licensed under GPL, MIT, or Apache, because these licenses are based on copyright law, which simply doesn't exist[2]. Short phrases from AI (common in code) are also not copyrightable[7]. And prompt engineering? The Copyright Office is unequivocal: the mere fact of writing a prompt does not make a human an author, because it's the model that controls the output, not the user[2].
The biggest hole in this system? Fair use for GenAI training remains unresolved. The Copyright Office has not issued clear guidelines on whether using millions of copyrighted works to train models falls under the fair use doctrine[2]. This means ongoing court battles – see: lawsuits against OpenAI, Stability AI, or GitHub Copilot. Each case tests the boundaries, but precedents emerge slowly.
Experts propose a new category: copyright for human-AI collaborative works[2]. If a developer uses AI as a tool (like an IDE with autocomplete), but actively modifies, selects, and integrates the output – this could be subject to protection. Problem: where is the boundary? How much "human input" is enough? The Copyright Office doesn't provide an answer.
Practical effect? MongoDB in 2025 used an AI agent (Cursor) to rewrite thousands of lines of code from an LGPL project, then re-licensed it under MIT[7]. The original author demanded reversion: copyleft requires preserving the license in derivative works. Can AI "launder" copyleft? Legally unclear. Technically – it just happened.
For CTOs and lead devs, this means decision paralysis. Publish a model with full transparency of training data? You risk copyright infringement lawsuits. Hide the data? You're not open source according to OSI, you lose benefits from the EU AI Act[2]. Lack of guidelines isn't an abstraction – it's direct cost: legal teams, compliance audits, release delays.
Practical conclusions and checklist for open source AI projects
Open source AI project maintainers must understand that publishing a model is something much more than throwing a file on GitHub. OSI in version 0.0.6 of its Open Source AI definition clearly states: without the complete triad of data + code + parameters you only have "open access", not open source[6]. This isn't semantics – it's the difference between qualifying for exemptions in the EU AI Act and full compliance regime.
Legal status verification checklist:
Start with training data. Don't assume something is public domain – in many jurisdictions it's copyright-protected content[1]. Key trap: reproduction for training is legal (fair use), but distribution of the same data in an open dataset is not[1][2]. Reproduction rights work locally, but online publication must comply with the law in all jurisdictions from which the dataset is accessible[1]. This is the asymmetry that blocks true transparency.
Code is the second critical point. The U.S. Copyright Office in its January 29, 2025 report confirmed: AI-generated code without human intervention is not subject to copyright protection[2]. You cannot therefore license it under MIT or GPL, because open source licenses are based on copyright. Prompt engineering is not enough – you must demonstrate human modification or arrangement of the code[2]. The MongoDB case from 2025 shows real risk: an AI agent copied thousands of lines from an LGPL project, rewrote it through Cursor, and released it under MIT[8]. Copyleft was violated because derivative work must preserve the original license.
Procedure for ensuring human authorship:
Document every AI-assisted change in the commit message. Mark files with AI-generated fragments and describe human intervention. It's enough for a senior dev to review, modify the structure, and approve – that's already human authorship. Short phrases generated by AI (typical in code) are not copyrightable, so they don't require special handling[3].
Voluntary disclosure strategy:
Publicly disclose which components are AI-generated. This builds trust in the community and protects against license washing accusations. In the README add an "AI Contribution Disclosure" section with a breakdown: which modules, what model, what level of human modification. For datasets, disclose sources and jurisdictions in which you verified distribution legality.
Jurisdictional risk management:
Don't publish datasets without legal review in key jurisdictions: EU, US, UK. Each has different interpretations of fair use and database rights. Consider geographic access restrictions (geo-blocking) for particularly sensitive datasets. This isn't ideal, but in practice the only path to compliance in a trial-and-error environment of new regulations[4].
Preparation for EU AI Act:
Exemptions for "free and open-source" AI can save months of compliance work[4]. But you must meet the OSI definition, "open weights" is not enough. Monitor final implementation guidelines – many are still in the consultation phase. Prepare compliance documentation now: data lineage, architecture decisions, training methodology.
For maintainers: three golden rules
First: transparency over convenience. Don't hide AI-generated elements, even if it complicates licensing. Second: human-in-the-loop as standard. Every AI output goes through code review with change documentation. Third: conservative licensing. If you have doubts about copyright status – don't publish as open source, use open access with an explicit disclaimer.
The industry is waiting for subsequent parts of the U.S. Copyright Office report (part 1 in July 2024 concerned digital replicas, part 2 in January 2025 copyrightability[2][7]). Over 10,000 comments in the 2023 Notice of Inquiry show the scale of uncertainty. Maintainers must operate in this legal limbo, balancing between transparency and risk.
References
- aera
- [PDF] The Future of "Open Source" in the Age of AI - Steptoe
- How open-source software shapes AI policy | Brookings
- [PDF] Copyright and Artificial Intelligence, Part 2 Copyrightability Report
- Open to open-source AI? Navigating AI model choice in public ...
- Open Source Artificial Intelligence Definition 1.0 - A "take it or leave it" approach for open source AI systems? | Kluwer Copyright Blog
- Developer Perspectives on Licensing and Copyright Issues Arising ...
- Mapping the Open-Source AI Debate: Cybersecurity Implications ...