RTEMS | Adopt a Developer Certificate of Origin and an AI disclosure tag (#5657)

Fri Jul 24 00:10:52 UTC 2026

Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5657

## Background

RTEMS has no documented certification of contribution provenance. Concretely,
in the current tree:

- `Signed-off-by:` appears in 118 of the last 2000 commits on `main`.
- `Signed-off-by` appears nowhere in rtems-docs.
- "Developer Certificate of Origin" appears nowhere in rtems-docs.
- The repository contains no DCO file.

So the trailer is used by a minority of commits, is not required, and is not
documented. Where it is used it certifies nothing in writing, because the text
it would refer to does not exist in the project.

This came up in !1362, where reviewers asked for a declaration of AI usage.
The underlying question is provenance, and provenance is not an AI specific
problem. A contributor can just as easily submit code they do not have the
right to submit without any tool involved. The project has no instrument for
either case.

## Proposal

Adopt the Linux Foundation and Linux kernel model. The three parts only work
together: a disclosure tag without a DCO certifies nothing, and a DCO nobody
signs has no effect.

### 1. Add `DCO.txt`

Add the Developer Certificate of Origin 1.1 to the top of the repository,
copied verbatim from https://developercertificate.org/. It must not be
reworded. This is the same text used by the Linux kernel, Git, GCC and most
Linux Foundation projects.

### 2. Require `Signed-off-by:`

Require every commit to carry a `Signed-off-by:` trailer from a human
contributor, meaning that contributor certifies the DCO. Document this in the
RTEMS Software Engineering manual alongside the existing commit message
guidance.

This is what actually answers the licensing and copyright concern: the person
submitting the code asserts they have the right to submit it, whatever tools
they used to write it.

### 3. Adopt `Assisted-by:` for AI disclosure

Use the tag defined in the kernel's
`Documentation/process/coding-assistants.rst`:

    Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

For example:

    Assisted-by: Claude:claude-opus-4-8 claude-code

Two rules from that document carry over directly:

- AI agents must not add `Signed-off-by:` tags. Only a human can certify the
  DCO.
- Basic development tools are not listed. The tag is for coding assistants and
  specialised analysis tools, not for git, gcc, make or an editor.

The kernel considered `Co-developed-by:` and rejected it, because that tag
requires a paired `Signed-off-by:` which an AI cannot give. Choosing
"assisted" over "co-developed" is how the kernel states that an AI is not an
author. Adopting the same tag means RTEMS does not have to litigate that
question itself, and contributors who already work to kernel conventions do
not need a second set of habits.

## Why this shape

The Linux Foundation Generative AI Policy already covers projects like RTEMS
and states:

> Code or other content generated in whole or in part using AI tools can be
> contributed to Linux Foundation projects.

The obligation it places on the contributor is to confirm they have the
necessary rights and to provide attribution where third party material is
involved. A DCO sign-off is the standard expression of exactly that
obligation.

A structured one line tag also suits RTEMS better than a prose declaration.
For pre-qualification work, provenance metadata has to be traceable and
auditable per artifact. `git log --grep` over a fixed tag gives that. A
free form paragraph in a merge request description does not.

## Alternatives considered

Not every project chose this route. QEMU bans AI-assisted contributions
outright, and Gentoo and NetBSD have similarly restrictive policies. That is a
legitimate position and the project may prefer it.

The argument for the kernel model here is that RTEMS resembles the kernel more
than it resembles QEMU: it is DCO shaped in practice already, it has
safety-adjacent and qualification obligations that reward machine readable
provenance, and a large part of its contributor base works to kernel
conventions. A ban would also be unenforceable without the very certification
mechanism proposed above.

## References

- https://developercertificate.org/
- https://docs.kernel.org/process/coding-assistants.html
- https://www.linuxfoundation.org/legal/generative-ai
- !1362

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5657
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-7hk6uznmaaxxov39voq36ga28-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260724/fb2f7122/attachment-0001.htm>