The moral contract
In today's rapidly evolving technological landscape, the spirit of free software and open-source projects is being put to the test. As businesses seek ways to monetize their efforts, the balance between maintaining openness and generating revenue has become increasingly complex. In this blog post, we will delve into the challenges faced by the open-source community, exploring various business models, the concept of the "moral contract," and how some companies may be abusing the system.
I will also discuss alternatives like Open Core and fair-use licenses, and whether they align with the initial principles of free software. By examining these issues, I hope to shed light on the ongoing debate and inspire further dialogue on how to preserve the core values of the open-source movement while ensuring its sustainability in the modern era.
This blog post is not about winning a "purity" contest, but rather about understanding and navigating the challenges of upholding the spirit of free software in an era that has evolved significantly since its inception.
🎍 The essence of free software
Before delving into business aspects, it's essential to understand the underlying principles or the "spirit of the law" governing free software. The foundations of free software are evident in the first Free Software license, known as the General Public License (GPL). This license embodies the idea that users should be free to use, copy, modify, and redistribute software, with the source code available to everyone as shared knowledge for all of humanity.
But what was the intention behind these rules? Primarily, Richard Stallman wanted to prevent corporations from taking control of software back in the 1980s. The GPL provided a safeguard against this, as David A. Wheeler explains:
David A. Wheeler argues that the copyleft provided by the GPL was crucial to the success of Linux-based systems, giving the programmers who contributed to the kernel the assurance that their work would benefit the whole world and remain free, rather than being exploited by software companies that would not have to give anything back to the community.
To me, this statement encapsulates the essence of free software: using it as desired while contributing to the greater good.
The concept of giving back may seem naive to some, but I believe it forms the foundation of cooperation, which in turn enables us to progress efficiently as a group, civilization, or society. This core personal belief of mine is arguably supported by scientific evidence, although this article is not a scientific paper.
Despite the evolution of licensing rules (e.g., via the Affero General Public License v3 or other licenses), some corporations persistently attempt to exploit or circumvent them for personal gain. If the majority of companies follow suit, it could threaten the existence of free software as we know it. With that in mind, let's return to our central topic: generating revenue from open-source projects without compromising the spirit of free software.
💰 Open Source, business & collaboration
Open Source and Free Software are not solely the domain of hobbyists. While hobbyists play a crucial role in kickstarting ideas, developing innovative proofs of concept, and creating exceptional software, larger projects often require more extensive features, support, and bug fixes. These demands are typically addressed by teams backed by companies or charities. For instance, the Linux kernel is partially supported by the Linux Foundation, with Linus Torvalds leading the project.
One advantage of having an organization working on software, as opposed to an individual or multiple individuals from different entities, is the increased efficiency in release speed and decision-making. With a dedicated team, collaboration is often quicker, and clear choices can be made when there is a primary editor or a designated person to resolve issues or make decisions. A fitting analogy would be a multi-state military program, where it can be more challenging and costly to achieve results compared to having a single leader or a single-country program.
Ultimately, Open Source and business can coexist harmoniously. In fact, the infusion of financial resources allows for hiring more people, expanding projects, and improving quality.
However, not all is perfect in this scenario. While it is possible to generate revenue without compromising the spirit of free software, some may abuse the system for their gain. In the next section, we will explore business models that align with the original principles of free software.
🫘 Various approaches to monetization
There are several ways to monetize Open Source software. Let's first examine the "original" free/libre/Open Source approach, where the software itself is accessible, free to use, and can be resold:
- The "RedHat way": this model relies on support and quality assurance, effectively selling a "stable release." Additional revenue streams include training, certification, and insurance. This "vanilla" model is challenging to replicate without reaching critical mass.
- The "SaaS way": your software is fully Open Source, without restricted features, typically using GPL-like licenses. As the primary editor, you can deploy it as an online service, often as a SaaS offering. While anyone can self-host it without limitations, achieving stability without in-depth knowledge can be time-consuming and challenging: this approach lacks support and guarantees. Training and certification can provide extra revenue.
- The "Hybrid way": if you cannot offer your software in SaaS mode, like an on-premises virtualization platform, you can integrate it with additional SaaS services. This "hybrid" approach combines aspects of both Red Hat and SaaS models. Dedicated appliances, virtual or physical, allow for greater control over the entire stack: the turnkey approach. At Vates, this model is applied to XCP-ng and Xen Orchestra under the Vates virtualization stack, featuring a virtual appliance and support bundles. Training and certification are also additional possibilities.
In my opinion, these three methods align with the spirit of the original Free Software movement. In any case, an individual can use the entire software, even without support. Users can self-train, becoming expert users or even contributors without any financial investment. Payment is only required for services such as integration, QA, SaaS offerings, and so on.
Are these models sustainable? I believe so, as demonstrated by Red Hat and our own experience. However, they are challenging to implement because some companies may exploit the system. If achieving "real" Open Source is difficult, are there any easier models? Why do other models seem to work better, and why do clashes sometimes arise between companies regarding their use of free software?
As with any system, abuse is possible at the expense of the greater good. Free software was created in the 1980s, long before the era of public cloud and SaaS. While users are free to use the software without restrictions, services, or support, individuals or companies can enjoy everything for free. This aligns with the principles of free software and fosters a sense of community. One of the best outcomes of free software is connecting individuals through its usage. While proprietary products can also create communities, the key difference lies in the ability to modify and improve the software and share these changes with others. This encourages the fundamental principle of free software: collaborative development.
So, what constitutes system abuse? It boils down to scale and a moral contract.
🙉 The moral contract
With the term "moral contract," I aim to define a particular boundary. The phrase comprises two words: "moral" and "contract." Let's begin with "contract." This contract is between two parties: the user of the software and the entity primarily responsible for its development, which we will call the main contributor.
"Moral" refers to actions that, while not illegal, may be considered harmful to the greater good. In other words, one can abuse the system without breaking the law, but it is still morally questionable.
Based on this definition, we can draw an initial conclusion: free software can be abused by either party involved, the main software editor or the end-user. Let's see how.
Abusing free software as the "end user"
The end user refers to an individual or a company using free/open source software. The spirit of Free Software, however, is not designed to protect the software against individual users. Its original goal was to prevent companies from exploiting it without contributing back.
Now that we know companies can abuse free software, how do they do that? Let's analyze one example to understand some ways this can happen.
The first public Cloud
Having an entire business rely directly on free software without ever contributing is one way to abuse it. This is the very reason the GPL license was created. "Exploited" means not providing feedback, documentation, code contributions, or even acknowledging its use. While this is legal, it is not moral. The degree of immorality depends on the scale of the abuse.
In our example, Amazon created AWS using Xen as their hypervisor but never contributed at a scale proportionate to the profits they made from their cloud. The gap between the revenue generated thanks to the free software and the level of contribution is immense: hundreds of billions in revenue compared to maybe a few million in investment, upstream contributions, or publicity for Xen.
This was possible due to a "loophole" in GPLv2: since AWS never redistributed the software, only the service on top of it, they were not legally bound to contribute. It was addressed in aGPLv3, but as being a derivative of Linux, Xen Project was and still is GPLv2. Amazon decided to exploit this loophole. If just a small portion of their revenue had been funneled into the Xen Project, its scale could have been much larger.
On the other hand, the misuse of Xen in relation to the free software spirit might have demonstrated its scalability and reliability. One could argue that it's better for the software to be utilized, even if it goes against the principles of free software, than not being used at all, as long as it doesn't jeopardize the project's future and sustainability.
Smaller companies also engage in this behavior, but on a smaller scale, resulting in less harm. For example, some companies use our stack for free without sharing anything, despite generating all their revenue with it. While this is legal and a valid "play," it breaks the moral contract, as generalizing this behavior would ultimately kill the product or force it to adopt a model other than "full" Open Source.
The "real" Open Source/Free software model works as long as people pay for a service, whatever that may be. It is up to the companies creating such open software to communicate and generate enough perceived value through their services to be paid for it. Achieving this delicate balance is possible, and everyone wins if the moral contract remains intact.
However, in response to potential breaches of this moral contract (or the fear of them), some editors have chosen an alternative model. We will now explore why this alternative path can be a slippery slope concerning the original spirit of the Free Software movement.
Abusing free software as a software editor
In response to the first category of "abusers" (the "end users"), some software editors have devised a solution to ensure payment for the use of their partly open-source code. This approach, known as "Open Core," is seen by some as a "fair" way to redistribute value because users are required to pay. By reducing software freedom, the Open Core model aims to prevent companies from breaking the moral contract. While the idea may seem attractive at first, it's important to examine the implications of this approach.
🔒 Open Core is the new shareware
To me (and to OSI), Open Core isn't really Open Source/free software, because users don't have all the freedoms to do whatever they want with the software. Only the "core" is open, and the definition of "core" can be abused. In some cases, almost all important features are not in the core, making the entire software nearly useless without paying for the rest. It resembles more of a "demo" or shareware, which deviates from the original spirit of free software. But is it bad?
In my opinion, yes, it's bad: Open Core diminishes the value and attractiveness of free software for the sole purpose of increasing the main editor's revenue. Some people even call this "open source washing," similar to "green washing" for companies faking their true commitment to reducing their climate impact. In short, you think it's Open Source, but it's not. Some companies claim to be Open Source while only offering Open Core. Even some investment funds promote Open Core because it's an easy path to make more money while appearing "open."
At least, certain companies have become more aligned with this reality: for example, try searching for the word "Open" on https://about.gitlab.com. Good luck. GitLab started as open core relatively early in their development and gradually became less and less open. Now, they don't seem to care about being "open" anymore. This is a typical example of a slippery slope: as you start with Open Core, there's less incentive to release any new feature in the "core." Over time and with new releases, the software becomes more and more proprietary.
Nonetheless, Open Core is a whole continuum: ranging from having only a few closed features to almost everything closed or sometimes almost all features open but without the freedom to use them as desired. To me, the real problem with Open Core is the gradual shift towards proprietary products, as the temptation is great. This shortcut has the pernicious effect of slowly but surely killing free software. Is it feasible to adopt Open Core while maintaining the same proportion of free software and making responsible decisions about feature accessibility (see below)? Perhaps, but it's unlikely that most companies opting for Open Core will achieve this balance.
Fair-use or fair-code licenses
Fair-use or fair-code licenses, also called "Sustainable Use" licenses, provide another alternative to Open Core. With these licenses, you remove one liberty from the original free software licenses: the freedom to commercialize or resell the software the way you want. If you use it for internal purposes (within your company), that's fine. If you want to build a service on top of it, such as hosting it and selling that service, you can't.
This approach is interesting, as it still allows individuals to use the software as they want while limiting corporations' ability to exploit it without contributing. However, it also makes it less attractive for a company to contribute, as building things around locked software is less appealing.
In my opinion, fair-use or fair-code licenses are a lesser evil compared to Open Core. This model can make sense for some software that is easy to resell, such as a database software that could be sold by a large third-party cloud provider. It's probably less dangerous to free software than Open Core.
Unfortunately, I've seen companies combining both fair-use and Open Core, which, in my view, is very close to proprietary software. It's even worse because users can be lured into using software they think is open when it's not. For example, https://n8n.io/ displays "Full source code available" and "Self host-able" on their website, while offering only a few open features (small open core and most features closed) and using a fair-use license.
⚔️ Admission of failure?
Is the situation a failure of free software licenses to protect the initial concepts in the age of Cloud, SaaS, and such? Perhaps. But there are many ways to maintain openness while making money. It will be interesting to explore these approaches in a future article, shedding light on how businesses can strike a balance between maintaining the spirit of free software and achieving financial success. The key lies in finding innovative solutions that honor the moral contract and preserve the core principles of the open-source movement.
The Open Core movement stems from two factors: first, a reaction to the initial breach of the moral contract by end-users, and second, the desire to take a shortcut to avoid the difficulty of monetizing free software.
As a free software editor who has built a company from scratch with 40 people working on fully open-source products, I know it's hard. We've managed to grow and make millions while preserving the original spirit of free software. It might require more effort than taking the open core shortcut, but I don't think we're unique, and others can succeed in the same way. It involves solving more problems, improving communication, and making the value proposition clear.
Free software is everywhere, and if we want it to stay that way, it's worth fighting for. As a software editor, our mission is to find ways to maintain openness while providing more value in our service, increasing visibility of our work, and fostering understanding from our users, both individual and corporate, that all our work is possible thanks to the moral contract. Many community users understand this perfectly. For companies, it's our responsibility to create a product where it makes no sense to use it without paying, even if the customer doesn't care about free software.
Member discussion