Open source licence series - Percona: is the battle won, or is this a different war?
Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.
The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.
Peter Zaitsev, CEO of Open source database management and monitoring services company Percona writes from this point forward.
For years there has been a ‘battle’ between the proponents of ‘free and open source’ software and ‘proprietary’ software. The GNU General Public License (GPL) was famously once called a “cancer” by Microsoft’s ex-CEO Steve Ballmer, and a killer of intellectual property by Jim Allchin.
This battle did not lead to the complete annihilation of either side.
Both open source and proprietary are thriving, just in different areas. Open source software has even [now] won ubiquitous recognition from an old arch-enemy, Microsoft, which has made a complete turnaround to embrace open source.
However, there is now a new battle raging, the battle for open source Itself.
Open source proved [I would argue] that it can provide superior value compared to proprietary software, so there is now a great deal of value in the marketplace by being able to call your software open source.
No trademark, no problem
Interestingly, the terms of free and open source software are not trademarked, like organic labels are for food products. There is a general understanding of what open source software is along with a few published (and respected) definitions: The Free Software Definition by Free Software Foundation, Open Source Software Definition by Open Source Initiative (OSI) and Debian Free Software Guidelines. Out of these, only OSI takes an active role in this — you can submit a licence to OSI for evaluation and receive an OSI badge of approval for your licence.
In recent years, the black and white nature of free and open source software definitions has started to face some challenges. First, as a result of trying to prevent unfair competition by cloud vendors, companies are offering as-a-service versions of open source products without sharing the spoils or their own innovations with the public at large. Second, on the ethical side, free and open source software is not placing any restrictions on how software can be used, which can be for good as well as for evil, a concept found repugnant by some activists. While the good and versus question is specifically covered by the OSI FAQ with the clear position, “giving everyone freedom means giving evil people freedom, too,” it is the more nuanced cases that expose the cracks in the system.
No whom, but how
Recently, the Cryptographic Autonomy License (CAL) was submitted for OSI consideration. As Holo’s co-founder Arthur Brock explains in his blog post, his goal is to protect end-user privacy and autonomy. Restrictions in this case focus not on whom, but how the software should be used.
While many on the OSI board seem to support the licence, Bruce Perens, OSI co-founder and the person who drafted the original Open Source Definition (OSD), resigned from OSI saying, “… it seems to me that the organisation is rather enthusiastically headed toward accepting a licence that isn’t freedom-respecting. Fine, do it without me, please.”
What does this tell us? Is the previously unified community fractured at the core? Does it affect what free and open source software means? There are a couple of outcomes possible here.
Open, but by another name
First, it is possible the definition of free and open source will be diluted by allowing restrictions such as those placed by CAL or MongoDB’s Server Side Public License (SSPL), which have not been approved by OSI to stand. If this happens, it is likely the hardcore open source advocates will have to find a different name to use.
Second, it is possible there will be a need for two (or more) definitions to be recognised and a different name will be determined that is more restrictive than the classic open source definition, but still not quite the same as proprietary. For this to happen, we need to recognise the need for more than one definition and switch arguments to it, rather than trying to define what open source is, or is not.
Interestingly, in the past, the open source community accepted two very different approaches to licensing which have existed in parallel for many years. Specifically, “copyleft” licenses, like GPL which place restrictions on the “derived work” and “permissive” licenses which do not place such restrictions.
Marketing muscle
My hope is for the second outcome, but because of the high marketing value of the term “open source” it would be hard to see the industry preferring a diluted open source definition.
Understanding how open source licensing reflects the wide variety of differences across the industry, from individuals and single software projects through to large enterprises and entire markets founded on open source, should help in this process. However, this means recognising that this is also a battle that cannot be won in the conventional sense, as there are no longer two sides involved.
The truth is that there are no simple answers to the questions around what should happen to open source licensing, even though we should encourage everyone involved to do the right thing for the whole community. Instead, there will only be context.