Free Software and LLM Contribution Policies

Multiple free software (or open source) projects have policies that forbid, or in some cases allow with extra scrutiny and scepticism, contributions that are supported by AI-augmented tools. I believe that this is a poor decision for many reasons, which fall under these categories:

1. The Four Freedoms
2. Free Software and Copyright
3. Freedom to Fork
4. Historical Discontinuities
5. Unintended Consequences
6. Miscategorized Assumptions

I will present my argument on each point, then conclude by saying the policy I believe that these projects would be better served with. This is just my suggestion, of course, I’m not in a leadership position on any of the projects and I’ve only contributed to them in minor ways.

1. The Four Freedoms.

Central to the philosophy of free software – and transitively to the open source philosophy – are the four freedoms. The GNU project website spells them out in full, but I like the pithy summary from FSF Europe: ‘use, study, share, improve’.

Given these freedoms as axiomatic, it seems perverse to introduce a policy that restrict someone’s freedom regarding the way they use their computer to work with the software, at the point of contributing to the software.

Imagine a contributor policy that says ‘you can’t submit patches to this project that you edit with vim’, or ‘we reject submissions if we find that you used Windows to test them’. These seem absurd, but they’re consistent with what’s happening with LLMs: the project team doesn’t like the tool you used to prepare the software change, so it rejects the change regardless of the consequences of doing so.

2. Copyleft

In Free as in Freedom (2.0), Richard Stallman observes that “use of copyright was not necessarily unethical. What was bad about software copyright was the way it was typically used, and designed to be used: to deny the user essential freedoms.”

In “What is copyleft?”, he writes, ‘proprietary software developers use copyright to take away the user’s freedom; we use copyright to guarantee their freedom. That’s why we reverse the name, changing “copyright” to “copyleft”.’

One of the concerns people have with LLM-authored contributions – a subset of the types of contribution these policies ban – is that the copyright status is unclear in many places, with one early indicator being that LLM-authored contributions might not be copyrightable.

If this is the case, then nobody can remove the freedom of people who use that contribution. If that isn’t the case, and the work is the creation of the person who used the AI tool, then they can use a freedom-preserving license.

If, instead, we enter a new era of copyright … well, anything could happen, but the way to have a say is to build competence, authenticity, and respect in society by engaging with the problem, not by withdrawing from it.

3. Freedom to Fork

The freedom to distribute your modifications and to distribute copies of the software explicitly doesn’t require people to ‘upstream’ their modifications; that is, to contribute them back to the place where they originally got the software. In fact, licenses with clauses that mandate upstreaming are non-free, for example, the earliest versions of the APSL.

Someone who modifies your software using an LLM, then has their upstream patch rejected, is free to distribute it anyway, creating a fork in your project. They might choose to track and apply changes in your project – not too much work, after all they can use an LLM to do it – so that your version of the project becomes the one with the recognizable name, but a subset of the features. At one extreme, this means fracturing the project’s community, along tool-use lines. At another extreme, it means the original project becomes irrelevant and the replacement takes over, as happened to GCC and EGCS.

4. Historical Discontinuity

Free software always has coexisted with and even used non-free software. GNU Emacs was only one of about 30 emacs implementations. GNU itself uses Unix as its design document, and the original GNU components ran on proprietary UNIX distributions, because there was no fully-free environment available – so people used proprietary development tools, libraries, shells, and kernels. Even today, many free software components are portable to proprietary environments like Windows or macOS, and you can use proprietary tools like Microsoft’s compiler or NotePad++ to work on them.

Anti-LLM policy muddles the software freedom message by making the community values more about position on LLMs than about software freedom. This risks making it easier to dismiss genuine concerns about software freedom, because the people involved are seen as opportunists riding a temporary wave of situational sentiment, rather than supporters of a strong principled position that they defend in all circumstances.

