Re: DCO: Was: Re: Contributing to gdb

> Date: Mon, 17 Jun 2024 15:18:25 -0300
> Cc: [email protected], [email protected], [email protected]
> From: Guinevere Larsen <[email protected]>
> 
> > And who talked to them and made sure they understand completely what
> > copyright assignment means and entails?  IME, a large number of people
> > have completely distorted idea about that, and are mightily surprised
> > when told the facts by someone who knows them.
> Another problem with this system, then, is scalability. Yes, we don't 
> have huge swaths of people eagerly waiting to contribute to GDB, but if 
> it is hard enough for regular contributors to find time to review 
> patches, where is the time for someone who understands completely the 
> copyright assignment to mentor prospective contributors before they are 
> turned away when they read that this is a requirement in the 
> contribution checklist?

That's not an excuse.  And you can ask me to do that.  I will make
time for it, exactly as I make time to review documentation patches
here, and as I make time to explain this stuff to contributors to
Emacs.

> > In contrast to the above, which may or may not be true, the risks
> > associated with accepting DCOs are real, not imaginary and not
> > "maybe".

> Could you explain the risks? Not only I am not a lawyer, I have an extra 
> large blindspot with regards to copyright law.

They were explained many times on gnu-prog-discuss 3 years ago, so you
are invited to read those discussions.  Basically people misrepresent
themselves as having the rights to contribute code which they have no
legal rights to contribute, and it's likely to happen exactly in the
cases in which the copyright assignment is complicated by the need to
obtain the disclaimer of the employer.

> > Anyway, I don't see a need to argue.  You have expressed your opinion,
> > and I expressed mine.  We disagree.  It's allowed and is perfectly
> > okay.
> >
> I would like to change the current system, but I don't have all the 
> information, so I think it would be beneficial for us to discuss this so 
> that we don't rely on any one person's personal preference, and instead 
> choose what is best for the project.

Anyone who wants to discuss this seriously should first read the
gnu-prog-discuss discussion of these issues, from June 2021 (it went
on all the way through July).