DCO, Signed-off-by & Documentation Contributions

The DCO is a short legal document — literally 280 words — that defines exactly what you are certifying when you add Signed-off-by to a commit. It was introduced to Linux in 2004 by Linus Torvalds and Andrew Morton in direct response to the SCO Group lawsuit, which threatened to unravel Linux by claiming that IBM had contributed code it did not own.

The document lives at Documentation/process/submitting-patches.rst and at https://developercertificate.org. It has four clauses (a through d):

• (a) The contribution was created in whole or in part by you, and you have the right to submit it under the open source license indicated in the file.
• (b) The contribution is based upon previous work that, to the best of your knowledge, is covered under an appropriate open source license, and you have the right under that license to submit that work with modifications under the same open source license.
• (c) The contribution was provided directly to you by some other person who certified (a), (b), or (d), and you have not modified it.
• (d) You understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information you submit with it, including your sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

The key insight: you are not transferring copyright. You retain ownership of your code. You are certifying that you have the right to license it under GPLv2, and that you are doing so. This is much weaker than a CLA, and intentionally so.

# The DCO full text (for reference — this lives at https://developercertificate.org)
# Developer Certificate of Origin Version 1.1
#
# Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
#
# Everyone is permitted to copy and distribute verbatim copies of this
# license document, but changing it is not allowed.

# Clause (a) — original work you have the right to submit
# Clause (b) — derivative of a compatible open-source work
# Clause (c) — work given to you by someone who certified (a)/(b)/(d)
# Clause (d) — you understand this is public and permanent

The Signed-off-by line is a Git commit trailer — a structured key: value pair that appears after a blank line at the end of the commit message. Git does not interpret it; it is pure convention, but it is a convention that the entire kernel toolchain (checkpatch.pl, get_maintainer.pl, patchwork, b4) understands and enforces.

The format is exactly:

Signed-off-by: Full Name <email@example.com>

Capitalization matters. There must be no space between Signed-off-by and the colon. The email must be a real address that you have authority over. The name should match a real person. Pseudonyms are technically allowed but discouraged.

What it is NOT: It is not a digital signature in the cryptographic sense (that is git commit -S, which uses GPG). It is a plain-text human-readable statement. Its legal weight comes from the fact that it was made publicly in a permanent record (the git history and mailing list archives), not from cryptography.

The chain of custody: When a patch flows through the tree, each person who passes it on adds their own Signed-off-by. A typical patch landing in Linus's tree might have:

1. The original author's Signed-off-by
2. A co-developer who tested and verified it
3. The subsystem maintainer who reviewed and accepted it
4. Sometimes Linus himself

Other related trailers you will see:

• Acked-by: — reviewer agrees with the change but did not author or integrate it
• Reviewed-by: — reviewer did a careful code review
• Reported-by: — credit to whoever filed the bug this fixes
• Tested-by: — someone who ran the code and confirmed behavior
• Co-developed-by: — when two people wrote the patch together (each must also have a Signed-off-by)
• Fixes: — links to the commit this patch fixes, by 12-char SHA + subject

# A realistic commit message with a full trailer block
# (this is what you write; git log --format=full shows it)

git log --oneline -1
# 4a6c8f2 docs: fix typo in memory-barriers.rst

git log -1 --format='%B'
# docs: fix typo in memory-barriers.rst
#
# "smp_mb()" was described as a "read" barrier in one paragraph
# but it is actually a full memory barrier. Correct the description
# and add a cross-reference to the barriers FAQ.
#
# Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
# Signed-off-by: Alice Developer <alice@example.com>

A Contributor License Agreement (CLA) is a contract under which a contributor grants the project owner additional rights beyond what the project license itself provides — typically the right to relicense the code, use it in proprietary products, or enforce patents on behalf of the project. Google, Apache, Eclipse, and many other large projects use CLAs.

Linux deliberately has no CLA. Understanding why requires understanding the kernel's governance model:

