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.
For engineering leaders, this is not abstract. Your product almost certainly depends on libraries maintained by a handful of overstretched people, and the models you build on may be "open" in name only. Below, we look at why the old open source bargain is breaking, what "open" really means for a model versus a library, who pays for maintenance, who benefits, and what teams building with AI should do about it.
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 tension explored further in how AI training data licensing actually works.
- 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" — a distinction with real financial consequences once you're the one footing the bill for self-hosting those weights. 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. For a fuller comparison of what open-weight and closed models each actually commit to, see our breakdown of open vs closed AI.
Open Source AI Use Cases
Despite the ambiguity around the word "open," open-weight models and open source AI tooling are doing real work inside many organisations. These are the most common patterns.
Self-hosting for data control
Organisations handling sensitive data, such as legal documents, internal code, or customer records, often can't send it to a third-party API. Running an open-weight model on their own infrastructure keeps data in-house while still using a capable model. The trade-off is operational: hosting, scaling, and patching become the team's job, and the licence still has to permit the intended use.
Fine-tuning for a specific domain
When a general model doesn't know a company's terminology or output format, fine-tuning open weights on internal examples can close the gap. Teams own the resulting derivative, subject to the licence's redistribution terms, and can run it wherever they choose rather than depending on a provider's fine-tuning service. The work shifts to curating good training examples and evaluating whether the tuned model actually beats the base model on the tasks that matter.
Research, evaluation, and auditing
Researchers and safety teams use openly released weights to study model behaviour, test for bias, and probe failure modes in ways a closed API doesn't allow. Even without training data, inspectable weights make independent evaluation possible, which is one of the strongest arguments for releasing them. Universities and smaller labs in particular depend on open weights, since they can't train frontier-scale models themselves.
On-device and edge deployment
Smaller open models can run on laptops, phones, or edge hardware, enabling offline features and low-latency responses without per-call API costs. Product teams use this for private assistants, field tools, and features that must work without a connection. Keeping inference on the device also means user data never leaves it, which simplifies privacy reviews.
Building on open AI frameworks
Much of the tooling around models, from training libraries and inference servers to vector databases and agent frameworks, is itself traditional open source. Teams assemble their AI stacks from these components, which makes the health of those projects, and the people maintaining them, a direct concern for anyone shipping AI products.
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.
Benefits of Open Source in the AI Era: Who Captures Them
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
Model developers 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, echoing the dynamics behind large-scale AI content licensing deals in other media.
Cloud and infrastructure providers
Hyperscalers and hosting companies gain 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
Companies adopting assistants 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
Here the gains are uneven. 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
People using AI-powered software get 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.
Common Mistakes Teams Make With Open Source and AI
Most of the risk in this area comes from assumptions carried over from the pre-AI open source world.
Reading "open" as a licence
A model described as open on its launch page may carry user caps, field-of-use limits, or a clause banning use of its outputs to train competing models. Teams that rely on the label rather than the licence file discover these terms during due diligence, a customer audit, or a fundraise, when changing models is most painful.
Merging AI-generated code on trust
A pull request that compiles, passes a few tests, and reads fluently can still contain hallucinated API calls, subtle logic errors, or code lifted from incompatibly licensed sources. Treating it as lower risk because it looks polished is the wrong instinct; plausible code is exactly what makes careful review necessary, in your own repos and in the projects you contribute to.
Treating critical dependencies as free
Products often rest on libraries maintained by one or two unpaid people. Assuming those projects will keep shipping fixes indefinitely is a supply-chain risk that rarely appears in planning documents until a maintainer steps away or a vulnerability goes unpatched. By then the options are an emergency fork, a rushed migration, or hoping someone else fixes it.
Building a business on a revocable model licence
A permissive research licence is fine for a prototype. Scaling a commercial product on a model whose terms can be revoked or capped, without a fallback model or migration plan, puts the roadmap in someone else's hands. Investors and enterprise customers increasingly ask about this during due diligence.
Ignoring licence changes after adoption
Projects and model providers do change terms, and some have moved from permissive to source-available licences. Teams that check licences only at adoption time can end up running versions under terms they never reviewed, simply by upgrading.
Open Source and AI Best Practices for Engineering Teams
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.
- Map your critical dependencies. Keep an inventory of the libraries and models your product cannot run without, along with their licenses, number of active maintainers, and last release date. Single-maintainer projects and stale releases are the ones to fund, fork-proof, or replace before they become an incident.
- Set a policy for AI-assisted contributions you send upstream. If your engineers use coding assistants to contribute to external projects, require them to test, understand, and disclose AI use as the project asks. Sending maintainers unreviewed generated patches adds to the very load that is pushing projects to close their doors.
- Record model provenance in your stack. For each model in production, note its version, license terms at the time you adopted it, and where the weights came from, so a later license change or audit request can be answered quickly.
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 — an area where even the U.S. Copyright Office has only begun issuing formal guidance.
- 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 |
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.
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. The Open Source Initiative has published a separate definition for open source AI to address this gap, and many popular models don't meet it.
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 AI training today. Some AI companies fund foundations, offer grants or sponsor specific projects, but that support is voluntary and small relative to the value captured.
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. Many projects are responding with contribution policies that require disclosure of AI use, stricter templates, or closing low-effort pull requests without detailed review.
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. Companies training their own models should get legal advice, document the sources and licenses of their training data, and respect opt-out signals where they exist.
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. Start by listing your most critical dependencies and checking how many active maintainers each one has.
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. Also check whether training data and code are released or only the weights, since "open" labels often mean open weights under usage restrictions rather than open source in the traditional sense. When the terms are unclear and the model will sit inside a commercial product, get legal advice before you build on it.
Conclusion
Open source built the foundation the AI industry runs on: the code models were trained on, the frameworks they run in, and the tooling around them. The old bargain, free code in exchange for adoption, contributions and goodwill, is under strain because AI companies capture large value from that work while maintainers absorb more load, including a wave of AI-generated pull requests that are cheap to produce and expensive to review.
The word "open" has also stretched. A library under an OSI-approved license and a model released with weights but no data, plus usage caps, are very different things, and teams need to read licenses directly rather than trust labels.
Legal questions around training on public code remain unsettled across jurisdictions, and no funding model has yet emerged that reliably routes AI revenue back to maintainers. Expect both to keep shifting.
A practical step for any engineering team is to inventory your critical open source dependencies and AI model licenses, flag single-maintainer projects and restrictive terms, and budget for sponsorship as risk management. If you want help evaluating build-versus-license decisions for your AI stack, talk to our tech consulting team.