The GNU Public License is popular with many developers, but it’s lost a lot of its momentum over the years. Commercial developers hate it, because it imposes complexity into license management. The “GPL virus” is a bit exaggerated, but the reality is that the moment you include some GPL code, you’ve got to have a link where people can download the source. I mean, my car has an option to read the GPL on my dashboard.
If I’m a company developing software, who needs that headache? Particularly in a litigious society. There may be societal benefits to copyleft code – that is the Free Software Foundation’s argument – but there is zero benefit to a commercial software publisher or distributor.
I also think the rise of GitHub has played a role. When you go to choose a license for your repository, several options are chosen. If you look them over, the MIT license is certainly far easier to understand than the GPL.
In prior years, GPL-licensed software was so common that companies almost had to include it. This is changing rapidly.
First, the Gnu Compiler Collection (gcc) has been eclipsed by LLVM/Clang for many tasks, and it has industry heavyweights behind it. The common toolchain used to create software no longer has the big flagship project that was gcc. Richard Stallman has called this a “terrible setback“.
Second, there is an ongoing effort to rewrite many core Linux utilities in Rust, in the name of security. These utilities are MIT-licensed, not GPL licensed. There is a compelling reason (security) for distributions to adopt these tools, and they have. You can expect that from here on out, GPL packages will be replaced by MIT-licensed ones in Linux distros.
In both cases, non-GPL licenses are being chosen. As the universe of GPL software shrinks, it has a snowball effect. The GPL becomes less visible, and the network effect of the GPL is diminished with every migrated project. If the Linux project is mostly GPL-license software, the next developer will license with the GPL. But what happens in the future when only the kernel is GPL-licensed? The kernel has too many contributors, of course, to relicense but…
…actually, hold that thought.
Recently there was a kerfuffle about the chardet project. chardet is a Python module (and a very popular one, with 170 million downloads), which has been licensed under the GPL. A different developer was hoping to include it in the Python standard distribution, and decided to reimplement it.
With AI.
And did so in 5 days.
From start to finish, a complete clean room implementation was done. The original developer is raising holy hell, but it’s hard to see how they have a case to stand on. Every file is different. Automated plagiarism checks report only 1.3% in common code (and you’ll always have some common boilerplate in software).
In a true “clean room” implementation, you isolate some people from any access to existing source code, and you tell them to write a similar program. You can never truly do that with open source software, because it’s ubiquitously accessible. But if you examine the source code and compare new vs. old, it’s clear if someone was just mechanically copying things and doing some light variable-renaming.
Here, the reimplementation looks very clean. Different code, different algorithms, and better performance.
This was done using Claude. Now…how long before other GPL projects are replaced?
Imagine you’re a company and you want to use some GPL software. Do you really want to inject that licensing headache into your project, or do you want to have an engineer spending a week reimplementing it with AI assistance? I know which I’d choose.
Fast forward a couple years…how long before the Linux kernel itself is rewritten? Maybe there’s still the “official” kernel that is GPL-licensed, but there could be a shadow kernel that is MIT-licensed which tracks it. If reimplementing software becomes cheap and easy, commercial entities and developers who don’t like the GPL will swiftly replace it.
Copyleft was an intriguing idea. Emphasis on the verb. Given the pace of AI advancement, can it have more than a few years left to live?
Related Posts:
raindog308 is a longtime community LETizen, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.
As an avid user of LowEndBox providers, raindog308 runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.
Beyond the command line, raindog308 has a life-long love of German Shepherd Dogs, high-quality knives, target shooting, theology, tabletop RPGs, playing guitar, and hiking in deep, quiet forests.
His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.
You can find him daily in the forums at LowEndTalk under the handle @raindog308.