Copyright stays with contributors. Under the GPLv2, the Linux kernel can only ever be distributed under GPLv2 (or compatible licenses). There is no single entity that owns all of Linux and could decide to relicense it. If you contributed in 1994, your code is still under the exact terms you gave it. This creates a permanent, distributed constraint that protects the commons.

No copyright assignment. The Free Software Foundation, by contrast, requires copyright assignment for GNU projects — you sign over ownership to the FSF so they can enforce the GPL in court. Linux has no such mechanism. The Linux Foundation does not own Linux code. Linus Torvalds owns his personal contributions only.

The DCO as a lightweight alternative. The DCO achieves the one thing you actually need: a public, auditable record that each contributor had the right to contribute, and chose to do so under GPLv2. This is enough for legal purposes without imposing the friction of a CLA.

Practical implications for corporate contributors: If your employer owns the copyright to code you wrote at work (which is usually the case), you must certify under DCO clause (b) — that your employer has authorized the contribution. Many companies have internal open-source policies; if yours does not, you need explicit written permission before contributing work-time code to Linux. This is not paranoia; it is real intellectual property law.

Every contribution to the Linux kernel is licensed under GPLv2 ("GNU General Public License, version 2"). The key phrase is "only" — Linus has repeatedly stated that Linux is GPLv2 only, not "GPLv2 or later" like many other GNU projects. This has practical consequences:

What GPLv2 requires of contributions:

1. Source code must be available for any distributed binary.
2. Any modifications to GPLv2 code must also be GPLv2.
3. The license text must accompany distributions.

The "kernel exception" to copyleft. User-space programs that merely call kernel system calls via the standard C library are NOT derivative works. This is called the "syscall interface exception" and is why you can run proprietary software on Linux. However, code that runs inside the kernel (drivers, file systems, modules) must be GPLv2 (or, for modules, arguably dual-licensed — but this is contested territory).

Compatible licenses in the kernel. Some files in the kernel are dual-licensed (GPLv2 + MIT, GPLv2 + BSD, etc.) to allow reuse in firmware, bootloaders, or other contexts. This is allowed — the combination is still GPLv2 when distributed as part of Linux. You can see this in many header files that are shared between kernel and user space.

The MODULE_LICENSE macro. In a kernel module, you declare your license:

MODULE_LICENSE("GPL v2");

The kernel uses this at load time to mark the module as "tainted" if it is not a recognized free-software license. A TAINT_PROPRIETARY_MODULE flag prevents bug reporters from blaming the kernel for crashes in proprietary driver code.

/* A minimal kernel module showing license declarations */
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Alice Developer <alice@example.com>");
MODULE_DESCRIPTION("Minimal example module");
MODULE_VERSION("0.1");

static int __init hello_init(void)
{
    pr_info("hello: loaded\n");
    return 0;
}

static void __exit hello_exit(void)
{
    pr_info("hello: unloaded\n");
}

module_init(hello_init);
module_exit(hello_exit);

Historically, every source file in the Linux kernel had a sprawling copyright header: a multi-line block of GPL boilerplate, sometimes spanning 20+ lines, sometimes subtly different between files, and sometimes simply wrong due to copy-paste errors. This made automated license scanning unreliable and created legal uncertainty.

In 2017–2019, the kernel community undertook a massive migration to SPDX (Software Package Data Exchange) license identifiers. SPDX is a Linux Foundation project that defines a standardized, machine-readable shorthand for licenses. The result: every source file now starts with exactly one line:

// SPDX-License-Identifier: GPL-2.0-only

or for dual-licensed files:

// SPDX-License-Identifier: (GPL-2.0-only OR MIT)

Why this matters:

• License scanners (like FOSSology, ScanCode) can reliably identify the license of every file.
• Legal teams at companies using Linux can audit their distributions automatically.
• New contributors do not have to copy-paste a boilerplate block they do not understand.
• The SPDX identifier is a precise reference to the full license text, not a vague description.

