On Tue, May 20, 2025 at 10:06 AM Ghanshyam Maan <gmaan@ghanshyammann.com> wrote:

---- On Mon, 19 May 2025 23:54:48 -0700 Thierry Carrez <thierry@openstack.org> wrote ---

...

Hi,

It's worth noting that back in 2014, the TC already voted on a resolution asking to move all CLAs to DCO:

"The OpenStack Technical Committee, representing the developer community, requests that the Board of Directors consider implementing the Developer Certificate of Origin (DCO) as the Contributor License Agreement (CLA) for the OpenStack project. [...]"

https://governance.openstack.org/tc/resolutions/20140909-cla.html

So this is more of a check to see if that resolution still holds :)

++, We have not overridden this resolution of not using DCO, but as this is too old a resolution, maybe we can propose/confirm the same with a new resolution.

Pursuant to today's TC meeting [1], I've raised a resolution here: https://review.opendev.org/c/openstack/governance/+/950463 Please feel free to review. The main concern expressed at today's meeting was about the implications of a quick change. Even if we always wanted this, the timeline to change everything is short (June 1st is 10 days from now). Many companies have formal policies regarding open-source contributions. After we inform them, they may need to re-engage their legal teams to discuss the effect of this change and adapt. It might end up delaying contributions. While the technical implementation/enforcement of DCO in Gerrit seems straightforward, the "human component" of communication and policy adjustment seems complex.

-gmaan

...

Thierry Carrez (ttx)

Jonathan Bryce wrote:

...

Hi everyone,

I wanted to flag a recent message on the Foundation mailing list about the possibility to move OpenInfra projects from using the Contributor License Agreement (CLA) to the Developer Certificate of Origin (DCO) [1].

This change would be part of the broader transition into the Linux Foundation and could take effect starting June 1, 2025. It’s something the Board has supported for newer projects, and now existing projects like OpenStack have the opportunity to make the switch as well.

I’m happy to join the TC meeting this week to discuss.

Thanks,

Jonathan

1. https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/thr...

On 20/05/2025 21:58, Goutham Pacha Ravi wrote:

On Tue, May 20, 2025 at 1:58 PM Goutham Pacha Ravi <gouthampravi@gmail.com> wrote:

...

On Tue, May 20, 2025 at 10:06 AM Ghanshyam Maan <gmaan@ghanshyammann.com> wrote:

...

---- On Mon, 19 May 2025 23:54:48 -0700 Thierry Carrez <thierry@openstack.org> wrote ---

...

Hi,

It's worth noting that back in 2014, the TC already voted on a resolution asking to move all CLAs to DCO:

"The OpenStack Technical Committee, representing the developer community, requests that the Board of Directors consider implementing the Developer Certificate of Origin (DCO) as the Contributor License Agreement (CLA) for the OpenStack project. [...]"

https://governance.openstack.org/tc/resolutions/20140909-cla.html

So this is more of a check to see if that resolution still holds :)

++, We have not overridden this resolution of not using DCO, but as this is too old a resolution, maybe we can propose/confirm the same with a new resolution. Pursuant to today's TC meeting [1], I've raised a resolution here: https://review.opendev.org/c/openstack/governance/+/950463 Please feel free to review.

The main concern expressed at today's meeting was about the implications of a quick change. Even if we always wanted this, the timeline to change everything is short (June 1st is 10 days from now). Many companies have formal policies regarding open-source contributions. After we inform them, they may need to re-engage their legal teams to discuss the effect of this change and adapt. It might end up delaying contributions.

10 days seams unlikely a more realistic goal is probably by the end of this cycle. i.e. have it take effect formally form the start of 2026.1 development cycle. the infra to support that and communication can happen on a shorter timeline but a hard switch over by june 1st seam hard.

...

While the technical implementation/enforcement of DCO in Gerrit seems straightforward, the "human component" of communication and policy adjustment seems complex.

