Linux History, Philosophy, Distros & Licensing

Unix was created at Bell Labs by Ken Thompson and Dennis Ritchie starting in 1969. Before Unix, operating systems were expensive, proprietary, single-vendor systems — you bought a machine and got an OS tightly coupled to it, different on every machine, non-portable. Unix broke that pattern in three critical ways.

First: written in C. Thompson originally wrote Unix in assembly. Ritchie invented the C language partly for the purpose of rewriting Unix in it. This was radical: a high-level language (by 1970s standards) to write an OS meant you could port the OS to a new processor by rewriting a small C compiler, not the whole OS. This is why Unix (and Linux) could spread from PDP-11s to VAXes to SPARC to x86 to ARM without starting from scratch each time.

Second: the Unix philosophy. Doug McIlroy, one of the inventors of Unix pipes, articulated it: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. This philosophy is why grep, sort, awk, sed each do one thing, and why you can chain ls | grep '.c' | wc -l to count C files without writing a new program. It is a design philosophy about composability.

Third: the fork model of the kernel. Unix introduced the process model — fork() creates a child process, exec() replaces a process image with a new program. This abstraction is so powerful it survived unchanged into Linux. The shell you use today creates processes via fork() + exec() for every command you type, exactly as it did on a PDP-11 in 1971.

Unix fractured in the 1980s into BSD (Berkeley), System V (AT&T), HP-UX, AIX, SunOS/Solaris — all proprietary, all slightly incompatible. POSIX (IEEE Std 1003.1) was created in 1988 precisely to define a portable API across all these variants. Linux implements POSIX, which is why programs written for Solaris in the 1990s often compile unchanged on Linux today.

/* The Unix fork+exec model, unchanged since 1971 */
#include <unistd.h>
#include <sys/wait.h>
#include <stdio.h>

int main(void) {
    pid_t pid = fork();          /* duplicate this process */
    if (pid == 0) {
        /* child: replace ourselves with 'ls' */
        execlp("ls", "ls", "-l", NULL);
        perror("exec failed");   /* only reached on error */
        return 1;
    }
    /* parent: wait for child to finish */
    int status;
    waitpid(pid, &status, 0);
    printf("child exited with %d\n", WEXITSTATUS(status));
    return 0;
}

In 1983, Richard Stallman (rms) announced the GNU Project from MIT. GNU stands for 'GNU's Not Unix' — a recursive acronym that signals both lineage and independence. The backstory: Stallman had tried to get source code for a Xerox printer driver so he could fix an annoying bug. Xerox refused. This small incident crystallized something for him: software you cannot read, modify, or share is a form of social control, and technologists who build such software are complicit in restricting human freedom.

His manifesto was sweeping: he would write a complete Unix-like operating system — every tool, every library, every utility — and release it under a license that guaranteed it would remain free forever. Not 'free as in price' (though that too), but 'free as in freedom' — libre, not gratis. The four essential freedoms Stallman defined:

• Freedom 0: The freedom to run the program as you wish, for any purpose.
• Freedom 1: The freedom to study how the program works, and change it. (Requires source access.)
• Freedom 2: The freedom to redistribute copies so you can help others.
• Freedom 3: The freedom to distribute copies of your modified versions to others. (Requires source access.)

By 1991, GNU had produced: GCC (a C compiler that is still the dominant compiler for kernel work today), Bash (the shell you almost certainly use), the GNU C Library (glibc, which provides the POSIX API on Linux), Emacs, Make, Binutils (assembler, linker), and hundreds of other tools. The one missing piece was a working kernel. GNU Hurd, the planned kernel, was architecturally ambitious (a microkernel) and still years from production quality. This gap is exactly why Torvalds' 1991 kernel was significant: it filled the hole.

The Free Software Foundation (FSF), which Stallman founded in 1985, became the legal and organizational home for GNU, and the author of the licenses (GPL, LGPL, AGPL) that govern most of this software.

In 1991, Linus Torvalds was a 21-year-old computer science student at the University of Helsinki. He owned an Intel 386 PC and was frustrated that MINIX — a small Unix-like teaching OS written by Andrew Tanenbaum — was not free to modify and redistribute. He started writing his own kernel, initially just to learn how the 386's memory management and task-switching hardware worked.

On August 25, 1991, he posted to comp.os.minix:

'Hello everybody out there using minix — I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.'

The parenthetical 'won't be big and professional' is one of the most famously wrong predictions in software history.

