For years, open-source software has powered an enormous share of the technology industry. Companies can build products on top of libraries maintained by a small group of contributors—or sometimes by a single person—without paying anything for the software itself.
That arrangement has always been fragile. Now, as generative AI changes how software is created and consumed, the cracks are becoming harder to ignore.
A growing number of familiar projects are experimenting with commercial licenses, dual licensing, paid support, or closed-source future releases. The important question is not whether AI invented this trend. It did not. The better question is whether AI is accelerating pressures that open-source maintainers were already struggling to absorb.
The Licensing Shift Is Already Visible
The .NET ecosystem offers several recent examples. AutoMapper 15 and MediatR 13 introduced commercial licensing requirements for many business users, while their earlier releases remain available under their original open-source licenses. Fluent Assertions adopted a model in which version 8 and later remain free for open-source and non-commercial use but require a paid license for commercial use.
A similar change is reaching frontend development. PrimeTek has announced that future major releases—PrimeNG 22, PrimeReact 11, and PrimeVue 5—will be distributed under the PrimeUI license rather than released as open source. Existing MIT-licensed versions keep their original terms, so the change is prospective rather than retroactive.
These decisions have practical explanations: salaries, support obligations, security work, documentation, compatibility testing, and years of maintenance all cost money. Popularity does not automatically pay those bills.
AI adds a new dimension to that old sustainability problem.
Code Production Scales Faster Than Human Attention
Generative AI can produce a feature, test scaffold, bug report, or pull request in minutes. That sounds like an obvious advantage for open source—and sometimes it is. AI can help contributors understand unfamiliar codebases, improve documentation, translate examples, and automate repetitive work.
But contribution volume and contribution value are not the same thing.
A maintainer still has to understand every meaningful change before merging it. Someone must verify the assumptions, reproduce the bug, evaluate architectural consequences, run tests, inspect security risks, and support the result after release. AI can assist with parts of this process, but accountability remains human.
This creates a fundamental asymmetry:
Code became cheaper to generate. Trust did not.
If AI enables ten times more people to submit plausible-looking changes without providing ten times more experienced reviewers, the maintainer becomes the bottleneck. A project may receive more activity while becoming less sustainable.
AI May Also Disrupt How Open Source Captures Value
Open-source projects do not rely only on direct license revenue. Some sell hosted services, enterprise features, consulting, training, or premium support. Others use documentation traffic to introduce paid products and sponsorship options.
AI assistants can weaken those channels. When developers ask a model how to configure a library instead of visiting its documentation, the project may lose website traffic, product discovery, attribution, and opportunities to convert users into customers.
The model has absorbed the public knowledge, but the project maintaining that knowledge may receive nothing from the interaction.
This does not mean developers should stop using AI. It means the value flow has changed: information can now travel from an open project to an end user without passing through the project's own community or business layer.
Public Code, Model Training, and the Attribution Gap
There is also a psychological cost. A developer who publishes an experiment today knows that its code and documentation may be collected, summarized, imitated, or used in model training. Some authors will be comfortable with that. Others may feel that the social contract has changed—especially when a commercial model can help generate a competing implementation without meaningful attribution or compensation.
Licensing makes the issue even more complicated. Suppose a maintainer spends months building a GPL-licensed project, and an AI system later helps someone produce a closed-source alternative with similar behavior. It may be extremely difficult for an individual maintainer to demonstrate whether protected expression was copied or whether the new implementation was independently generated from ideas and public interfaces.
Training legality, copyright infringement, and open-source license compliance are related but distinct questions. The answers depend on the model, its output, the evidence available, and the relevant jurisdiction. For small maintainers, however, even establishing the facts may be financially unrealistic.
Security Cuts Both Ways
AI can help open-source teams identify vulnerabilities, generate tests, explain unfamiliar code, and review risky changes. These are meaningful benefits.
The same capabilities are available to attackers. Public repositories can be analyzed at scale, reducing the time and expertise required to locate weak validation, unsafe defaults, outdated dependencies, or exploitable edge cases.
Open source has long argued that public scrutiny improves security—and often it does. But scrutiny only helps when defenders have enough time and resources to respond. AI may increase the speed of both discovery and exploitation while leaving patching, coordination, and release management dependent on overstretched humans.
AI Is an Accelerator, Not the Original Cause
It would be misleading to blame every licensing change on generative AI. Maintainer burnout, corporate free-riding, inadequate sponsorship, cloud vendors commercializing community work, and rising support expectations existed long before modern language models.
The recent licensing changes do not, by themselves, prove that AI is the primary cause. Projects mature, costs grow, and maintainers eventually seek sustainable business models.
What AI changes is the speed and scale of the pressure. It increases code volume, creates new demands on review and security, changes how users access documentation, and intensifies concerns about reuse without attribution. In that sense, AI is less like the spark and more like oxygen feeding an existing fire.
What the Next Generation of Open Source May Look Like
Open source is unlikely to disappear. Its technical and cultural advantages are too significant. But the default model may become more varied:
- Open-source cores paired with paid hosting or enterprise capabilities
- Free community editions with commercial licenses for larger organizations
- Source-available licenses that restrict competing hosted services
- Paid long-term support and security maintenance
- Community forks of the last permissively licensed release
- Contribution policies that require disclosure or verification of AI-generated code
For maintainers starting a valuable project today, the licensing decision is no longer merely philosophical. It is part of product design.
A sustainable project needs to answer several questions early: Who pays for maintenance? Which users receive commercial value? What remains permanently open? Can contributors' work be relicensed later? How will AI-assisted contributions be reviewed? And what happens if adoption grows much faster than funding?
The healthiest future is probably not one in which everything becomes closed. Nor is it one in which maintainers are expected to provide unlimited free labor while others capture the economic value.
The real challenge is building a new bargain—one that preserves open collaboration while making reliability, stewardship, and long-term maintenance financially viable.
AI can generate more software than ever before. Whether that software remains open will depend on whether we learn to value the people who keep it trustworthy.
Top comments (0)