correct me if im wrong but the main change we need to enforce that all commit would have signed-off-by going forward to signify that it was commit under the DCO. if we enforce it at the gerrit level then that would also require the bot proposed patches to be updated. That would also mean updating all open gerrit patches... which we can do but that will take time and muscel memory is also a factor.

(apologies hit send too soon): [1] https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.log.html

...

...

-gmaan

...

Thierry Carrez (ttx)

Jonathan Bryce wrote:

...

Hi everyone,

I wanted to flag a recent message on the Foundation mailing list about the possibility to move OpenInfra projects from using the Contributor License Agreement (CLA) to the Developer Certificate of Origin (DCO) [1].

This change would be part of the broader transition into the Linux Foundation and could take effect starting June 1, 2025. It’s something the Board has supported for newer projects, and now existing projects like OpenStack have the opportunity to make the switch as well.

I’m happy to join the TC meeting this week to discuss.

Thanks,

Jonathan

1. https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/thr...

If you're inclined to use the UI, you'll need to first edit the commit message, and add a "Signed-off-by" with your name and email, and then hit the "Rebase" button.

That is actually interesting point you raised. Correct me, but I think this is an option, only if you are rebasing your own patch. But what is the course of actions if a project maintainer wants or needs to rebase the patch proposed by contributor who is not on in contact or does not really want (or can) to add sign off, but the patch is valid and valuable? On Thu, 22 May 2025, 00:29 Goutham Pacha Ravi, <gouthampravi@gmail.com> wrote:

On Tue, May 20, 2025 at 5:52 PM Sean Mooney <smooney@redhat.com> wrote:

...

On 20/05/2025 21:58, Goutham Pacha Ravi wrote:

...

On Tue, May 20, 2025 at 1:58 PM Goutham Pacha Ravi <gouthampravi@gmail.com> wrote:

...

On Tue, May 20, 2025 at 10:06 AM Ghanshyam Maan <

...

...

...

...

---- On Mon, 19 May 2025 23:54:48 -0700 Thierry Carrez <

...

...

...

...

...

Hi,

It's worth noting that back in 2014, the TC already voted on a resolution asking to move all CLAs to DCO:

"The OpenStack Technical Committee, representing the developer community, requests that the Board of Directors consider implementing the Developer Certificate of Origin (DCO) as the Contributor License Agreement (CLA) for the OpenStack project. [...]"

https://governance.openstack.org/tc/resolutions/20140909-cla.html

...

So this is more of a check to see if that resolution still holds

:)

++, We have not overridden this resolution of not using DCO, but as

gmaan@ghanshyammann.com> wrote: thierry@openstack.org> wrote --- this is too old a resolution,

...

...

...

...

maybe we can propose/confirm the same with a new resolution. Pursuant to today's TC meeting [1], I've raised a resolution here: https://review.opendev.org/c/openstack/governance/+/950463 Please feel free to review.

The main concern expressed at today's meeting was about the implications of a quick change. Even if we always wanted this, the timeline to change everything is short (June 1st is 10 days from now). Many companies have formal policies regarding open-source contributions. After we inform them, they may need to re-engage their legal teams to discuss the effect of this change and adapt. It might end up delaying contributions.

10 days seams unlikely a more realistic goal is probably by the end of this cycle.

+1

...

i.e. have it take effect formally form the start of 2026.1 development cycle.

the infra to support that and communication can happen on a shorter timeline but

a hard switch over by june 1st seam hard.

We discussed this some more on the #openstack-tc channel [2] and on the gerrit change itself. The new proposal is to require the DCO from July 1st 2025. It isn't set in stone, Jonathan will follow up with the OpenInfra Foundation legal team.

...

...

...

While the technical implementation/enforcement of DCO in Gerrit seems straightforward, the "human component" of communication and policy adjustment seems complex.

correct me if im wrong but the main change we need to enforce that all commit would have signed-off-by going forward to signify that it was commit under the DCO.

this is correct. To follow DCO, all commits will require a "Signed-off-by" comment. This is required from the original committer as well as anyone that modifies a Gerrit change by submitting new commits [3]