The SPDX identifiers used in the kernel are defined at https://spdx.org/licenses/. The most common ones in the kernel:

• GPL-2.0-only — GPLv2, not "or later"
• GPL-2.0-or-later — GPLv2 or any later version
• (GPL-2.0-only OR MIT) — dual-licensed
• (GPL-2.0-only OR BSD-2-Clause) — common for user-space-shareable headers

When you write a new file for the kernel, you MUST include the SPDX identifier on the first line. The checkpatch.pl script will warn if it is missing. This is documented in Documentation/process/license-rules.rst.

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Example driver skeleton showing correct SPDX + copyright block.
 * The SPDX line replaces the old 15-line GPL boilerplate.
 *
 * Copyright (C) 2024 Alice Developer <alice@example.com>
 */

#include <linux/module.h>
/* ... rest of driver ... */

The Documentation/ subtree of the Linux kernel is a goldmine for first-time contributors. The reasons are practical and strategic:

Lower technical barrier. Fixing a typo, clarifying a confusing sentence, updating a stale file path, or adding an example to an API description requires understanding the concept being documented, not the entire kernel subsystem. You can make a meaningful improvement with a day of reading.

Identical process. The patch submission process — diff, cover letter (optional for small patches), mailing list, review, merge — is identical for documentation and code. You learn the real workflow without the risk of introducing a kernel regression.

High acceptance rate for quality work. Maintainers are busy. A patch that clearly improves documentation with correct grammar, accurate technical content, and a clean diff is almost always accepted. This is a real confidence-builder.

The Documentation/ maintainer is Jonathan Corbet (corbet@lwn.net). The subsystem mailing list is linux-doc@vger.kernel.org. To find the right maintainer for any file:

./scripts/get_maintainer.pl Documentation/process/submitting-patches.rst

ReStructuredText (RST). Kernel documentation is written in RST format and rendered via Sphinx. You will need to understand basic RST syntax: headings (underlines), code blocks (::), cross-references (:ref:, :doc:), and notes (.. note::).

Building the docs locally:

make htmldocs   # builds HTML in Documentation/output/
make pdfdocs    # builds PDFs (requires LaTeX)
make cleandocs  # clean up

Always build and preview before submitting a documentation patch. A broken RST structure is an easy mistake that reviewers will catch immediately.

# Finding documentation issues to fix — a practical workflow

# 1. Find files recently touched (stale docs often surround recent code changes)
git log --oneline --since='2 years ago' -- Documentation/ | head -20

# 2. Build the docs and look for warnings
make htmldocs 2>&1 | grep -i warning | head -30

# 3. Find the maintainer for a doc file before sending your patch
./scripts/get_maintainer.pl Documentation/admin-guide/kernel-parameters.txt

# 4. Check RST syntax with a quick Python check
python3 -m sphinx Documentation/ /tmp/kbuild-docs -b html -q 2>&1 | grep ERROR

The submission pipeline for a documentation patch is identical to a code patch. Here is the full sequence you will go through:

Step 1: Set up your Git identity. Your name and email in Git must match your Signed-off-by. This is non-negotiable.

git config --global user.name "Alice Developer"
git config --global user.email "alice@example.com"

Step 2: Create a topic branch.

git checkout -b doc-fix-memory-barriers origin/master

Step 3: Make the change, then stage and commit. The commit message must follow the kernel convention:

• First line: <subsystem>: <short description> (max 72 chars, imperative mood: "fix", not "fixed")
• Blank line
• Body: explain why this change is needed, what was wrong, and optionally what you changed. Do not just restate the diff.
• Blank line
• Trailers: Signed-off-by: last.

Step 4: Run checkpatch.

./scripts/checkpatch.pl --strict -g HEAD

Fix all errors; address warnings unless you have a good reason not to.

Step 5: Format the patch as an email.

