Re: DCO

On 1/27/25 12:55 PM, Bradley M. Kuhn wrote:
> Hey GDB folks,
>
> I'm not on this list, but I'm a big fan of GDB and have been doing work
> adjacent to and in support of GDB and all the toolchain communities for some
> time.  I read with interest this DCO thread you've been having; I'm grateful
> that you cc'ed me, as I do have some experience and knowledge about the
> situation that I think might be helpful.  In the past, I have also been
> involved in these discussions from inside the FSF — but I haven't been
> affiliated with the FSF since 2019.  As such, I can give perspective from
> having had different vantage points at different times.
>
> First of all, the DCO is a rather neat trick of legal hackery, and it works
> ok for Linux but the reason it works well in the Linux project is somewhat
> unique to Linux.  The most important thing I want to draw the GDB community's
> attention to is that the DCO is specifically designed to shift the blame and
> burden for improperly licensed code ending up in the codebase *onto the
> individual developers personally*.  This works great for companies, as it
> limits their liability.  In practice, it's rare anyone gets sued, so Linux
> folks are ok with the legal hack.  But I regularly urge developers to think
> carefully if they really want to take on such risk themselves.
>
> My position is nuanced: copyright assignment to a trusted non-profit is a
> really good tool for defending users' rights, but it has to be weighed
> against the convenience and ease of contribution, and that calculation is
> very hard to do.

There is another factor that you did not include in your calculation, 
which is the user actually finding the FSF a trusted non-profit. 
Regardless of any personal opinions I can have on the matter, I know 
that several programmers don't think that, and some of them are 
potential contributors to the GDB project (a personal acquaintance of 
mine has said so explicitly, and more than one implicitly).

By only having the copyright assignment we are implicitly reducing the 
pool of contributors to those that trust the FSF.

> One of the huge benefits of the FSF's copyright
> assignment/disclaimer process is that it forces every developer to have a
> really important conversation with their employer that they often don't
> bother to have:
>
>     (a) is it ok that I'm contributing this upstream?, and
>
>     (b) what is the proper copyright holder arrangement for such
>         contributions? , and
>
>     (c) do we (employer/employee) all really agree about (b)?
>
> Those are painful conversations, but it's a good thing if they happen as
> early as possible.  Also, those conversations should occur *even if* a
> developer isn't assigning copyright to a third party.  By default, absent a
> separate agreement, an employee's copyrights will be assigned to their
> employer anyway via "Work for Hire" (as it's called in the USA, and there are
> similar doctrines around the world).
>
> Those are a few reasons why my usual recommendation is that a project adapt
> the Linux DCO text for the needs of a their specific project (i.e., one size
> does not always fit all).  For example, the Samba Project decided to require
> in their Certificate that contributors explicitly license under a v3-group
> license.  Samba did this for for various reasons — including that it protects
> the project and the developers better than the Linux DCO:
>    https://gitlab.com/samba-team/devel/samba/-/blob/master/README.contributing
>
> Most importantly, my concern is that individual developers who don't want to
> assign to a charity (e.g., FSF or SFC) *push back* on their employers and
> instead demand employment contracts that let employees personally keep their
> own copyrights in the Free Software projects they contribute to.
>
> Ultimately, individuals make up Free Software projects, and I support the
> idea that a project have individual voices as part of its copyright holdings
> (i.e., I am sympathetic to those who don't want a projects' copyright
> assigned 100% to any organization, even if it's a charity.)  But, I don't
> think an oligarchy of copyright holders — whereby the copyright is held
> mostly by for-profit employers — serves Free Software's community-oriented,
> charitable, and individual-developer-and-user-minded goals.  We have observed
> that application of the DCO method of contribution (without a more
> comprehensive plan) often leads to that oligarchical outcome over time.

Another option for relaxing the need for CA could be that, if a user is 
doing contributions in their free time and unrelated to any work, they 
could use DCO, while someone contributing in a professional capacity 
would need to sign the CA. This would be enforced through emails: If it 
is something that looks professional (ie something that looks like 
email<at>company<dot>TLD) we'd know this goes through their employment, 
while something that looks end-user (ie, something like 
whatever<at>gmail/yahoo/university<dot>com), DCO would suffice, and for 
emails that we can't be sure, we could just ask the user.

This would lower the bar immensely for students or unemployed people, 
while not allowing for-profit companies to have most of the copyright of 
the project. We should still incentivize people who are employed but 
contributing in their free time to talk to their employer, but I think 
it isn't standard practice for employers to have copyright over things 
you do in your free time (at least not in Brazil), so I would think that 
DCO would still be acceptable in that case.

>
> I'm glad to discuss these topics more on this thread, offer my time to help
> GDB on how to implement a DCO-like solution effectively, and I also hope to
> reprise the licensing BoF at Cauldron this year to discuss these issues more.
> (We spent much of the time in the 2024 Licensing BoF discussing this very
> issue.)
>
> Also, IANAL, TINLA, and I also, as mentioned, I have not been affilaited with
> the FSF since 2019.  Nevertheless, I suspect that FSF folks would agree with
> most (but not all) of my views above, and I see they're cc'ed and hope
> they'lll also comment sharing their views.
>
> Sincerely,
> --
> Bradley M. Kuhn - he/them
> Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
> ========================================================================
> Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer
>

-- 
Cheers,
Guinevere Larsen
She/Her/Hers