Licensing and Distro Families

Kernel vs. Distribution covers what technically differs between distributions. This covers two things that aren't technical at all, but explain a lot about why the ecosystem looks the way it does: the legal terms code is shared under, and which distributions are actually derivatives of which others.

Open source licenses

Not all open source licenses grant the same freedoms, and the difference matters in practice - not just legally.

GPL (GNU General Public License) - the Linux kernel's own license, and the one behind much of the GNU userland (bash, coreutils, gcc). Copyleft: if you distribute a modified version, you must make that version's source available under the same license too. This is deliberate - it's designed to keep improvements to GPL software flowing back into the open, rather than letting a company take the code proprietary. See What Is Linux? for how this shaped the kernel's early growth.

MIT / BSD - permissive: do essentially anything with the code, including using it in closed-source proprietary software, as long as the original copyright notice is kept. Much of the modern web and cloud tooling ecosystem (Node.js, Redis historically, most Go projects) uses one of these.

Apache 2.0 - permissive like MIT/BSD, with an added explicit patent grant: contributors license any patents they hold covering their contribution, reducing the risk of a later patent claim against users of the code. Common in larger corporate-backed projects (Kubernetes, Android's own code, much of the Apache Software Foundation's catalog).

The practical question a license answers: can you fork it, modify it, and redistribute your changes - and if you do, are you required to share your modifications too? A permissively-licensed tool can be quietly forked into a closed product; a copyleft one generally can't be, which is a deliberate choice by the original author about what kind of ecosystem they want to encourage.

Distro families

Most distributions aren't built from scratch - they're derived from an existing one, inheriting its package format and much of its underlying system in the process.

Debian family - Debian itself, famous for stability and a strict free-software policy, is the base for Ubuntu (which adds a faster release cadence, commercial backing from Canonical, and broader default hardware/driver support), which is in turn the base for Linux Mint, Pop!_OS, and elementary OS. All share .deb packages and APT (see APT and dpkg) - a .deb file or PPA built for Ubuntu very often installs cleanly on Mint or Pop!_OS too, since they track Ubuntu's own package versions closely.

Red Hat family - Fedora is Red Hat's fast-moving upstream testing ground, where features land before eventually reaching RHEL (Red Hat Enterprise Linux), the stable, commercially-supported downstream release. CentOS Stream, Rocky Linux, and AlmaLinux sit adjacent to RHEL - free, binary-compatible (or near enough) alternatives that emerged after CentOS's original role as a free RHEL rebuild was discontinued in favor of CentOS Stream tracking just ahead of RHEL instead. All use .rpm packages and DNF (see DNF and RPM).

Arch family - Arch Linux itself: rolling-release, minimal, DIY-oriented, using pacman (see Pacman). Manjaro and EndeavourOS build a more approachable, pre-configured installation experience on top of Arch's package format and tooling, trading some of Arch's "you configure everything yourself" philosophy for a gentler on-ramp - EndeavourOS pulls packages straight from Arch's own repositories, while Manjaro maintains its own separate, delayed-by-design repositories (holding packages back for additional testing) rather than tracking Arch's directly.

Independent - openSUSE, Slackware, Gentoo, and Void aren't derivatives of any of the above, each with their own package tooling and philosophy (Gentoo notably compiles packages from source by default rather than distributing binaries, for instance).

Why lineage matters practically

• A guide, PPA, or .deb written for Ubuntu very often works unmodified (or with minor version differences) on Mint or Pop!_OS, precisely because they share a package base - but the same guide usually needs translating for Fedora or Arch, which don't.
• "Which distro should I use" is mostly a question of which family's release philosophy and package availability fits - Debian's stability, Arch's currency, Fedora's middle ground - not a fundamentally different operating system underneath, per Kernel vs. Distribution.
• Knowing a distribution's lineage is often the fastest way to guess whether an unfamiliar command, config file location, or package name will match what you already know from a different distro in the same family.