Of forks and clones and package management - The Consensus

The Consensus Weekly<br>Get new deep dives, plus jobs and funding in software infrastructure, free in your inbox every week.Subscribelinux<br>Of forks and clones and package management<br>Package management is tough. When licenses change and forks appear, your package manager might decide another package is what you really want. And sometimes, it might even keep giving you a package you probably wouldn't have wanted.By Phil EatonJuly 11, 2026 Focus<br>You are getting early access to this article as a subscriber. Your support makes articles like this possible. Thank you.Open-source software simplifies distribution. While every distribution has their own policy that defines "open-source", it's often associated with licenses approved by the Open Source Initiative (OSI). When a license is not obviously open-source, even just packaging the software at all can become legally murky. Sometimes, like in the Steam case, distributions not only don’t package the software itself, they don’t even package the installer: they package a script that fetches the installer for the user.MongoDB#<br>In other cases, a project might get removed from the distribution entirely when it goes closed-source. For example, in 2018 MongoDB switched from AGPL (an OSI-approved license) to SSPL, a license they created. Mongo could not get SSPL approved by the OSI, and distros stopped packaging it. Today, Mongo itself is not in any major Linux distribution except for openSUSE and Arch user packages.Does this prevent users from installing the server? No. It just means Mongo must provide packages directly, which they do. Mature and large software usually wants you to install from them directly anyway. The Docker install guide has long said something like “make sure you first uninstall the version your distro provided”. Postgres isn’t so strongly worded, but they also encourage you to use their own packages.MySQL#<br>Compared to Mongo, MySQL is a weirder story. MySQL has been GPL for decades, an OSI-approved license. But some time after MariaDB forked MySQL, some distros switched the packaging so that when you installed mysql you actually got MariaDB. This was the case in Fedora from version 19 (2013) until version 40 (2024). It doesn’t entirely make sense that Fedora switched away from MySQL in the first place, since it continued to be developed and continued to be open-source. But it definitely makes sense to have reverted this behavior since MariaDB has diverged significantly from MySQL.In Debian, default-mysql-server points to MariaDB as well. mysql-server isn’t available except for in the unstable repository, where it’s failing packaging tests. But in Ubuntu, default-mysql-server is MySQL and mysql-server has been available for a while. In RHEL world, version 7 (2014) dropped MySQL packages completely and you could only install MariaDB. (Since that version is out of all the package indexers and I can’t easily install packages in a RHEL 7 or CentOS 7 machine, I can’t tell if yum install mysql-server got you MariaDB.)But again, this did not and does not mean you couldn’t install MySQL. You just had to set up MySQL’s own repositories. Which is still how you’d probably do it on any system today.Redis#<br>Redis followed Mongo when it changed from a BSD license to SSPL in 2024. But unlike Mongo there was a community fork, Valkey, that gained quick adoption. Within the year, Fedora 41 swapped out Redis for Valkey. When you install Redis on Fedora, to this day, you get Valkey. This in spite of the fact that Redis added back an OSI-approved license in 2025. Debian and Ubuntu have not followed suit, despite some sources online claiming otherwise. Redis remains Redis on Debian and Ubuntu.Redis is not available on RHEL10 or Rocky Linux 10, but Valkey is.Varnish#<br>This last case is particularly interesting because very few distros have picked it up. By 2026, due to a trademark dispute, the developers of Varnish Cache renamed Varnish to Vinyl while the legal entity behind “Varnish” retained the name.Development primarily continues on Vinyl, with Varnish as a downstream distribution. For example this Vinyl commit on March 5 paired with this Varnish commit on March 17.Both projects remain open-source. And Varnish does seem to have done some of their own feature development. But when people wanted the Varnish project they probably also wanted the developers and maintainers who worked on it. And they’re not working on “Varnish” anymore, they’re working on “Vinyl”.But almost no system even packages Vinyl at all right now except Arch, FreeBSD, and OpenBSD. And OpenBSD is the only one that has granted the Vinyl package the alias “Varnish”.The times they are a-changing#<br>In the production world of containers and immutable infrastructure I’m not sure this all means as much. Unlike distribution packages, container images are mostly published by the creators without input from the container registry. Docker does have its...