On Thu, Jul 24, 2025 at 1:21 PM Brian Stansberry via wildfly-dev <
wildfly-dev(a)lists.jboss.org> wrote:
Thanks, Tom and Yoann.
So, people with professional knowledge of these things (I've now seen the
Red Hat OSPO guidelines Tom mentioned; unfortunately not public but quite
clear) have indicated that not requiring Signed-off-by and doing things the
way Narayana and Hibernate do is ok.
Do we want to do signoffs anyway? Personally, I don't. It would be a lot
of logistics I think.
+1 to "don't want"
If we felt the need for a signing off I would prefer it was in the form of
a GPG signature as that can at least be used to verify source came from a
specific source but I don't think we need that at this stage either.
On Thu, Jul 24, 2025 at 5:00 AM Yoann Rodiere <yoann(a)hibernate.org> wrote:
> Hey,
>
> What we've been using in the Hibernate repos is this:
>
> All contributions are subject to the Developer Certificate of Origin
>> (DCO) <
https://developercertificate.org/>. The DCO text is available
>> verbatim in the dco.txt
>> <
https://github.com/hibernate/hibernate-orm/blob/main/dco.txt> file in
>> the root directory of the ORM repository.
>>
>
> It's in CONTRIBUTING.md:
>
https://github.com/hibernate/hibernate-orm/blob/50177c5b2efd0bb84a2fc59bf...
>
> This is in line with the requirements from Commonhaus at
>
https://github.com/commonhaus/foundation/blob/main/templates/README.md#co...
>
> Our assumption -- validated by people who *do* have actual knowledge in
> copyright laws -- is that this is enough, and that no sign-off is required
> as long as this is listed as a requirement for contributing to our projects.
>
> @Sanne Grinovero <sanne(a)hibernate.org> would probably know the exact
> history behind this. Or tell you if I'm wrong :) But I know we've discussed
> it again recently when moving to Commonhaus, and it was confirmed to me
> that this was enough, without requiring anything more from contributors.
>
> Yoann Rodière
> Hibernate team
>
>
> On Thu, Jul 24, 2025 at 10:40 AM Tom Jenkinson via wildfly-dev <
> wildfly-dev(a)lists.jboss.org> wrote:
>
>>
>>
>> On Thu, 17 Jul 2025 at 16:59, Brian Stansberry via wildfly-dev <
>> wildfly-dev(a)lists.jboss.org> wrote:
>>
>>>
>>>
>>> On Thu, Jul 17, 2025 at 10:37 AM Darran Lofthouse <
>>> darran.lofthouse(a)jboss.com> wrote:
>>>
>>>> On Thu, Jul 17, 2025 at 4:20 PM Brian Stansberry via wildfly-dev <
>>>> wildfly-dev(a)lists.jboss.org> wrote:
>>>>
>>>>> The clause you mention is the CONTRIBUTING.md thing from my point
#2,
>>>>> with the Narayana version I linked being the example.
>>>>>
>>>>> I don't see any indication Commonhaus requires the signoff.
>>>>>
https://github.com/commonhaus/foundation/blob/main/templates/README.md
>>>>> is where their requirements around this subject are discussed.
>>>>>
>>>>> More formal discussions of DCOs that I've seen, e.g.
>>>>>
https://osr.finos.org/docs/bok/artifacts/clas-and-dcos, indicate
>>>>> it's needed.
>>>>>
>>>>> Apache uses CLAs so they are not a source of guidance. Eclipse
>>>>> requires Signed-off-by blocks, which I believe is done to ensure
>>>>> attestation to complying with Eclipse requirements like this, but
signing
>>>>> the required Eclipse Contributor Agreement itself also requires
attesting
>>>>> to the DCO.
https://www.eclipse.org/legal/eca/
>>>>>
>>>>> I can ask around more about this at Commonhaus if needed. I
didn't
>>>>> want to proactively do that if adding this requirement is
non-controversial.
>>>>>
>>>>
>>>> Personally I find having to add a Signed-Off by to a commit message
>>>> really annoying when you find out at the time of submission that your PR
is
>>>> rejected due to lack of this field and yet the project has no clear
>>>> definition of it's meaning.
>>>>
>>>> Good point. Any implementation of this should involve beefing up the
>>> CONTRIBUTING.md language to make it clear what "Signed-off by"
means.
>>>
>>> But, I just now noticed this interesting bit in the Narayana document:
>>>
>>> "(we adopt the "CoreOS method" approach to using the DCO in
which there
>>> is no per-commit signoff ceremony)."
>>>
>>> Googling isn't giving me any details on that, other than convincing
>>> sounding but undocumented AI generated stuff, so hopefully Tom or Mike can
>>> give us more details.
>>>
>>
>> Sure, the wording you can find in our CONTRIBUTING.md followed an option
>> that guidelines provided by the Red Hat Open Source Program Office (if
>> anyone is curious what an OSPO does, please consider to take a look at
>>
https://www.redhat.com/en/blog/what-does-open-source-program-office-do).
>> Assessing myself more, I would point you to consider the wording "By
>> contributing to this project you agree...".
>>
>> Perhaps this additional insight helps providing an option for other
>> projects to consider?
>>
>>
>>>
>>> IMO in the DCO it should almost be a case of swapping out this line:
>>>>
>>>> By making a contribution to this project, I certify that
>>>>
>>>> With something like:
>>>>
>>>> By contributing to this project I certify the following by using a
Signed-Off commit
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 17, 2025 at 10:02 AM David Lloyd
<david.lloyd(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I think that using `Signed-off-by` for this purpose is really
>>>>>> oblique, and in most or all cases it's just going to be the
same as the
>>>>>> person who made the commit in the first place, which makes it
more or less
>>>>>> useless informationally speaking. Could there not instead be a
clause which
>>>>>> indicates that the mere act of submitting the commit is an
attestation of
>>>>>> its origin and/or agreement with the DCO?
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 17, 2025 at 9:55 AM Brian Stansberry via wildfly-dev
<
>>>>>> wildfly-dev(a)lists.jboss.org> wrote:
>>>>>>
>>>>>>> One of the few requirements that Commonhaus puts on its
projects is
>>>>>>> that they use either a Developer Certificate of Origin or
some kind of
>>>>>>> Contributor License Agreement system. This is a reasonable
requirement and
>>>>>>> I believe some projects associated with WildFly are already
using a DCO.
>>>>>>>
>>>>>>> If you're impatient, skip to #3 below...
>>>>>>>
>>>>>>> A CLA isn't really practical to administer for an
organization of
>>>>>>> our scope; a DCO is far simpler.
>>>>>>>
>>>>>>> There are three things we need to do for a good DCO system.
>>>>>>>
>>>>>>> 1) Add a dco.txt file in each repository. Commonhaus has a
jbang
>>>>>>> script "policy-panda"[1] that checks for this when
run against a GitHub org.
>>>>>>>
>>>>>>> You may have noticed that a few days ago I spammed 88 repos
in the
>>>>>>> wildfly and wildfly-extras GH org with PRs to add this file.
In case it is
>>>>>>> helpful for other orgs, the script is at [2].
>>>>>>>
>>>>>>> 2) Add a reference to the DCO in the CONTRIBUTING.md in each
repo.
>>>>>>> This is also checked by the Commonhaus policy-panda script.
>>>>>>>
>>>>>>> Narayana has nice text in [3] that I think is appropriate
most
>>>>>>> anywhere. (Note that the requested license/copyright header
says "The
>>>>>>> Narayana Authors". For repos in the wildfly and
wildfly-extras orgs it
>>>>>>> would be "The WildFly Authors".)
>>>>>>>
>>>>>>> I don't think we should take immediate action on this,
i.e. don't
>>>>>>> everyone go off and start editing existing files separately.
We can make a
>>>>>>> plan. FWIW, my jbang script at [2] can also send up
modification PRs, so if
>>>>>>> we determine that big sets of repos should all use the same
file it may be
>>>>>>> helpful.
>>>>>>>
>>>>>>> 3) DCOs involve an attestation from the person submitting
that code
>>>>>>> that they agree with the DCO. This is typically done via a
'Signed-off-by'
>>>>>>> line in the git commit message. This can be done via the -s
flag (lower
>>>>>>> case) to the git commit command.
>>>>>>>
>>>>>>> I expect there will be lots of discussion around the
logistics of
>>>>>>> adding these signoffs! There already are in the brand new
zulip thread
>>>>>>> around this. Chatters -- please post a summary of the
discussion to this
>>>>>>> thread as many WF developers are not actively following
zulip!
>>>>>>>
>>>>>>> Note that the git commit flag for a signoff is "-s"
NOT "-S" which
>>>>>>> is a different thing that triggers gpg signing of your
commit. GPG signing
>>>>>>> is not an attestation of a DCO etc.
>>>>>>>
>>>>>>> Rado has kindly created a WFLY issue[5] to track adding of
software
>>>>>>> enforcement of the signoff requirement. The details of that
are another
>>>>>>> topic to discuss.
>>>>>>>
>>>>>>> [1]
>>>>>>>
https://github.com/commonhaus/foundation/tree/main/templates/panda
>>>>>>> [2]
https://github.com/bstansberry/git-file-adder
>>>>>>> [3]
https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md
>>>>>>> [4]
>>>>>>>
https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t...
>>>>>>> [5]
https://issues.redhat.com/browse/WFLY-20791
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Architect, JBoss EAP
>>>>>>> WildFly Project Lead
>>>>>>> He/Him/His
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>>>>>> To unsubscribe send an email to
wildfly-dev-leave(a)lists.jboss.org
>>>>>>> Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
>>>>>>> List Archives:
>>>>>>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> - DML • he/him
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Architect, JBoss EAP
>>>>> WildFly Project Lead
>>>>> He/Him/His
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>>>> Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
>>>>> List Archives:
>>>>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>>>>
>>>>
>>>
>>> --
>>> Brian Stansberry
>>> Architect, JBoss EAP
>>> WildFly Project Lead
>>> He/Him/His
>>> _______________________________________________
>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>> Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
>>> List Archives:
>>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>>
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
>> List Archives:
>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>
>
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...