1.3. Licenses and the FHS

Let us say you release a browser. Good for you. Amazing. You publish the source tree with no license and no code headers, assume everyone will understand your intentions, and then act surprised when the situation becomes a mess. The first correction is important: without a license, other people do not receive permission to copy, modify, or redistribute your work. That does not protect you by magic; it mostly creates confusion, blocks legitimate reuse, and leaves everyone arguing about what is allowed.

A license is the part where you stop relying on vibes and state the legal terms plainly. It tells other people what they may do with your code, what obligations attach to redistribution, and what liability you are refusing to accept. If you want software to be usable by other people, licensing is not optional paperwork. It is the mechanism that makes distribution and reuse legally intelligible.

Copyleft

Copyleft licenses are licenses that preserve downstream freedoms by requiring certain redistributed derivative works to remain under the same license, or under terms that preserve the same rights. The GNU General Public License is the standard example. The simplified version many people remember is directionally right but incomplete: copyleft does not mean every modification must be published immediately. The obligation is usually triggered when the modified work is conveyed or distributed to others, not when it is used privately.

The GPL is therefore not simply “a license that forces any derived software to be released.” More accurately, it requires that recipients of a distributed derivative work receive the corresponding source code and the same GPL rights. That distinction matters. Private internal modifications are one thing. Distribution to other parties is another.

This book is intentionally avoiding strong copyleft in the userland where practical. That is a project policy choice, not a claim that copyleft is invalid or unworkable. Copyleft is effective at keeping code and modifications available to recipients. The tradeoff is that it imposes reciprocal conditions the project does not want as its default licensing posture.

Permissive and Weak Copyleft Licenses

The preferred licenses for this book are permissive licenses and, in limited cases, weak copyleft licenses. Permissive licenses generally allow reuse in proprietary and open source projects alike, subject to modest conditions such as preserving notices, disclaimers, or attribution text.

• The BSD licenses are acceptable. In practice this usually means the 2-clause or 3-clause BSD variants, which are short, permissive, and easy to satisfy.
• The MIT license is acceptable. It is one of the simplest permissive licenses in common use and is broadly compatible with mixed-source environments.
• The Apache License 2.0 is acceptable. It is permissive, includes an express patent grant, and is often preferable when patent language matters.
• The Mozilla Public License 2.0 may be acceptable in some cases. It is not a permissive license; it is a weak copyleft license with file-level reciprocity. That means modified MPL-covered files generally remain under the MPL when distributed, while larger combined works may use other licenses for separate files.
• The PostgreSQL license and ISC license would also fit the overall policy, even if they are not the main examples listed here.
• The SQLite blessing is usable as a public-domain style dedication, but it is unusual. Where legal certainty matters across jurisdictions, an established permissive license is often simpler to evaluate.

In short: BSD, MIT, and Apache are the default comfort zone. MPL is only acceptable when its file-level copyleft is understood and deliberately tolerated.

There is one explicit exception to the broader preference against copyleft software: the Linux kernel. The project is building a Linux system, so excluding the kernel on licensing grounds would reduce the exercise to a very elaborate refusal to finish the sentence. The kernel remains in scope, and its GPL obligations are accepted as part of using it.

The FHS

The Filesystem Hierarchy Standard attempts to define conventional locations for binaries, libraries, configuration files, variable data, temporary files, and other system components. Its purpose is predictability. A system that follows the FHS closely is easier for administrators, packages, and third-party tooling to reason about because file placement is less surprising.

This book is not committed to following the FHS strictly. The reason is straightforward: the project does not want to. That answer can be made more formal by saying the filesystem layout should serve the build and maintenance model of this system rather than satisfy a standard whose priorities are not automatically ours. The short version is still the accurate one.

That does not mean the layout will be random. It means the book reserves the right to choose directory structure deliberately, even when that structure diverges from FHS conventions. Compatibility concerns will still matter, especially where software expects particular paths, but the standard itself is not being treated as binding law.

Readers should therefore expect occasional departures from conventional directory placement when those departures make the system easier to understand, maintain, or bootstrap. Standards are useful tools. They are not obligations unless a project decides they are.