Open Source Does Not Require Empowering Your Competition
- Details
- Written by Zackary Deems
- Category: Open Source
- Hits: 29
It has been a few years since I've posted anything, and really, I'm not sure I really had much to share in that time. I try not to just throw out drivel just to add content, though I could be better about adding content more frequently.
At any rate, as many have noticed, Red Hat has changed the way they manage their source code, and many in IT are crying foul. The reality is that there is a major misconception - STILL - among IT consumers as to what Open Source means from a practical, consumption perspective, as well as from a competition standpoint. Consumers want to believe that because vendors like Red Hat build their products using projects released under licenses like (and especially) the GPLv3, that the resulting products should be freely available. Distributions like CENTOS and ROCKY Linux have spearheaded this effort, taking advantage of the early approach taken by Red Hat (and similar vendors) to complying with these development licenses. The original angst that lead to this arose from Red Hat's original policy change from "Red Hat Linux", which was freely available, to "Red Hat Enterprise Linux", which was only available with purchase of a subscription. Companies were outraged that Red Hat should have the gall to suddenly expect them to pay for what they had used for free to that point.
The GPL (and similar development licenses)
The GPL up through its third revision, essentially states that the source code released under it is freely available to anyone and everyone, free to modify, free to use in products you intend to sell, and free to distribute - with two major caveats:
- In order to distribute your modified version of the code (or derivative projects), you are required to make your changes available to the original project for inclusion in the upstream project (should they choose to implement the changes)
- You must also make the source code you modified available upon request.
It also technically requires you to maintain attribution for the original author and basically not try to claim you wrote it. You are 'standing on the shoulders of giants' after all, not wearing their skin like a costume. The attribution portion is the major bit that changed from v3 to v4. Most things released under v3 are non-graphical in nature, so it was sufficient to handle attribution in the source. As things became more graphics oriented, some developers started being a bit disingenuous and left the proper attribution in the source, while blatantly changing the visuals to appear as their own original works. They were technically in compliance with the letter of GPLv3, but definitely not the spirit.
If you think about the nature of what happens here, some person or team developed an original project on their own, and in hopes of allowing others to step in and extend and expand their project, they gave it away with the simple expectation that they would be given credit for being 'the person' who started it all. It makes perfect sense that if I pick up this project they started, that developer and likely that community, saved me a huge amount of time by getting the project to that point. Otherwise I would have had to do it all from scratch. So even if I vastly improve the project, it's still not right for me to try and claim it's now MY project just because I improved it.
Keep in mind that the GPL explicitly states that you are totally welcome to build your own thing using the project AND make money on it, so long as you abide by the requirements. It was never the intent of the GPL that a developer be required to create a competitive environment for a thing you build from an open source project. It's a development license after all. The intent is to ensure equal access to the source and that changes flow back to the project.
Understanding that fact, it's time to look at what Red Hat announced, and why people are upset. Spoiler alert - they're upset for exactly the same reason in exactly the same way that they were back around Y2K when Red Hat deprecated "Red Hat Linux" in favor of "RHEL".
Competing in an Open Source Ecosystem
When Red Hat first released Red Hat Linux, their approach to complying with the GPL requirements was twofold:
- They would contribute to the upstream projects and share their improvements to the code for everything they update
- They would make the Source RPMs for their packages available for public download.
The Source RPM (SRPM) is a pre-built package that includes the project source code, patches and build instructions necessary to build the RPM (installable package) for the product. So by making the SRPM available, they very plainly were in compliance with the second requirement of the GPL.
When they switched to a subscription model, the pre-built binaries were no longer available on public download sites, but they left the SRPMS where they were. Which is how the Community Enterprise OS (CENTOS) came to life. A group of Red Hat consumers, outraged at suddenly having to pay for RHEL, built a system to systematically download the SRPMS, rip out the Red Hat logos, replace them with CentOS logos, then build them and release them for download as a new 'free' version of RHEL. An unintended consequence of distributing open source software - Even though Red Hat had put for significant investment in time and money to create the product that is RHEL, they had no choice but to grin and bear it as CentOS directly undermined their market share with their own high quality work. The "other shoe" dropped when Oracle saw what they did with CentOS and followed their lead - downloading CentOS, ripping out the logos and replacing them with their own logos, creating Oracle Unbreakable Linux.
So Red Hat did all of the work, created a quality product, then was basically forced to watch another company benefit directly from their own hard work, without having to invest any time or effort to improve the product. In some ways this may have had a silver lining in that it theoretically forced Red Hat to ensure they provided a higher quality of support, a more robust developer community and to extend their portfolio... so the customer likely ended up with an overall better experience than they otherwise might have.
Red Hat has made multiple changes over the years in efforts to stop the bleeding. They ultimately took over both CentOS and Fedora and incorporated them into their development process for RHEL. They then modified the nature of these distributions to differentiate them from RHEL. Fedora has always been the bleeding edge, the place to see the absolute latest versions of everything, with a 6 month release cycle on new versions. As likely to melt down your computer as to show the latest shiny new widgets, Fedora has always been a dynamic, moving target, and that has only become more true after Red Hat brought it back in house. CentOS became the test bed for the next version of RHEL. More stable than Fedora, but no longer strictly just off-brand RHEL packages, it began deviating further from RHEL with each successive release. This very self-serving move had a couple of very specific impacts:
- Red Hat gained a testbed where they could get enterprise customers to try out new things before they get rolled into the enterprise product
- Oracle no longer had access to the exact same code that was in the current version of RHEL.
Red Hat took a further step in making Oracle's life difficult when they moved to CentOS stream. No more point releases. All of these steps had the desired effect of making CentOS a less desirable platform for true production shops or third party application developers, as it was just more volatile than many Enterprises could bear, while also likely improving the overall quality of RHEL.
To this point, Red Hat still made its SRPMS available to subscribers - and still do today, still abiding by the letter of the license. CentOS Stream's source RPMS are now the only publicly available sources for RedHat-like distributions, and these are Upstream of RHEL, not equivalent, meaning any distribution derived from CentOS will be an Upstream distribution, not a clone. The challenge this poses is that many things will go into CentOS which may never go into RHEL, or conversely, things that go into RHEL may never go into CentOS.
It is almost a certainty that the moves have been designed to make these 'clones' less desirable than the original. But keep in mind - through all of this, Red Hat is still leading the way in the community, contributing source to upstream projects, and they have now purchased at least five companies for their IP then turned around and given the IP to the community (Red Hat Virtualization, Gluster, Ceph, CloudForms, VDO and their API gateway).
Free as in 'Free Beer'?
Open Source has always been a home for people who believe strongly and deeply about the concepts embraced by the community. It takes a special person (or organization) to make the conscious decision to give away their intellectual property for the betterment of both the software and the community, rather than simply using it to make money. The reality is that it's possible to do both, as Google and Red Hat (and others) have demonstrated time and again. But never forget that these companies are made up of people. People who work hard, have families and whose families like to eat and have homes. The fact that their products are based on open source software does not mean that the software has no value, which is ultimately what we mean when we say a thing is 'free' (as in gratis) - it has no value. It actually has significant value. These companies who rail against Red Hat because they dislike having to pay for it readily admit that they value the products, that they choose them due to their quality, stability and support. They simply want all of that without having to pay for it. Or in some cases, they want to be able to redistribute it without paying Red Hat anything.
The GPL does not cover anything but the source code. It does not even guarantee that the source code will work. The reason Red Hat deserves to get paid is that they have added value to the open source files, made them trustworthy, stable, and provided additional services around them. The subscription fee is not for the software. Red Hat does not license you software. The only license associated with the source code is the development license. When you purchase Red Hat software entitlements, they come with their own End User License Agreement (EULA) which says that if you use it, you agree to pay for it.
The other aspect it's important to understand is that all of these Open Source products, whether it's RHEL or HortonWorks or one of the many enterprise variants of Google's Kubernetes, they are all comprised of many otherwise independent open source projects. Each of these components is like a building block for the final product. Individually, the projects were never intended to do what the vendor is doing with them. Each project's source is freely available from the project's website, so enterprising companies who have faith in their own skills are free to go download the source code for each of these building blocks and try to assemble them into a coherent product the way these vendors have.
This is really where these vendors add value for consumers and developers alike. They do the work to assemble the building blocks into a coherent, cohesive standalone project - then proceed to layer on security, hardening, support, repeatability etc. None of that was ever covered by the various development licenses of the building blocks. There is no legal basis for anyone to claim that they should have unfettered access to the resulting products gratis. There is no license requiring that the final product source be available for competitors to snap up and productize for free money.
The moral of the story is - if you use the product and your company depends on it, you should have no issues with paying for it. If you use a whole lot of it in a whole lot of places around the world, you should have no issues with paying in kind. Chances are, though, if you use that much, talk to your vendor representative. They are all coin operated, so the more you think you'll need to buy, the better the deal they are likely to offer.
It's easy to think that 'open source' should mean cheap, and it usually does mean 'cheaper than the alternative', but don't get drawn into the trap of thinking that means inexpensive, and don't blame the software for having a high price tag if you use a bunch of it. Even inexpensive things have high price tags when you buy them by the truckload. If you don't NEED them by the truckload, don't buy them by the truckload. If you DO need that much, you should be willing to pay for it. If not, you should probably re-evaluate the term 'need'.