Torvalds chose a monolithic kernel architecture (all kernel services run in a single address space) rather than a microkernel. Andrew Tanenbaum famously criticized this on the MINIX mailing list as architecturally obsolete. Torvalds defended his choice on grounds of performance — microkernels require message-passing overhead for every system call, and on real hardware in 1991, that was too slow. The debate (now called the Tanenbaum-Torvalds debate) is genuinely worth reading. The architectural choice has proved robust: Linux is still monolithic, though with loadable kernel modules.

Critical timeline:

• 1991-08: First public announcement (0.01 release, ~10,000 lines of C)
• 1991-09: Version 0.01 released (not yet compilable without hacks)
• 1992-01: Version 0.12 released under the GNU GPL v2 — the licensing decision that changed everything
• 1994-03: Linux 1.0 released (176,250 lines of code)
• 1996-06: Linux 2.0 (multi-processor support)
• Today: Linux 6.x (~36 million lines of code)

The jump from 10,000 lines to 36 million is not Torvalds typing — it is what happens when a GPLv2 codebase attracts tens of thousands of contributors worldwide. That growth rate is the open-source development model in action.

/* From Linux 0.01 (1991): the actual entry point for system calls.
 * Torvalds hand-wrote this x86 assembly. It uses software interrupt 0x80
 * — the same mechanism Linux still supports today for 32-bit compat. */

/* Modern equivalent: a minimal raw syscall in x86-64 asm (AT&T syntax) */
.global _start
_start:
    movq $1,   %rax   /* syscall number: write */
    movq $1,   %rdi   /* fd: stdout */
    leaq msg(%rip), %rsi  /* buf: pointer to message */
    movq $14,  %rdx   /* count: 14 bytes */
    syscall
    movq $60,  %rax   /* syscall number: exit */
    xorq %rdi, %rdi   /* status: 0 */
    syscall
msg:
    .ascii "Hello, kernel!\n"

This distinction is not pedantry — it is a load-bearing conceptual distinction.

The Linux kernel is a single C program (with some assembly) that manages hardware: it schedules processes, manages virtual memory, drives devices, handles interrupts, and provides the system call interface. By itself, the kernel does nothing useful for a user. You cannot run a shell inside a bare kernel. You cannot edit a file. You cannot compile code.

GNU/Linux (or a Linux distribution) is a complete operating system built by combining:

1. The Linux kernel
2. The GNU userspace (glibc, Bash, coreutils: ls, cat, grep, etc.)
3. Often: a package manager, init system, display server, desktop environment

When you type ls in a terminal, what happens is:

1. Bash (a GNU program) parses your command
2. Bash calls fork() then exec() (system calls into the Linux kernel)
3. The kernel loads /bin/ls from the filesystem (another kernel service)
4. ls calls getdents() (a system call) to read directory entries
5. ls calls write() (a system call) to print to the terminal
6. The kernel returns results each time

In this interaction, ls, bash, and glibc are GNU programs. The kernel is Linux. Every step that crosses the userspace/kernel boundary is Linux; everything in userspace is (predominantly) GNU.

Some purists (including Stallman and the FSF) insist on the name 'GNU/Linux' to give GNU credit for the 15 years of work that made the system usable before the kernel existed. Torvalds uses 'Linux'. In practice, the industry says 'Linux' for the whole stack. Be aware of this — it matters when discussing licensing, contribution norms, and credit.

/* Demonstration: every 'simple' shell operation crosses the kernel boundary.
 * strace shows the system calls. Run: strace ls 2>&1 | head -20
 * You will see execve(), openat(), getdents64(), write(), exit_group()
 * Each of those is a trap into the Linux kernel. */

/* A minimal C program that does what 'echo hello' does,
 * showing the exact system call layer explicitly: */
#include <unistd.h>
int main(void) {
    /* write() is a direct Linux system call wrapper in glibc */
    write(1, "hello\n", 6);
    return 0;
    /* _exit() is called by glibc's __libc_start_main, which
     * eventually does: syscall(SYS_exit_group, 0) */
}

The GPL is the legal mechanism that enforces free software. Linux is licensed under GPLv2 (with a 'syscall exception' that we will cover). Understanding it is essential before you touch kernel code.

Copyright and the problem it creates. By default, when you write software, copyright law gives you exclusive rights: no one can copy, modify, or distribute your work without your permission. Proprietary software exploits this: you can use the binary, but you cannot read or modify the source. The GPL is a copyright license — it uses copyright law to enforce the opposite outcome.

The copyleft mechanism. GPL grants you four freedoms (run, study, modify, redistribute), but attaches one condition: if you distribute a modified version of a GPLed program, you must distribute it under the same terms. You must provide the source code. You cannot add restrictions. This is the 'viral' or 'copyleft' property: freedom propagates forward. The name 'copyleft' is a pun — instead of 'all rights reserved', it is 'all rights reversed'.