git format-patch -1 --cover-letter  # for a single patch; omit --cover-letter
git format-patch -1

Step 6: Send via git send-email. This is the only acceptable way to submit patches to the kernel. Do not use GitHub PRs or attachments. git send-email preserves the exact whitespace and encoding that git am needs to apply the patch cleanly on the other end.

git send-email --to corbet@lwn.net --cc linux-doc@vger.kernel.org 0001-*.patch

Step 7: Respond to review. Reviewers will reply on the mailing list. If they request changes, make them, increment the version ([PATCH v2]), and resubmit with a changelog below --- in the patch body.

# Full patch submission walkthrough for a tiny doc fix

# 0. Clone and set up (do this once)
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git config user.name  "Alice Developer"
git config user.email "alice@example.com"

# 1. Find a documentation file to improve
grep -r "TODO\|FIXME\|XXX" Documentation/ --include='*.rst' | head -10

# 2. Create branch, edit, commit
git checkout -b my-doc-fix
# ... edit the file ...
git add Documentation/process/submitting-patches.rst
git commit  # editor opens; write your commit message here

# 3. The commit message you write (example)
# docs: clarify Signed-off-by requirements in submitting-patches
#
# The previous wording said contributors "may" add Signed-off-by,
# implying it is optional. In practice it is mandatory — patches
# without it are rejected. Update the language to reflect this.
#
# Signed-off-by: Alice Developer <alice@example.com>

# 4. Validate
./scripts/checkpatch.pl --strict -g HEAD

# 5. Find maintainers
./scripts/get_maintainer.pl Documentation/process/submitting-patches.rst

# 6. Format and send
git format-patch -1
git send-email \
  --to corbet@lwn.net \
  --cc linux-doc@vger.kernel.org \
  0001-docs-clarify-signed-off-by-requirements.patch

When a patch travels from contributor to subsystem maintainer to Linus, each person who carries it adds their own Signed-off-by. This creates a chain of custody — an auditable trail showing exactly who touched the patch and certified its provenance at each step.

Consider this realistic trailer block on a patch landing in mainline:

Signed-off-by: Alice Developer <alice@example.com>
Reviewed-by: Bob Reviewer <bob@kernel.org>
Signed-off-by: Carol Maintainer <carol@subsystem.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

What this tells you:

1. Alice wrote and submitted the patch, certifying DCO (a) or (b).
2. Bob reviewed it and agrees it is correct — Reviewed-by is a strong signal of quality.
3. Carol accepted it into her subsystem tree, certifying DCO (c) — she received it from Alice (who certified (a)).
4. Linus pulled Carol's tree and added his sign-off certifying that he received it from Carol (who certified (c)).

What breaks the chain: If Alice copied code from a proprietary project, her Signed-off-by would be fraudulent — she certified (a) or (b) without having the right to do so. This is exactly the scenario the DCO was designed to create accountability for. The chain does not prevent fraud, but it creates a permanent, public record that attributes it to a specific person.

Amending a patch to add your sign-off:

git commit --amend --signoff

This is the idiomatic way. The --signoff flag reads your user.name and user.email from git config and appends the correct trailer automatically.

For maintainers integrating patches: Tools like b4 (a modern patch management tool) automate the process of applying a patch from the mailing list and adding your sign-off in one step.

# Adding your sign-off when committing (always use this)
git commit --signoff
# or -s shorthand
git commit -s

# Amending the most recent commit to add a missing sign-off
git commit --amend --signoff

# Verifying the trailer is present
git log -1 --format='%B' | grep 'Signed-off-by'

# Using b4 to apply a patch from lore.kernel.org with your sign-off
pip install b4
b4 am <message-id> --add-my-sob
# b4 fetches the patch, checks the series, applies it, and adds your SOB