Bradley M. Kühn of the Software Freedom Conservancy wrote of the Challenges in Maintaining a Big Tent for Software Freedom – the LLM moment is one of those situations where we should keep the big tent open.

5. Unintended Consequences

It’s already the situation that a well-resourced proprietary software vendor who disagrees with the license of a free software component can staff up a team to reimplement a proprietary version. If the no-LLM policymakers get their way, and all free software is either LLM-free or fractured into irrelevance, then it becomes supremely inexpensive to spin up proprietary versions of free software components – and ridiculously expensive to maintain free software versions of proprietary components. Software freedom would lose the significant (but already precarious) foothold it gained in computing over the last few decades.

As the LLMs tool evolve and improve, the gap would become wider. Free Software risks becoming a historical reenactment activity, in which people type in code the old-fashioned way, and upon sharing it immediately gets cloned by a hundred LLM agents.

I’m not saying that’s a necessary conclusion, and it’s certainly an undesirable one, but I do see it as a real risk.

6. Mischaracterized Assumptions

Reading Stallman’s position on LLMs, one sees that he’s mostly concerned about the non-free, cloud-hosted partner models that send all of the user’s data to the model provider. That’s a genuine and valid concern, one that’s consistent with his long-standing views on hosted software and software freedom. But it’s an incomplete picture.

At the opposite end of the spectrum is Apertus, a model for LLMs which that applies an open training process to open data to produce an open-weights model that you can host in a free software harness, and use from a free software UI.

A ‘no-LLM’ policy that forbids Apertus shoots software freedom in the feet – and prevents software freedom advocates from evangelising the benefits we’d see if more LLMs were like Apertus.

Free Software projects used to advocate for software freedom, while using proprietary compilers to build their free software until GCC was along and could support their needs. We can do the same with other tools, including LLMs.

7. A Way Forward

LLM-augmented coding tools empower people without traditional programming backgrounds to modify software to suit their needs, and to share their modified version.

Maintainers of popular projects are rightly concerned that rather than ‘fostering collaboration and improvement’, this can lead to hard to maintain projects that buckle under the weight of low quality, poorly thought out contributions that take time to interact with but don’t add value to the project.

This situation gets to the core of a hypocrisy in the ‘Cathedral and the Bazaar’ model of free software communities – the true bazaar model is difficult to navigate, so instead the free software world organizes itself into various unorthodox cathedrals, with their hierarchies and bylaws. As the bazaar increases in size, the choices available get harder to navigate, and the people who put themselves in the position of mediators, the clergy, get more and more work. Improving the access to tools that enable software freedom has the perverse effect of making maintainers want to keep people away from contributing.

The quality / anti-slop concern is easy to address by having quality criteria on patch submissions, with automated checks. Don’t tell people they can’t submit patches if they use particular tools; tell them their patches are only considered for acceptance when they meet the quality criteria. In addition to cleaning out the frustration matrix of confusing tool use for quality (the submissions that are low quality & produced without LLM, and the submissions that are high quality & produced with LLM); this approach allows anyone who wants to contribute – using whatever tools – understand and adopt the quality rules of the upstream project; ‘fostering collaboration and improvement’ as stated in the Four Freedoms.

The non-free concern is addressed by advocating for software freedom in LLMs – the same way we’ve been advocating for software freedom in web browsers, office suites, and other applications for decades.

The copyright concern is addressed by representing our position on software freedom strongly, consistently, and authoritatively, so that we earn the right and respect to influence the people who make those decisions. If we do not, then only the people who run the LLM companies – along with traditional anti-freedom advocates like record and motion picture industry associations – will be in the room, and we will not.

It might be that we need to identify new freedom and new principles to uphold in the LLM age – Matthew Skala has written his 11 freedoms for free AI, for example. What we definitely don’t need to do is to abandon our existing principles in favor of opportunistic positions in the debates of the day. That is a recipe for being sidelined in all debates, and for watching software freedom become irrelevant.