Every large language model on the market today was trained, in part, on code that someone else wrote for free. Every AI coding assistant that writes a pull request for you leans on parsers, compilers, and package managers maintained by volunteers who are not paid a cent for that work. Open source built the substrate that the AI industry now runs on top of — and the relationship between the two is getting stranger, not simpler, as the industry matures.
This isn't a story about whether open source is "good" or "threatened." It's a story about who captures value in a software supply chain that has quietly been rewired, and what that means for the people who maintain the code everyone depends on.
The old bargain, and why it's breaking
Open source software has always run on an implicit trade. Maintainers give away code; in return they get adoption, reputation, sometimes a job offer, occasionally a support contract. Companies get free infrastructure; in return they're expected to contribute back — fix bugs, sponsor development, upstream patches. It was never a perfectly balanced exchange, but it held together for two decades because the volume of extraction and the volume of goodwill roughly tracked each other.
Three things have broken that balance:
- Training data extraction at a scale no license anticipated. Public repositories were scraped to train foundation models, and the resulting systems now generate revenue in the billions without any mechanism that routes value back to the code's authors. MIT and Apache licenses permit reuse, including commercial reuse — but they were written for a world where "reuse" meant forking a library, not ingesting millions of repositories into a statistical model that reproduces stylistic and structural patterns from that code.
- A flood of AI-generated contributions hitting maintainer inboxes. Anyone can now generate a plausible-looking pull request in seconds. Reviewing it still takes a human minutes to hours. The cost of producing a contribution has collapsed; the cost of vetting one hasn't.
- A new definition of "open" competing for the same word. Model weights, model cards, and "open" AI systems now use the vocabulary open source built — but with licenses, reproducibility, and governance that often look nothing like the Open Source Definition maintained by the Open Source Initiative.
None of these are hypothetical concerns debated in a vacuum — they show up directly in maintainer workflows, corporate legal reviews, and the licensing choices companies make when they release a model.
What "open" means for a model versus a library
The word "open source" has a specific, decades-old meaning enforced by a set of criteria: you can run the software for any purpose, study how it works, modify it, and redistribute your modifications. When a company says its AI model is "open," it's rarely making the same commitment, and the differences matter enormously for anyone deciding whether to build on top of it.
| Dimension | Traditional open source software | Typical "open" AI model release |
|---|---|---|
| What you actually get | Full source code | Model weights, sometimes a technical report |
| Can you reproduce it from scratch | Yes, in principle | Usually no — training data and full training recipe are withheld |
| License restrictions on use | Rare, and standardized (MIT, Apache, GPL) | Common — usage caps, field-of-use restrictions, revocable terms |
| Can you see the training data | N/A (code is the artifact) | Almost never disclosed in full |
| Governance | Often community-run, forkable by design | Controlled by the releasing company |
| Commercial competitor clauses | Essentially none | Increasingly common ("you may not use this to build a competing product") |
This gap is why some researchers and organizations push back on calling weight releases "open source" at all, preferring terms like "open weights" or "source-available." It's not pedantry — it determines whether a startup can safely build a product on a model without the rug being pulled by a license change, and whether independent researchers can actually audit what the system is doing.
Why the distinction matters for builders
If you're evaluating a model to build on, the license text is doing more work than the marketing page. Two models can both be called "open" while one lets you fine-tune, redistribute, and deploy commercially without restriction, and the other bans you from using outputs to train a competing model, caps your monthly active users before a separate commercial license kicks in, or reserves the right to revoke access. Treat every "open" AI release as a contract to read, not a category to trust.
Who actually pays for maintenance
Open source has never been free to produce — it's just had its costs hidden, absorbed by volunteers, employers who let engineers contribute on company time, and a handful of foundations. The AI era adds new costs to that ledger without adding new funding mechanisms to match.
Consider the actual expense categories a maintainer of a widely used library now faces:
- Triage volume. AI coding tools make it trivial to generate issues and pull requests, including ones that look complete but contain subtle logic errors, hallucinated API usage, or code copied from incompatible license terms. Every one of these still requires a human to read it.
- Infrastructure load. AI agents and scrapers hit package registries, documentation sites, and git hosting at a rate that dwarfs human traffic, driving up bandwidth and compute costs for projects that often run on donated infrastructure.
- Security surface. A larger volume of contributions, some from accounts with no track record and machine-assisted plausibility, makes it harder to spot an intentionally malicious change — the exact pattern behind several real supply-chain compromises where a "helpful" contributor spent months building trust before slipping in a backdoor.
- Documentation as training fodder, not user support. Maintainers write docs for humans; those docs are now also training material and retrieval context for AI assistants, which changes what "good documentation" needs to do without changing who's expected to write it.
None of this is offset by AI companies routing meaningful revenue back to the projects they depend on. A small number of foundations, security funds, and corporate sponsorship programs exist, but they're not sized to the scale of extraction. The mismatch is structural: training runs are a capital expense measured in the billions; maintainer stipends are measured in the thousands, when they exist at all.
Who actually benefits
If maintainers are absorbing new costs without new revenue, it's worth being precise about where the value they create actually ends up. It doesn't vanish — it moves, and it concentrates in a few identifiable places.
- Foundation model companies get a training corpus of extraordinary breadth and quality — real code, written by real engineers to solve real problems, annotated implicitly by commit messages, issue threads, and documentation — at a fraction of what it would cost to commission that volume of labeled data from scratch.
- Cloud and infrastructure providers benefit twice over: once from hosting the training and inference workloads, and again from the increased consumption of compute that AI-assisted development drives, since more code shipped faster generally means more deployed infrastructure.
- Enterprises building on AI coding tools capture real productivity gains — faster prototyping, less boilerplate, quicker onboarding to unfamiliar codebases — largely without needing to trace or compensate the specific projects that made those gains possible.
- Individual developers benefit unevenly. A well-known maintainer with an existing platform can convert AI-era attention into sponsorships, speaking engagements, or a job; a maintainer of a small but critical dependency — the kind of project that quietly underpins half the ecosystem — usually sees none of that upside, only the added triage load.
- End users of AI products benefit from lower prices and faster iteration, indirectly subsidized by uncompensated inputs earlier in the chain, in much the same way that free content subsidized the early web before advertising and subscription models caught up.
The pattern is familiar from other digital industries: value generated by a distributed, uncompensated base gets aggregated by whoever sits closest to the paying customer. Search engines did it to publishers. Ride-hailing platforms did it to local taxi economies. Open source is now experiencing a version of the same dynamic, except the "product" being aggregated is code itself, and the intermediary is a model rather than a marketplace.
This doesn't mean the arrangement is illegitimate — aggregation often does create genuine new value, and plenty of maintainers are pragmatic about the trade. But it does mean that "open source made this possible" is doing a lot of unacknowledged work in AI industry narratives, and the maintainers behind that work are rarely in the room when the value gets priced.
Why this matters right now
The tension isn't abstract — it shows up in day-to-day decisions inside engineering organizations. Companies choosing a base model for a product have to weigh whether "open weights" gives them the durability guarantees they assumed open source gave them. Security teams have to decide how much scrutiny an AI-authored pull request needs relative to a human one. And maintainers — many of them unpaid — are making individual calls about whether to keep accepting external contributions at all, or to lock a project down to a small trusted circle, which quietly reduces the openness that made the project valuable in the first place.
This also plays out in how companies license their own AI releases. A model released under a restrictive "open" license can still get community goodwill and ecosystem effects similar to a truly open project, while reserving commercial control — a strategy that works precisely because most users don't read past the word "open." That gap between perception and terms is where a lot of near-term friction is concentrated: procurement teams assuming they have rights they don't, startups building roadmaps on a model whose terms can change, and researchers unable to independently verify claims about a system they're told is open.
Practical implications for teams building with AI and open source
If you're a business or engineering team operating in this space, a few concrete practices reduce risk:
- Read the actual license, not the label. "Open" on a landing page is marketing copy. The license file — or its absence — is the contract. Check for field-of-use restrictions, revocation clauses, and whether redistribution of fine-tuned derivatives is permitted.
- Treat AI-generated contributions to your own repos with the same scrutiny as unfamiliar external code, regardless of who submitted them. Provenance and intent are harder to verify when generation is cheap.
- Budget for the dependencies you rely on. If your product sits on top of open source infrastructure, sponsoring maintainers or contributing engineering time isn't charity — it's supply-chain risk management, the same category of spend as a security audit.
- Separate "can I use this" from "can I build a durable business on this." A permissive research license is fine for a prototype; a business built on a model with a revocable or usage-capped license needs a contingency plan.
- Watch for license changes on projects and models you depend on. Several widely used open source projects have shifted from permissive to source-available licenses in recent years in response to cloud providers monetizing their work without contributing back; AI model providers are following a similar pattern of tightening terms as commercial pressure increases.
Limitations and open questions
None of this is settled, and it's worth being honest about what's still unresolved rather than treating any single framework as the answer.
- The legal status of training on public code is still being litigated and legislated in different jurisdictions, with no converged global standard yet on what counts as fair use versus infringement when code (or any copyrighted work) is used as training data.
- There's no agreed mechanism for compensating original authors even where courts or legislatures land — unlike streaming royalties in music, there's no infrastructure to trace a model's output back to the specific repositories that shaped it.
- "Open" as a term for AI systems doesn't yet have the kind of enforceable, community-governed definition that the Open Source Definition provides for software, though standards bodies and advocacy groups are actively working on frameworks to fill that gap.
- Maintainer burnout is a slow-moving problem without a clean metric, which makes it easy for organizations to underinvest until a widely used project actually breaks or goes unmaintained.
What to watch next
A few signals will indicate which direction this settles in over the next few years:
| Signal | What it would tell you |
|---|---|
| New funding mechanisms tying AI company revenue to upstream maintainers | Whether the value-capture imbalance is being addressed structurally |
| Court and legislative rulings on training-data fair use | Whether current AI training practices remain legally viable as-is |
| Adoption of a rigorous, enforceable definition of "open" for models | Whether "open washing" becomes reputationally costly enough to stop |
| Maintainer tooling for triaging AI-generated contributions | Whether the ecosystem adapts operationally rather than just absorbing the load |
| High-profile projects moving from permissive to restrictive licenses | Whether more maintainers see licensing as their only lever against uncompensated extraction |
FAQ
Is open source AI actually open source?
Often not in the traditional sense. Many "open" AI releases share model weights but withhold training data, full training code, and impose usage restrictions that the Open Source Definition doesn't permit — which is why terms like "open weights" or "source-available" are increasingly used instead.
Do AI companies pay open source maintainers for training on their code?
Generally no. There's no standard mechanism that routes revenue from AI products back to the authors of the code, documentation, or forum content used to train them, and this remains one of the most contested aspects of the current AI training landscape.
Why are maintainers overwhelmed by AI-generated pull requests?
Because generating a plausible-looking contribution now takes seconds, while reviewing it for correctness, security, and license compatibility still takes a human real time — the cost of production and the cost of verification have decoupled.
What's the difference between open weights and open source?
Open source requires the ability to inspect, modify, and redistribute the actual source — in AI terms, that would mean full training code and data. Open weights typically means only the trained model parameters are released, often under a license with usage restrictions, without the data or process needed to reproduce the model independently.
Can a company legally train an AI model on public GitHub repositories?
This is actively being litigated and legislated, with different jurisdictions reaching different conclusions, and no settled global answer yet on whether training counts as fair use, a licensable act, or an infringement depending on the specific license and use case.
Should my company contribute money to open source projects it depends on?
If your product's reliability depends on a library or framework maintained by a small team or a single person, treating a sponsorship or contribution as risk management — not charity — is a reasonable read of the current environment, given how thin maintainer capacity has become.
How can I tell if an AI model's license is actually permissive?
Read the license file directly rather than trusting a website's description, and check specifically for field-of-use restrictions, user or revenue caps, revocability clauses, and whether you're allowed to redistribute fine-tuned derivatives commercially.
If your team is navigating build-vs-license decisions around open source and AI tooling, Woyce Technologies can help you work through the practical tradeoffs.