A matter of license and lock-in
Recently, a few bits of newsworthy information hit the open source landscape. Separately, these pieces of news were not that glaring, but when you put them together something a bit more ominous comes into focus--something I never would have thought to be an issue within the open source community.
Before I get into this, I want to preface this by saying I am not usually one to cry foul, wolf, or squirrel! I prefer to let those pundits who make a living at gleaning the important bits out of the big bowl of alphabet soup and draw their own conclusions. But this time, I think it's important I chime in.
Yes, at this very moment I am donning my tin foil hat. Why? Because I think it's necessary. And with me sporting that shiny chapeau, understand every word you are about to read is conjecture.
I could be wrong. I could also be right.Only time will tell.
Let me explain.
SEE: 10 free alternatives to Microsoft Word and Excel (TechRepublic download)
This all starts out with Linus Torvalds coming out publicly to disavow ZFS. His justification was pretty straightforward, and can be summed up with this quote from his original statement:
"...there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd."
When you unpack this, it's very easy to conclude Torvalds' disdain for ZFS stems directly from his even greater disdain for Oracle. It's no secret that Torvalds has held Oracle in contempt for some time. Much of his criticism of Oracle stems from lawsuits and licenses. The beef he holds with Oracle is spread wide among the open source community. Mention "Oracle" to any long-time Linux/open source user and you'll be met by the same look of disgust.
In fact, Oracle has had a love/hate relationship with open source for some time. The company loves open source, except when they hate it. They bow down to open source when it serves them, and smack it down when it doesn't. In fact, at one point in time Oracle Senior Vice President Kenneth Glueck went at the US Government to say:
"There is no math that can justify open source from a cost perspective as the cost of support plus the opportunity cost of forgoing features, functions, automation and security overwhelm any presumed cost savings."
Because of statements and stances like this, it's not easy for the open source community to support a company like Oracle. So when the creator of Linux bashes the ZFS module from Oracle, it should be clear that this stems from years of bad blood.
And although I agree with Torvalds on the issue of Oracle, I'm not sure how I feel about his bashing ZFS. Why? The features found in ZFS are really needed for Linux. No other stable file system offers a similar feature set. Btrfs does, but it's been maligned as never having been ready for production systems. The problem with that is few have offered much proof for those cases, and plenty have offered cases where the file system works.
But enterprise businesses cannot trust a piece of technology without solid proof and backing.
That's where ZFS could find itself. With Canonical now doing serious work with ZFS, this open source file system could easily become the go-to for businesses who rely on Linux. I've worked with Canonical's ZFS implementation (in Ubuntu 19.10) and can attest that, even in this early stage, it is rock solid.
This one hits me right where it counts. Why? Because I've grown quite fond of the docker container runtime. It's easy to install and use, and many of the technologies I write about depend upon this software.
But Red Hat has other plans. The company decided--seemingly out of the blue--to drop support for the docker runtime engine. In place of docker came Podman. When trying to ascertain why Red Hat split with Docker, nothing came clear. Sure, I could easily draw the conclusion that Red Hat had grown tired of the security issues surrounding Docker and wanted to take matters in their own hands. There was also Red Hat's issue with "no big fat daemons." If that's the case, how do they justify their stance on systemd?
Here's where my tinfoil hat comes into play. Understand this is pure conjecture here and I have zero facts to back these claims up. However, after hearing what I have to say about the issue, you might find it possible to draw the same conclusion as I. Also understand that I have a great deal of respect for Red Hat. They were there when I first started my journey with Linux (way before the RHEL/Fedora split) and they'll be here well beyond the days when my fingers are no longer capable of typing words (shudder). Red Hat has done amazing things for Linux and open source, and will continue to do so.However, Red Hat is now owned by IBM. IBM was desperate to gain serious traction within the cloud. To do that, IBM needed Red Hat, so they purchased the company. Next, IBM had to score a bit of vendor lock-in. Using a tool like docker wouldn't give them that lock-in. However, if Red Hat developed and depended on their own container runtime, vendor lock-in was attainable.
Consider this: Installing the docker container runtime engine has been made seriously challenging by Red Hat. Because Red Hat locked containerd.io out of both RHEL and CentOS, getting docker installed into a reliable state has become an issue. Installing Podman, on the other hand, is simple. And because Podman is a near drop-in replacement for docker, it should be a no-brainer.
But notice I said "near drop-in replacement". Podman is not nearly as mature as docker. In fact, there are things Podman cannot do with making use of sudo (which, as you know, is a security issue within the realm of docker). So Red Hat has jettisoned a mature, known commodity for a less-mature, relatively unknown piece of software--without offering justification for the migration.
Don't get me wrong, Podman is a great tool for running a single container on a single host. But what about a swarm? And what about all of those dockerfiles that will no longer function with Podman? Administrators have spent a great deal of time tuning and perfecting those dockerfiles. Now? If you work with either RHEL or CentOS, you might be back at square one.
Until Red Hat offers up a sound justification for migrating from the docker container engine to Podman, there's going to be a lot of people sporting tinfoil hats. It comes with the territory of an always-connected world. And if it does turn out to be an IBM grab for vendor lock-in, there'll be a lot of admins migrating away from RHEL/CentOS to the likes of Ubuntu Server, SUSE/openSUSE, Debian, and more.
A need for unification
There will always be the Oracles and the IBMs on the fringe, waiting to stake their claim within the open source community. But it's important to not let companies shooting to ruin the GPL or bring about vendor lock-in take down important projects.Yes, Oracle has something to do with ZFS, but so does Canonical. And Red Hat may have their reasons for migrating to Podman, but that shouldn't reflect on Docker.
We, the open source community, need to be unified, not divided.