Re: DCO: Was: Re: Contributing to gdb

[Luis Machado via Gdb <gdb@sourceware.org>]

On 1/13/25 17:14, Andrew Burgess wrote:
> Luis Machado via Gdb <gdb@sourceware.org> writes:
> 
>> Hi,
>>
>> On 6/23/24 23:06, Tom Tromey wrote:
>>>>> I just noticed that GDB (and binutils) are currently not accepting
>>>>> DCO's like both glibc
>>>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>>>> has this not been brought up yet?
>>>
>>> If gcc, glibc, and binutils accept it, then IMO gdb should as well.
>>>
>>> Tom
>>
>> Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
>> of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
>> want to stray from the other toolchain projects by not making a decision on whether we accept
>> it or not.
>>
>> [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/
> 
> Based on nothing more than remaining consistent with gcc, binutils, and
> glibc, I think we should make the switch to accepting DCO contributions
> under the same terms that binutils uses[2] (as well as accepting FSF
> assigned contributions).
> 
> I'm volunteering myself to add suitable words to the GDB wiki (based off
> the binutils wording), unless anyone objects.  Ideally I'd like a +1
> from a couple of other global maintainers with no serious objections,
> and I'll go ahead and make the change.
> 
> I think that Eli believes the concerns with FSF assignment are
> overblown, and given the information provided, I'm inclined to agree.
> But at this point, with other components accepting DCO, I'm not sure
> that's really relevant.  Unless there's a super compelling reason why
> GDB should diverge ... I think we should fall into line with the other
> components.
> 
> [2] https://sourceware.org/binutils/wiki/HowToContribute
> 
> Thanks,
> Andrew
> 

I did some reading on DCO's and I have mixed feelings. I haven't followed
discussions about DCO's on the other GNU tools projects, so it is not clear
to me yet how/if they addressed the shortcomings of DCO's.

While I agree having gdb be the sole bureaucratic entity not accepting DCO
with the other GNU tools projects accepting it (in particular because we
share code with binutils, so technically we'd have to make a joint decision),
DCO's don't seem to come for free, as we need to track each and every one of
those contributions so we can refer back to them when/if we ever decide to
update/switch licenses or if a legal problem arises.

The contributions are not gdb's, they are still owned by their contributors,
but those are granted the right to be distributed by gdb under the GPL, if I
understand it correctly.

That is potentially a lot of work, and really needs to be taken seriously if
we really want to do things by the book. Makes me wonder how we're supposed
to track this.

Also, I've seen DCO's being sold partially as a mechanism that doesn't require
contributors to share personal information, due to privacy concerns. I don't
think that is true from my reading of it, given we absolutely need to know
how to reach out to the contributor/employer of the contributor in case the
need arises. And that is not even considering things like the contributor
passing away, disappearing etc.

Has this ever been discussed at a higher level across global maintainers of the
other projects?

If all we want is a means to simplify contributions or an alternate way of
contributing for people that don't want to be out in the open personal-
-information-wise, DCO's may not cover it all.