Debian splits its archive into main, contrib and non-free (and, on recent releases, non-free-firmware). What distinguishes these areas, and why does the split matter to a company deciding whether it can redistribute a Debian-based system?

## Where the split comes from Debian's Social Contract states which software the project considers part of Debian, and the **Debian Free Software Guidelines (DFSG)** are the licence test it applies. The DFSG require, among other things, free redistribution, availability of source, permission to modify and to distribute modified works, and no discrimination against persons, groups or fields of endeavour — including no clause forbidding commercial use. Licences are assessed against that list, and the result places a package into an archive *area*. ## The areas - **main** — the package's own licence satisfies the DFSG **and** it does not require anything outside main to build or run. This is Debian. When the project says a release contains a given number of packages, it means main. - **contrib** — the package itself is DFSG-free, but it depends on something that is not. Typical shapes: a free installer that fetches a proprietary binary at runtime, a free client for a proprietary service, or a free game engine that needs non-redistributable data files. - **non-free** — the package's own licence fails the DFSG. Common reasons are restrictions on modification, on commercial use, or on redistribution of modified versions. Debian carries these on its mirrors as a service to users, but they are explicitly not part of Debian. - **non-free-firmware** — introduced with Debian 12 (bookworm). Device firmware blobs, which are not DFSG-free but are required to make ordinary hardware such as wireless adapters work at all, were separated out of non-free into their own area so that the official installer could include them by default without enabling the whole of non-free. A useful way to remember contrib versus non-free: the question is about *this package's licence*, and contrib is the case where this package is fine but its world is not. ## How to tell what you have Each area is enabled explicitly in a sources entry — the words after the suite name are the areas: ``` deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware ``` A machine that lists only `main` cannot install anything from the other areas at all. On an installed system, a package's `Section` field is prefixed with the area for anything outside main (for example `non-free/net`), so an inventory of what you actually have is a query away rather than a guess. ## Why this is a procurement question, not a philosophy question The distinction turns concrete the moment you stop being an end user and start being a distributor — building an appliance image, an installable product, a customer-shipped virtual machine, or a base image handed to another organisation: - **Redistribution rights are uniform in main and per-package outside it.** Everything in main may be redistributed on the same broad terms. In non-free, one package may permit unlimited redistribution, another may forbid charging for it, another may forbid modification. "We ship Debian" is a statement you can defend for main and a statement you must audit per package outside it. - **Support commitments are strongest for main.** Debian's guarantees are written about the Debian system, and packages carried outside main do not attract the same commitment — security handling for non-free is best-effort and depends heavily on what upstream provides, since the project often cannot patch the source itself. - **Firmware is the one nearly everybody actually needs.** Refusing non-free entirely is a defensible policy right up to the point where a laptop's wireless or a server's network adapter does not come up. The bookworm-era separation exists precisely so that an organisation can take firmware without adopting the rest of non-free — a much easier policy to write and to enforce. - **Auditability is the real deliverable.** The value of the split to a legal or procurement team is that the boundary is machine-readable. You can state which areas your build enables, enumerate every installed package outside main, and attach the licence review to that short list, rather than reviewing thousands of packages. ## The answer that lands in an interview Say that main is the DFSG-clean, self-contained core and the only part Debian calls Debian; that contrib is free-but-dependent; that non-free is not free and needs per-package licence review; that firmware was split out in Debian 12 so installation media could be practical; and then say what it *costs you*: everything outside main is a package your organisation, not the project, has to justify redistributing.