scripts/checkpatch.pl is a Perl script in the kernel tree that enforces coding style, commit message format, and common mistakes. Running it before submitting is not optional — it is expected. Patches that fail obvious checkpatch errors are often NAKed (rejected) without further review.

The script checks a wide variety of things:

• Trailing whitespace — every character counts in a patch
• Missing SPDX-License-Identifier in new files
• Missing Signed-off-by — it will warn if no SOB is found
• Line length — over 100 chars triggers a warning (the old 80-char limit is relaxed for documentation)
• Commit message format — "Subject: " prefix, proper tag format
• C coding style — spacing around operators, brace placement, use of pr_info vs printk
• Problematic patterns — BUG_ON vs WARN_ON, deprecated APIs

Three modes to know:

• checkpatch.pl file.patch — check a patch file
• checkpatch.pl -g HEAD — check the HEAD commit in git (most useful during development)
• checkpatch.pl -f file.c — check a source file directly (not a patch)

The --strict flag enables additional checks beyond the mandatory ones. Many maintainers require no --strict warnings for documentation patches.

Interpreting output: Each finding is tagged ERROR, WARNING, or CHECK. ERROR means "this will almost certainly be rejected." WARNING means "you should fix this unless you have a reason." CHECK means "consider this."

ERROR: Missing Signed-off-by: line(s)
WARNING: line over 80 characters
CHECK: Prefer pr_info to printk

# Run checkpatch on your latest commit — do this before every send
./scripts/checkpatch.pl --strict -g HEAD

# Run on a formatted patch file
git format-patch -1
./scripts/checkpatch.pl --strict 0001-my-fix.patch

# Run on a source file directly (useful when writing new code)
./scripts/checkpatch.pl -f --strict drivers/mydriver/myfile.c

# Example output you want to see:
# total: 0 errors, 0 warnings, 0 checks, 47 lines checked
# 
# Your patch has no obvious style problems and is ready for submission.

The Linux kernel is developed entirely over email. There is no GitHub PR, no Gerrit review, no Jira ticket. This is a cultural and technical choice — email is decentralized, archivable, searchable, and works with any tool. Understanding the mailing list infrastructure is essential.

Key lists:

• linux-kernel@vger.kernel.org (LKML) — the main list, very high volume (hundreds of messages/day). Do not send patches here unless specifically instructed; send to subsystem lists.
• linux-doc@vger.kernel.org — documentation patches
• Each subsystem has its own list (e.g., linux-mm@kvack.org for memory management, netdev@vger.kernel.org for networking)

Patchwork (https://patchwork.kernel.org) — a web interface that tracks patches submitted to mailing lists. When your patch is accepted, it moves through states: New → Under Review → Accepted (or Rejected). You can follow your patch's fate here.

lore.kernel.org — the authoritative, permanent archive of all kernel mailing list traffic. Every message has a stable URL of the form https://lore.kernel.org/linux-doc/<message-id>/. When you refer to a previous discussion in a commit message or email, link here.

Responding to review: Always reply inline (not top-posting). Address each reviewer comment directly. If you disagree, explain why politely and technically. If you agree and will fix it, say so. Reviewers are volunteers giving their time; treat them accordingly.

Mailing list etiquette rules:

• Plain text only (no HTML email)
• No attachments (patch is inline in the email)
• Reply to the correct thread
• Keep Cc list tight — add people listed by get_maintainer.pl, do not mass-Cc random maintainers

# Configure git send-email (do this once)
git config --global sendemail.smtpserver smtp.example.com
git config --global sendemail.smtpuser alice@example.com
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserverport 587

# Dry run to see what would be sent without actually sending
git send-email --dry-run --to corbet@lwn.net 0001-*.patch

# The b4 tool makes mailing list workflow much easier
# Install: pip install b4
# Retrieve a patch series by message ID from lore.kernel.org
b4 am 20231015123456.12345-1-alice@example.com

# Check patch status on patchwork
# Visit: https://patchwork.kernel.org/project/linux-doc/list/