...

if we enforce it at the gerrit level then that would also require the bot proposed patches to be updated. That would also mean updating all open gerrit patches... which we can do but that will take time and muscel memory is also a factor.

great point on bot proposed changes. Note that we'll not _need_ to update anything on gerrit to add the "Signed-off-by" line. This needs to be done only on new commits. You could add a new commit to an existing change by amending a previous commit (this includes rebases) - when we begin enforcing DCO compliance, your new commit will need "Signed-off-by" in the commit message.

Unfortunately, this means that, on the Web UI, you cannot hit a button to "Rebase" a change that doesn't have "Signed-off-by" in the commit message. If you're inclined to use the UI, you'll need to first edit the commit message, and add a "Signed-off-by" with your name and email, and then hit the "Rebase" button. Hopefully this pain is short term.

Jeremy Stanley helped set up an experiment on DCO enforcement on the opendev/sandbox repository on https://review.opendev.org. If you'd like to play around, please do so before EOD on Friday, May 23rd 2025. As a maintainer, I found this super useful to predict the contributor experience/pain points.

On enforcement, if you commit without "Signed-off-by", you should see an error message similar to:

"Could not perform action: not Signed-off-by author/committer/uploader in message footer" on the UI or ! [remote rejected] HEAD -> refs/for/master (commit: not Signed-off-by author/committer/uploader in message footer) in the git-review CLI

[2] https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2025-05... <https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2025-05-21.log.html#openstack-tc.2025-05-21.log.html%23t2025-05-21T16:01:20>

...

...

(apologies hit send too soon): [1]

...

...

...

...

-gmaan

...

Thierry Carrez (ttx)

Jonathan Bryce wrote: > Hi everyone, > > I wanted to flag a recent message on the Foundation mailing

...

...

...

...

...

> > This change would be part of the broader transition into the Linux Foundation and could take effect starting June 1, 2025. It’s something the Board has supported for newer projects, and now existing

https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.log.html list about the possibility to move OpenInfra projects from using the Contributor License Agreement (CLA) to the Developer Certificate of Origin (DCO) [1]. projects like OpenStack have the opportunity to make the switch as well.

...

...

...

...

...

> > I’m happy to join the TC meeting this week to discuss. > > Thanks, > > Jonathan > > 1. https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/thr...

Well, I'd say we totally need to have a lawyer input here, as while (C) of DCO [1] does cover rebases, I am not completely sure if signing CLA is counted as meeting (A) of DCO. As I read "by some other person who certified", as they should be having DCO as well. But I can easily assume that CLA may count here as well. We just need a clarification on such case, imo. [1] https://developercertificate.org/ On Thu, 22 May 2025, 08:04 Goutham Pacha Ravi, <gouthampravi@gmail.com> wrote:

On Wed, May 21, 2025 at 10:20 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

...

...

If you're inclined to use the UI, you'll need to first edit the commit message, and add a "Signed-off-by" with your name and email, and then hit the "Rebase" button.

That is actually interesting point you raised. Correct me, but I think

this is an option, only if you are rebasing your own patch.

...

But what is the course of actions if a project maintainer wants or needs

to rebase the patch proposed by contributor who is not on in contact or does not really want (or can) to add sign off, but the patch is valid and valuable?

My understanding is that the original contributor adhered to the ICLA, and their contribution made prior to the DCO enforcement date is acceptable as is. Further edits are made by others and they must follow the DCO.

On Thu, May 22, 2025, at 8:00 AM, Clark Boylan wrote:

On Wed, May 21, 2025, at 11:22 PM, Dmitriy Rabotyagov wrote:

...

Well, I'd say we totally need to have a lawyer input here, as while (C) of DCO [1] does cover rebases, I am not completely sure if signing CLA is counted as meeting (A) of DCO.

As I read "by some other person who certified", as they should be having DCO as well. But I can easily assume that CLA may count here as well. We just need a clarification on such case, imo.

