Re: DCO

["Bradley M. Kuhn via Gdb" <gdb@sourceware.org>]

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.  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.

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