GPLv2 specifically. Torvalds chose GPLv2 in January 1992 and has consistently refused to upgrade to GPLv3 (released 2007). He has cited specific GPLv3 provisions — particularly around 'Tivoization' (hardware locks that prevent modified software from running) and patent termination clauses — as going beyond his intent. The kernel is therefore covered by GPLv2 only, not 'GPLv2 or later'. This is why companies that ship Linux-based embedded devices (routers, TVs, cameras) are legally required to release their kernel modifications as source code.

The syscall exception. Running a program on Linux does not make that program a 'derivative work' of the kernel. The kernel explicitly includes a written exception stating that user-space programs that use the normal system call interface are not covered by the GPL. This is why proprietary software (Chrome, Slack, Zoom) can legally run on Linux without their source being required.

GPL vs. LGPL vs. MIT/BSD. The GNU C Library (glibc) uses the LGPL (Lesser GPL), which allows proprietary software to link against it dynamically without triggering copyleft. MIT and BSD licenses are 'permissive' — you can incorporate MIT-licensed code into a proprietary product without releasing your changes. Apache 2.0 is also permissive but includes patent grants.

/* How to check a file's license in the kernel source.
 * The kernel uses SPDX identifiers (a machine-readable license tag
 * in every source file). Example from a real kernel header: */

// SPDX-License-Identifier: GPL-2.0
/*
 * Linux kernel source uses this one-liner instead of the old
 * 15-line boilerplate. The SPDX system (spdx.org) maps short
 * identifiers to full license texts.
 *
 * Other identifiers you'll see:
 *   GPL-2.0-only        -- GPLv2, nothing else
 *   GPL-2.0-or-later    -- GPLv2+, can upgrade to v3
 *   (GPL-2.0 OR MIT)    -- dual-licensed
 *   MIT                 -- permissive, no copyleft
 */

A Linux distribution (distro) is a complete, packaged, installable operating system built on top of the Linux kernel plus a chosen set of userspace software. The same kernel source is the foundation for hundreds of different distros — from the ultra-minimal Alpine Linux (used in Docker containers) to the feature-rich Ubuntu Desktop.

Why distributions exist. The kernel developers do not ship an installer. They do not make decisions about which desktop environment to use, which package manager to run, or how to configure network services by default. Distributions make those decisions, test the combination, and provide a supported upgrade path.

The major family tree:

• Debian (1993): Emphasizes stability and free software. Uses .deb packages and apt. Parent of Ubuntu (2004), which is the most popular desktop/server distro and itself parents Linux Mint, Pop!_OS, and many others.
• Red Hat (1993): Emphasizes enterprise support. Uses .rpm packages. Red Hat Enterprise Linux (RHEL) is the dominant commercial Linux. Fedora is the community upstream. CentOS was a free RHEL rebuild (now CentOS Stream). AlmaLinux and Rocky Linux are the new community RHEL rebuilds.
• Slackware (1993): The oldest surviving distro. Emphasizes simplicity and manual configuration. Parent of SUSE Linux.
• Arch Linux (2002): Rolling release, minimalist, 'build it yourself' philosophy. Highly educational — installing Arch manually teaches you more about how Linux works than years of Ubuntu use.
• Gentoo (2000): Source-based distro; you compile everything from source. The USE flag system lets you compile exactly what you need. Extremely educational.
• Alpine Linux (2005): Musl libc + BusyBox instead of glibc + GNU coreutils. Tiny images (~5MB). The dominant base image for Docker containers.
• Android: Uses the Linux kernel, but replaces the GNU userspace entirely with a custom stack (Bionic libc, Dalvik/ART runtime). This is why Android is 'Linux' but not 'GNU/Linux'.

What a distro contributes vs. upstream kernel. Distros often carry patches on top of the upstream kernel for extended hardware support, security backports, or distro-specific features. A kernel version that Debian 12 ships is not bit-for-bit identical to what kernel.org releases. When you report a bug, it matters whether it reproduces on the upstream kernel or only on a distro kernel.

Long-Term Support (LTS) kernels. Kernel.org designates certain releases as LTS: they receive bug fixes and security backports for 2-6 years. Distros track LTS kernels for stability. The mainline kernel gets new features and moves fast.

# See which kernel version and distro you are running:
uname -r                  # kernel version, e.g. 6.8.0-45-generic
cat /etc/os-release       # distro name, version, ID