Top posting has made this response awkward, but I'm going to try my best.

I think the idea is that existing patchsets pushed under the CLA don't need to be updated simply to add the signed off by to the commit message. That said, once we start enforcing the signed off by lines in the commit message the Gerrit enforcement for new patchsets is going to check that the commit Author, Committer, and the person taking the Gerrit action all have signed off by lines [2].

To follow up on this, due to the way the boolean condition is formed with !sboAuthor && !sboCommitter && !sboMe in [2] we only need one of those to match a single signed off by line and then we're good according to the check. That behavior was intentionally added to Gerrit 16 years ago in this commit [3].

I believe that in most rebase situations the Author will remain the same, but if someone who isn't the Author is doing the rebase then they become Committer. This means to go from patchset N to patchset N+1 via a rebase of someone elses change Gerrit will require both individuals sign off. In those situations, the simplest thing is likely going to be having the Author do the rebase and add the signed off by themselves.

...

[1] https://developercertificate.org/

On Thu, 22 May 2025, 08:04 Goutham Pacha Ravi, <gouthampravi@gmail.com> wrote:

...

On Wed, May 21, 2025 at 10:20 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

...

...

If you're inclined to use the UI, you'll need to first edit the commit message, and add a "Signed-off-by" with your name and email, and then hit the "Rebase" button.

That is actually interesting point you raised. Correct me, but I think this is an option, only if you are rebasing your own patch.

But what is the course of actions if a project maintainer wants or needs to rebase the patch proposed by contributor who is not on in contact or does not really want (or can) to add sign off, but the patch is valid and valuable?

My understanding is that the original contributor adhered to the ICLA, and their contribution made prior to the DCO enforcement date is acceptable as is. Further edits are made by others and they must follow the DCO.

[2] https://gerrit.googlesource.com/gerrit/+/refs/tags/v3.10.6/java/com/google/g...

[3] https://gerrit.googlesource.com/gerrit/+/007c4da18a9ef4e70c5bc57b285b4ba447d...

On 22/05/2025 18:46, Clark Boylan wrote:

On Thu, May 22, 2025, at 8:00 AM, Clark Boylan wrote:

...

On Wed, May 21, 2025, at 11:22 PM, Dmitriy Rabotyagov wrote:

...

Well, I'd say we totally need to have a lawyer input here, as while (C) of DCO [1] does cover rebases, I am not completely sure if signing CLA is counted as meeting (A) of DCO.

As I read "by some other person who certified", as they should be having DCO as well. But I can easily assume that CLA may count here as well. We just need a clarification on such case, imo. Top posting has made this response awkward, but I'm going to try my best.

I think the idea is that existing patchsets pushed under the CLA don't need to be updated simply to add the signed off by to the commit message. That said, once we start enforcing the signed off by lines in the commit message the Gerrit enforcement for new patchsets is going to check that the commit Author, Committer, and the person taking the Gerrit action all have signed off by lines [2]. To follow up on this, due to the way the boolean condition is formed with !sboAuthor && !sboCommitter && !sboMe in [2] we only need one of those to match a single signed off by line and then we're good according to the check. That behavior was intentionally added to Gerrit 16 years ago in this commit [3].

right and looping back tothe rebase button when i rebase someone esle patch with that i shoudl not need to add my Signed-off-By to the commit. i actully think it woudl be incorrect too. if we were to then zuul would/shoudl do that wehn it merging each commit as 99% of the time it woudl also be either rebasing it or generating a merge commit. if i rebased it an had to modify the content for a merge commit i shoudl add signed-off-by as i changed the code.

...

I believe that in most rebase situations the Author will remain the same, but if someone who isn't the Author is doing the rebase then they become Committer. This means to go from patchset N to patchset N+1 via a rebase of someone elses change Gerrit will require both individuals sign off. In those situations, the simplest thing is likely going to be having the Author do the rebase and add the signed off by themselves.

...

