The clause addresses how future versions of the license will be handled and state that the Free Software Foundation (FSF) may publish new versions of the GPL, which will be similar in spirit to the current version but may include changes to address new legal and technological issues. This also ensures the protection of Free Software from potential missteps by the Free Software Foundation (FSF) itself as, for example, no one could state a valid GPLv4 without copyleft. Some argue that the GPLv3 is fundamentally different from the GPLv2, but a detailed examination shows this is not the case–it is indeed similar in spirit. Just read it for yourself. For our part, we therefore strongly recommend choosing the “or later” option for our own projects.
Using GPL-2.0-only in the past created significant compatibility issues with other licenses, hindering the integration and distribution of combined works. For example, software licensed under GPL-2.0-only is incompatible with the Apache-2.0 license, preventing the combination of many codebases even today. And some projects had to spend a lot of time and work to change licensing to achieve better license compatibility and reduce integration barriers. These issues can lead to fragmentation and reduced flexibility in the open-source ecosystem.
GPLv2 showed that this adaptability might be necessary, as sticking to GPL-2.0-only did not provide any significant benefit and led to compatibility problems. Therefore, it makes sense to adopt the “or later” option whenever possible. This approach not only preserves the spirit of the license but also provides a safeguard against potential future challenges, much like a well-prepared contingency plan.
The “or later” clause of GPL-3.0-or-later is crucial as it allows the evolution of the license to keep up with changing circumstances, ensuring ongoing protection and freedom for software users and developers. This clause is like a safety net that allows us to adapt to future changes in the legal and technological landscape and to enable cooperation from various parties in the future. Use it.
It is the same with Clause 9 of GPLv2. ↩︎
Licenses like the General Public License (GPL) are usually better for the open-source ecosystem than permissive ones like Apache 2 or MIT as they require that any modifications or derivative works are shared, promoting a cycle of continuous contributions and improvements. Enhancements are distributed, benefiting the entire community rather than allowing the exploitation of open source code without giving back (looking at you, Amazon Web Services).
Licenses like the GNU Affero General Public License (AGPL) might prevent some corporations from using an open-source project because they do not want to release the source code of their own modifications to it. Sadly, corporate compliance often prohibits the usage of copyleft projects altogether, even if nobody plans to modify anything. Especially the legal departments of large “enterprizy” organizations often prefer software with licenses like MIT as they want it simple and “risk”-free.
In light of license changes, the impression comes to mind that many start-ups use open source not because of freedom but as an argument for adoption in the enterprise ecosystem. They avoid choosing (A)GPLv3 licenses to facilitate easier corporate adoption without generating enough revenue, while being funded by venture capital and without getting contributions back by organization who could easily afford giving back something. Then, after being adopted, they complain.
While the open-source contributions from corporations like HashiCorp are impressive, the overall situation is complex. There’s a reason why Linux (GPL licensed) is still around, growing, and making money for so many while companies behind widespread open source projects often fail financially and burning insane amounts of money. It might work out for individuals and owners when getting bought, but it hurts users and ecosystems who relied on something.
So don’t be surprised if licenses like MIT attract large corporations and users who don’t care about you or the community, making it difficult to find fair cooperation (including financial resources) with them later. Stick with a real, copyleft license that has less adoption by other enterprises and focus on organic growth with people who care about the project.
Alternatively, be prepared for the consequences that Amazon or other hyperscalers will attract a large number of customers using your product without giving anything back—as you stated that’s OK by using e.g the MIT license.
If you still want to go that route, you must establish another source of income right away. One has to be realistic: Competing with your open-source product’s own SaaS against any SaaS by Amazon or other hyperscalers—or even the well-trained on-premises operations team—will not work out if that’s your only way to make money. Services that support users in operating in-house or enabling paid development (e.g., prioritizing features for a fee) are also possible with open source and are the better choice.
]]>