# See how your distro's kernel differs from a config perspective:
zcat /proc/config.gz 2>/dev/null | grep CONFIG_HZ
# or: cat /boot/config-$(uname -r) | grep CONFIG_HZ
# CONFIG_HZ=250 means the scheduler tick is 250 Hz (Ubuntu default)
# CONFIG_HZ=1000 is common on desktop-optimized builds

# Check SPDX license of a kernel source file (if you have kernel source):
head -3 /usr/src/linux/init/main.c
# Should show: // SPDX-License-Identifier: GPL-2.0-only

In 1997, Eric S. Raymond (ESR) published 'The Cathedral and the Bazaar' — an essay that analyzed two models of software development using Linux as the primary example.

The Cathedral model (traditional, proprietary): A small group of developers works in secret behind closed doors. Source is released only when ready. Bug reports are handled by a dedicated team. Development is planned and controlled. Release cycles are long. Examples: Microsoft Windows, pre-2000 Apple Mac OS.

The Bazaar model (Linux): Development is completely public from the start. Thousands of developers independently submit patches. Linus Torvalds famously said: 'Given enough eyeballs, all bugs are shallow' — Linus's Law. With enough people reading the code, every bug will look obvious to someone.

How Linux development actually works today. The kernel receives roughly 8-10 patches per hour, 24 hours a day. The workflow is:

1. A developer writes a patch and submits it to a subsystem mailing list (e.g., linux-kernel@vger.kernel.org for general patches, or netdev@vger.kernel.org for networking).
2. Subsystem maintainers review patches, request changes, and merge approved ones into their subsystem tree.
3. During the 'merge window' (roughly 2 weeks after a major release), subsystem trees are pulled into Linus Torvalds' main tree.
4. The 'rc' (release candidate) period follows: bug fixes only, for 6-8 weeks.
5. A new kernel is released roughly every 9-10 weeks.

The maintainer hierarchy. The MAINTAINERS file in the kernel source lists who is responsible for what. As of Linux 6.8, there are ~2000 named maintainers for ~2000 subsystems and drivers. Linus is at the top, with lieutenants like Greg Kroah-Hartman (stable kernel, driver core) and Andrew Morton (mm, general patches).

Governance is meritocratic but rough-edged. Linus is known for pointed email criticism of bad patches. There is a Code of Conduct (added 2018) and a Technical Advisory Board. But the ultimate gating mechanism is: does the patch make the kernel better? Code quality and correctness are the currency.

The numbers (as of 2024): ~4,000 developers contribute to each kernel release. The top 30 employers (Intel, Red Hat, Google, Samsung, etc.) account for ~85% of commits by employed developers. This is not altruism — these companies ship products that depend on Linux, so improving Linux is profitable.

# Explore the MAINTAINERS file yourself (requires kernel source):
# Download the kernel:
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.8.tar.xz
tar -xf linux-6.8.tar.xz

# Who maintains the TCP/IP networking stack?
grep -A 20 'NETWORKING \[GENERAL\]' linux-6.8/MAINTAINERS | head -20

# The get_maintainer.pl script tells you exactly who to CC on a patch:
perl linux-6.8/scripts/get_maintainer.pl linux-6.8/net/ipv4/tcp.c

This is the most architecturally important concept in this module — everything else in the roadmap builds on it.

Modern CPUs operate in at least two privilege levels (x86 calls them rings; ARM calls them exception levels):

• Ring 0 / EL1 (kernel mode): Code executing here can issue any instruction, access any memory, configure hardware, modify page tables. A bug here crashes the whole machine.
• Ring 3 / EL0 (user mode): Code here cannot directly access hardware, cannot touch another process's memory, cannot modify page tables. A crash here kills only your process — the rest of the system keeps running.

The Linux kernel runs in Ring 0. Every program you run — your browser, your shell, your text editor — runs in Ring 3.

System calls are the controlled bridge. When user-space code needs to do something privileged (open a file, allocate memory, send a packet), it makes a system call. On x86-64 Linux, the syscall instruction triggers a mode switch:

1. CPU saves user-space registers
2. CPU switches to Ring 0
3. CPU jumps to the kernel's syscall entry point (entry_64.S in the kernel source)
4. Kernel validates the syscall number and arguments
5. Kernel performs the operation
6. Kernel switches back to Ring 3 and returns the result

This boundary is why GNU and Linux are necessarily separate: GNU userspace runs in Ring 3, the Linux kernel runs in Ring 0. They communicate only through the system call interface. This is also why the syscall exception in the GPL makes sense: running in Ring 3 and calling the kernel via system calls is no more a 'derivative work' of the kernel than making a phone call is a derivative work of the telephone network.