[1] https://developercertificate.org/

On Thu, 22 May 2025, 08:04 Goutham Pacha Ravi, <gouthampravi@gmail.com> wrote:

...

On Wed, May 21, 2025 at 10:20 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

...

...

If you're inclined to use the UI, you'll need to first edit the commit message, and add a "Signed-off-by" with your name and email, and then hit the "Rebase" button. That is actually interesting point you raised. Correct me, but I think this is an option, only if you are rebasing your own patch.

But what is the course of actions if a project maintainer wants or needs to rebase the patch proposed by contributor who is not on in contact or does not really want (or can) to add sign off, but the patch is valid and valuable? My understanding is that the original contributor adhered to the ICLA, and their contribution made prior to the DCO enforcement date is acceptable as is. Further edits are made by others and they must follow the DCO. [2] https://gerrit.googlesource.com/gerrit/+/refs/tags/v3.10.6/java/com/google/g... [3] https://gerrit.googlesource.com/gerrit/+/007c4da18a9ef4e70c5bc57b285b4ba447d...

On 23/05/2025 15:11, Jay Faulkner wrote:

On 5/23/25 12:57 AM, Sean Mooney wrote:

...

i actully think it woudl be incorrect too.

In item "c", it addresses this kind of signoff.

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

https://developercertificate.org/

While I agree a rebase doesn't *need* a signoff, I should not say it's incorrect to add one. In fact, in other communities that use DCO (like Gentoo), I am required to add a signoff for any patch passing through my hands, even if I don't directly modify it.

by that logic as a core review i would be required to add my signed-off by when ever i approve a patch to merge my understanding is that the the DCO is a commitment form the author that they are allowed to contribute the review content under the terms of the license of the project and an affirmation that they agree to do so. so the received content will in our case be contributed under the apache2 license which no stipulation with regards to signed off by ectra. if adopting the DCO would require use to update the commit message like that just to rebase it or worse merge it i think that would be an excessive burden to put on maintainer who already are over taxed with reviews. if we are modifying the code content even if just resolving trivial merge conflict adding signed off by is more reasonable but even in that case that is tracked by the committer filed and the authorship is still that of the original author. in the case of resolving a merge conflict it really falls under b but for clicking the rebase button with no change is closet to C assuming the patch contains a signed-off by or was contributed under the current icla which would make the contribute APACHE 2 licensed. i often use the rebase button instead of a recheck when a patch fial due to a flaky test or an unrelated infra issue and it has not been updated in a few days. that results in a cleaner history as we hopefully avoid a merge commit and is otherwise a nice alternative to a bare recheck or "recheck DCO" which honestly would be preferable then having to pull the patch to add my "Signed-off-by" i also would not want to set a precedent of editing the commit in the ui to add my "Signed-off-by" to trigger a job run as a side effect either. i really think we should only be doing that if we make a material change to the code similar to a Co-authored by. for backprots we are adding the cherry picked form line anyway so adding signed off by when doing that is not really much extra effort. I really hope we are not trading a one time relatively minor step of readign and accepting the icla for a continuous burden for every contributions going forward. by the way on a related note where we recive patches for secuirty bugs as attachment to launchpad and the orgianl author is not the one to actully summit the patch i assume we will be useing clause B to make that submission on there behalf. """ 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 """ normally the reporter of a security bug is not the person that actually fixes the issue and that person has signed the icla if i was wright such a patch i would sign it off going forward but are we going to ask all those that submit a patch as an attachment like that to also include the signed off by too? i assume yes. i bring that up as we have discussed enforcing this in gerrit and while that is the primary way we get contributions its not the only one. we also get contribution for translations submitted via Zanata. those are submitted to project by a bot after the change are exported from the Zanata server but how are we going to enforce that those contribution are submitted under the project license? is there a way for translator to also add a "Signed-off-by" or otherwise agree to the DCO. i think that may have been over looked in the governance resolution currently begin proposed and should be reviewed before it is implemented.

-JayF