Why option `-s` for `git commit` makes no sense

August 8, 2026

In practice the Sign-Off-By: text in commit messages is always used to transfer copyrights. The “right to submit” does not exist, as long as there are no consequences when the right is violated. OSS projects should keep a list of proposed changes, whose only problem is the lack of Sign-off-by line.

git commit -s inserts particular text in the commit message: Sign-off-by: email-address. According to the documentation of git commit the meaning of that line depends on the particular project:

-s
–signoff
Add a Signed-off-by trailer by the committer at the end of the commit log message. The meaning of a signoff depends on the project to which you’re committing. For example, it may certify that the committer has the rights to submit the work under the project’s license or agrees to some contributor representation, such as a Developer Certificate of Origin. (See https://developercertificate.org for the one used by the Linux kernel and Git projects.) Consult the documentation or leadership of the project to which you’re contributing to understand how the signoffs are used in that project.

In practice the Sign-Off-By line is always supposed to indicate that the submitter owns the copyright (right to submit) for the creative work, changeset, patch, and the copyright is transferred to the project, towards which the patch was addressed.

The copyright appears, when some patchset is published, it is in general attached to the person who published it, and the copyright expires with the death of the person, when there are no heirs.

When a published patch fixes a bug, the publisher does not insert a Signed-off-by: line, and a project insists to accept only changes with Signed-off-line:, then the publisher of the patch can effectively prevent anybody else from fixing that bug. There are nuances here, as when the bug is eventually fixed in a completely different way, then there are no copyright violations, but sometimes there is only one reasonable way to fix a bug. If in such a case somebody published a fix without Signed-off-line:, then nobody is authorized to fix the bug in a very similar way, without violating copyrights, until the publisher dies.

Sometimes published changes consist only of deleting something, like deadcode, no-ops. Can deleted code be copyrighted? Some people say “yes”. This is insane!

Having one person, who publishes a patch without Signed-Off-By line, another person who adds a Signed-Off-By line to the very same published change, and then the latter change is integrated in the upstream source code (because it has Signed-Off-By line), is nonsense. The copyright still belongs to the person who published the change, irrespective of records in the history of the source code. In a similar discussion elsewhere a pragmatical approach was taken: https://github.com/eclipse-xtext/xtext/issues/3687.

If a project insists that some text is inserted in contributions, like Brum-Brum, or some really very long text, people will insert the text in order to make/see progress. It does not mean they have read the rationale why adding Brum-Brum is required for that project; it does not mean they understand the language, in which the rationale is written, sufficiently good. The last argument also implies that piiple who donot anderstand the lenguage of the agriment sufisiently gut canot publish objection in the wery same lenguage that they see zero husage in inserting Signed-Off-By/Brum-Brum linez. From people, who do not understand English sufficiently good to interpret contribution agreements in open-source software, cannot be expected to admit this fact.

Some people are paid to insert Signed-Off-By lines in open source software, while others are for exactly the same work not paid. If I am paid for the sole work to insert that line, in order for something to make progress, I will be willing to insert it, too, in order to receive the money.

Insisting on Signed-Off-By: line can lead to inclusion of additional text in the version history: https://github.com/podman-container-tools/podman/commit/056917c223f054bd0b4526fce0800258a410cd68.

No-Discussion at https://lore.kernel.org/git/3b7ac61c368f5b0f188929862a451b9944879567.camel@aegee.org/.

The costs of adding a sign-off-by line

Eventually I decided to offer adding the Sign-Off-By: my-email-address line, or the process of agreeing on any terms in open-source software, as a commercial service, which costs 0.50 Euro. The service fee is to be paid to account IBAN CZ70 5500 0000 0016 1831 3003, BIC RZBCCZPPXXX. The subject of the transaction can spell that the donor should be spelled next to the Sign-Off-By line.

Publishing proposed changes for code in suitable format is not covered by the fee. I also have no problem, if somebody copies my changes and adds a Sign-Off-By line, as long as I do not add the line.

The Developer Certificate of Origin

The Developer Certificate of Origin, usually implied by the Sign-Off-By: line, has this content:

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.

Developer’s Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

The aforementioned “right to submit” contains “right”. “Right” means that if something does happen, penalties are paid, until the reasons why the right is violated are resolved. Depending on the context “right” can mean “if something does not happen”. Without sanctions, there is no “right” that something will happen, but “happenstance”.

In case of infringements of the “right to submit” there are no consequences, so the right does not exist. When patches are proposed for inclusion in open source software, for the submitter there are no consequences, when the submitter has no “right to submit”, and the submitter states s/he has “the right to submit”. So in open source software changes are proposed, not because the submitter has ”the right to submit”, but by happenstance, coincidence, occasion.

Keeping track of inadmissible changes

Open source software projects should keep a list of changes, which are on their own good, but are inadmissible, as they lack the Sign-Off-By line. This way, when a user wants to have a particular change, the user can just copy from the list the proposed (by somebody else) change, add itself in a Sign-Off-By line, and propose again the code changes. This way the same code change will be made eligible.

The action of taking ready changes, adding a Sign-Off-By line, and resubmitting the proposal, can be used by novice developers to get a feeling how proposing changes in open source software works.

In the light of current Artificial Intelligence developments, an agent could be created, which takes the items from the list, adds a Sign-Off-By line and submits the changes.