The ABI contract. Linux makes a strong promise: the system call interface is stable. A binary compiled for Linux in 1995 will still run on a 2025 kernel if the architecture matches. Torvalds enforces this rule personally ('we do not break userspace'). This is why ancient binaries still work and why distributions can ship the same application binary for years.

/* Direct system call without going through glibc — demonstrates
 * the raw hardware interface. This is what glibc's write() wraps. */
#include <sys/syscall.h>  /* SYS_write = 1 on x86-64 */
#include <unistd.h>

long my_write(int fd, const void *buf, size_t count) {
    long ret;
    /* The 'syscall' instruction is the x86-64 gate into Ring 0.
     * Arguments: rdi=fd, rsi=buf, rdx=count, rax=syscall number */
    __asm__ volatile (
        "syscall"
        : "=a" (ret)
        : "0" (SYS_write), "D" ((long)fd),
          "S" (buf), "d" (count)
        : "rcx", "r11", "memory"
    );
    return ret;
}

int main(void) {
    my_write(1, "raw syscall\n", 12);
    return 0;
}

In 1998, Netscape announced it would release the source code to its browser. A group of hackers — including Eric S. Raymond and Bruce Perens — realized they needed a term to explain the development model to businesses without the political baggage of 'free software'. They coined 'open source'. The Open Source Initiative (OSI) was founded to certify licenses as open-source compatible.

The distinction matters. Richard Stallman has consistently opposed the term 'open source' because he believes it misses the point. For him, free software is an ethical position: software freedom is a moral right, like freedom of speech. 'Open source' reframes the same licenses as a practical development methodology — it is good for your business, it produces better software. Both can be true simultaneously, and the same licenses (GPL, MIT, Apache) are 'open source' and (usually) 'free software'. But the framing differs in ways that matter politically.

In practice:

• FSF / GNU perspective: Copyleft is essential. Permissive licenses allow proprietary relicensing, which is a loss of freedom. The goal is a world where all software is free.
• Open source / OSI perspective: Permissive licenses are fine. Getting source code into the open — even if companies can incorporate it into proprietary products — produces better software and is a practical win. Apache, MIT, BSD are excellent licenses.
• Linux kernel's position: GPLv2 (Torvalds' choice) enforces copyleft for kernel modifications, but the syscall exception means the ecosystem can include proprietary software. This is a pragmatic middle ground.

For you, as a kernel contributor: you will work under the GPL. Your patches will be GPL. The code you modify is GPL. Regardless of your philosophical position, you need to understand what the GPL requires and what it prohibits. Practically: do not copy code from a BSD or MIT project into the kernel without ensuring the license is compatible (MIT and BSD 2-clause are compatible with GPLv2; Apache 2.0 is not, due to patent clauses).

POSIX (Portable Operating System Interface) is a family of IEEE standards (IEEE Std 1003.1) that defines what a Unix-like OS must provide. It was created in 1988 specifically because the Unix fragmentation of the 1980s was making portability impossible.

POSIX defines:

• The C API for system calls: open(), read(), write(), fork(), exec(), pthread_create(), etc.
• Shell utilities and their behavior: ls, grep, awk, sed — their arguments and output formats
• The /etc directory structure, /usr hierarchy, etc. (partially — more is defined by the Filesystem Hierarchy Standard, FHS)

Linux is not officially POSIX-certified — certification costs money and requires specific test suites to pass. But Linux implements POSIX with very high fidelity. The Linux man pages (man 2 for system calls, man 3 for library functions) are largely organized by POSIX.

Why this matters for the kernel roadmap. When you write kernel code, you are implementing the other side of the POSIX API. When you write a new system call, you are extending the interface that POSIX defines. When you write a filesystem driver, it must implement the VFS (Virtual Filesystem Switch) operations that ultimately map to POSIX open/read/write/close semantics. POSIX is the contract that you are both reading and writing simultaneously as a kernel developer.

The Single Unix Specification (SUS) is a superset of POSIX, maintained by The Open Group, and is what 'Unix-certified' actually means today. macOS is SUS-certified. Linux is not, but is functionally compatible for most purposes. This is why most Unix programs compile on both.

# Check which POSIX version Linux claims on your system:
getconf _POSIX_VERSION   # outputs something like 200809
# 200809 = POSIX.1-2008

# See the POSIX system call documentation:
man 2 open   # the 'open' system call — POSIX-defined
man 3 printf # printf — defined by both POSIX and C standard

# All system calls are in section 2, library functions in section 3:
man 2 syscalls   # full list of Linux system calls