The GPL: A Controversial License in the Open Source Landscape

A recent incident surrounding Red Hat has sparked considerable discussion in the open-source community.

The company has opted to place its source code behind a paywall, prompting backlash from Linux enthusiasts. In response, Red Hat issued a blog post that can be distilled to a blunt message: “Pay us or go away!”

Initially, I struggled to find a compelling angle to discuss this situation. After all, it’s not unusual for a company to alter its product offerings. The uproar itself suggests that many users see value in Red Hat’s services. If complaints were absent, I would be concerned about the company’s relevance. Nevertheless, it puzzled me why Red Hat elicits such strong opinions. Alternatives like Debian or Ubuntu exist and are often more user-friendly.

Upon further reflection, I realized this issue transcends Red Hat; it's fundamentally tied to the GPL.

The GPL, or General Public License, is utilized by numerous free software projects. It's often termed a “copyleft” license because integrating GPL software requires that your modifications also be distributed under the same terms.

Ironically, despite being an open-source license, the GPL imposes significant restrictions. As stated in version 3 of the GPL:

> To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

I personally prefer the clarity of version 2, which articulates:

> To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

This paradox of “protecting your rights by limiting them” is reminiscent of Orwellian themes. Interestingly, the GPL mascot bears a striking resemblance to a devil—perhaps not in appearance, but it certainly has horns.

The rights curtailed by the GPL primarily include the ability to keep modifications private. If you alter GPL-licensed code, you are obligated to share your changes with others. This leads us back to the controversy surrounding Red Hat.

By placing its code behind a paywall, Red Hat is treading a fine line. While there's nothing inherently wrong with this approach, it skates perilously close to what could be deemed a “GPL violation,” exploiting ambiguities within the license as noted by the Software Freedom Conservancy.

A Closer Look at the GPL's Impact on Red Hat's Business Model

When incidents like this arise, I often ponder their root causes. Why has this occurred, and what makes it controversial? The answer appears to be the GPL. Red Hat contributes significantly to Linux but seems to feel that its contributions are not sufficiently compensated, prompting them to monetize further.

So, why does Red Hat rely on the GPL at all? The straightforward answer is that it doesn’t have to. However, due to the GPL’s copyleft nature, it must. Given that Linux is GPL-licensed and dominates the server OS landscape, using Linux is essential for companies wanting to compete in that space.

But why is Linux bound to the GPL? The license has undoubtedly facilitated Linux's development. Its copyleft stipulations have kept fragmentation at bay, ensuring a more unified ecosystem. While some fragmentation has occurred, the GPL has mitigated this issue significantly.

However, the GPL also hampers Linux's progress. If a company like Red Hat develops a patch, it must share that code with everyone using its software. This open access diminishes the motivation to innovate since anyone can appropriate your advancements. Critical fixes may be pushed upstream, but less urgent enhancements often languish unaddressed. Consequently, GPL software is often sufficient for businesses but tends to be less accessible for everyday users. Business-oriented applications like Inkscape, Blender, GIMP, and WordPress typically fall under the GPL umbrella. Despite its GPL status, VLC is a prime example where advanced features go underutilized due to its complexity.

While Linux is prevalent among businesses, it remains less common among consumers. The long-standing joke about “the year of Linux on the desktop” has persisted for over two decades. In fact, my game’s concluding chapter will be titled “The Year Of Linux On The Desktop” if I ever finish it.

The issues surrounding Linux can largely be traced back to the GPL. It incentivizes usability for servers but does little to make it approachable for non-technical users. Attempts have been made by companies like Ubuntu, Dell, and System76, but none have succeeded. Creating a new desktop OS requires backing from tech giants like Apple, Microsoft, or Google—entities that are increasingly distancing themselves from the GPL.

Apple is a prime example. The company appears to be removing GPL components from macOS; for instance, newer MacBooks come with ZSH instead of the GPL-licensed Bash. Recently, Apple introduced a DirectX 12 porting toolkit using Wine, which is LGPL-licensed. In an amusing twist, they’ve sidestepped the GPL by providing a script that downloads Wine’s source code, sets up a build environment, applies their patches, and runs it under Rosetta, thereby not technically distributing Wine itself.

Google, while currently using GPL code in Android and ChromeOS, is also moving away from it. The open-source version of Android, AOSP, comes with minimal out-of-the-box functionality. Most applications associated with Android are proprietary. Additionally, Google's development of a new OS called Fuchsia may be a strategic move to escape the GPL's confines.

Finally, we have Microsoft. Steve Ballmer’s infamous declaration of the GPL as “a cancer” inspired the title of this piece. While Microsoft appears to be embracing open-source, it remains uncertain whether they have truly accepted the GPL. Visual Studio Code, for instance, is licensed under the MIT License.

Companies are wary of the GPL, and rightly so. The license imposes restrictions that can stifle corporate flexibility. I've previously discussed this topic in detail.

The Conflict Between GPL and Capitalism

I initially considered titling this post “The GPL Is Incompatible With Capitalism” but decided against it due to the broader points I wanted to make. Nevertheless, the GPL’s enforced sharing of code embodies a form of socialism that is fundamentally at odds with capitalist principles.

Concluding Thoughts

Richard Stallman endeavored to compel companies to adopt the GPL, a license that mandates sharing. Essentially, it promotes a philosophy of “you will own nothing and you will enjoy it.” However, businesses have become savvy to these tactics. They dislike being coerced, which is why we see a proliferation of alternative licenses like MIT, Apache, and BSD.

In essence, the GPL can be seen as a cancer—not because it stifles growth but because it fosters it only to a point. Once GPL code reaches a “minimum viable product” status, it stagnates, consuming resources and hindering competitors’ growth.

Thus, the GPL could be viewed as worse than cancer. Much like how the Byzantines chose to blind rather than kill their enemies, the GPL disables its host without eliminating it.

Admittedly, this characterization may be overly dramatic. GPL software has its merits and can be invaluable during early development stages. However, it ultimately leads to a product that is challenging to use and has a steep learning curve. For business applications, this may suffice, but for other contexts, the GPL becomes a hindrance.

I anticipated that this article would stir controversy, and I’m not disappointed. However, I find the arguments lacking and would appreciate your insights. Do you agree or disagree? Please share your thoughts in the comments—I do read them eventually.

If you wish to keep up with my future articles and other exciting content, consider using my RSS app available on iOS and Android. This app supports Medium’s PubSubHubbub for quick updates, allows subscriptions to users and publications, and provides personalized notifications. It’s how I stay informed about my favorite creators across Medium, YouTube, Reddit, and beyond.