Guide on Your License

Copyleft

Mon, 01 Jan 0001 00:00:00 +0000

Copyleft is a licensing requirement that derivative works of a licensed work must be distributed under the same (or a compatible) licence. The term is a play on “copyright”: rather than reserving rights, copyleft uses copyright law to compel downstream sharing.

Licenses fall on a spectrum:

None (permissive)

No share-back requirement. MIT, Apache-2.0, BSD, ISC. Derivative works can be relicensed as anything, including proprietary. The trade-off: a proprietary fork can absorb your work without giving anything back.

Fair code and source-available licenses

Mon, 01 Jan 0001 00:00:00 +0000

Fair code is an informal term for licenses that are:

source-available (the code can be read and often modified),
free to use in most scenarios, but
restricted in at least one dimension that makes them incompatible with the Open Source Definition.

The most common restrictions:

No hosting as a service — you cannot offer the software as a managed service that competes with the licensor. Examples: SSPL, Elastic License 2.0, Confluent Community License.
Non-commercial — you cannot use the software commercially without a separate agreement. Examples: PolyForm Noncommercial, Commons Clause derivatives.
Field of use — the software cannot be used in a named industry or for a named purpose. Examples: some Hippocratic-style licenses.
Time-delayed conversion — restricted now, becomes open source automatically after a specified period. Example: Business Source License (BUSL).

Why not just use an OSI licence?

Venture-backed infrastructure companies discovered a pattern: they build a piece of open-source software (MongoDB, Elasticsearch, Redis), a cloud provider forks it and offers it as a managed service, and the cloud provider out-competes the original authors on distribution because they already run the data plane.

How to apply a licence

Mon, 01 Jan 0001 00:00:00 +0000

Picking a licence is half the work. Actually attaching it so it is discoverable, enforceable, and scannable by compliance tooling is the other half.

For a software repository

Add a LICENSE file at the root of the repository containing the full text of the chosen licence. Use the canonical text from the licence’s official source, not a paraphrase.
Fill in the copyright line if the licence template has one (MIT, BSD, Apache all do). Use the current year and the correct author or organisation name.

SPDX identifiers

Mon, 01 Jan 0001 00:00:00 +0000

SPDX is the Software Package Data Exchange — an open standard for communicating software bill-of-materials information, including licenses. Its most visible piece is the SPDX License List: a registry of short, unique identifiers for each license.

Examples:

MIT
Apache-2.0
GPL-3.0-only (or GPL-3.0-or-later)
BSD-3-Clause
CC-BY-4.0

SPDX identifiers in source files

Add a one-line header to the top of every source file:

// SPDX-License-Identifier: MIT

Tools including REUSE, licensee, and GitHub’s license detection understand these identifiers and will correctly attribute the file.