Re: Seeking input from developers: glibc copyright assignment policy.

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 7/1/21 3:24 AM, Bradley M. Kuhn wrote:
> Dear glibc Software Developer Community,

Thank you for writing this and the blog post.  I share my 2p as a long 
time contributor but I'm not ashamed to admit that there are others who 
would have far more educated opinions.

> I have read this thread with interest, and I hope that it is acceptable for
> me to share my comments.  Even though I personally have never put code into
> glibc, I *have* helped over the years with various issues around licensing
> in glibc (before the abrupt end to my affiliation with the FSF in 2019).  I
> hope that past work to help glibc, and my general work in the Free and Open
> Source Software community on copyleft enforcement, compliance, and policy
> means that my opinions here are useful.  However, if decision-making input
> here is welcome only from those who have code in glibc, I understand
> completely and, if so, please ignore this interruption!
> 
>       * * *
> 
> Much of the discussion I've seen here has contrasted the DCO with a
> copyright assignment process.  I am particularly appreciative for those who
> have pointed out that's not the case: the DCO and copyright assignment
> policies are orthogonal issues.  I fully support use of a DCO for glibc,
> although I recommend the Samba one myself (See
> <https://www.samba.org/samba/devel/copyright-policy.html>).  Regardless of
> which DCO you pick, you could implement most any DCO and keep copyright
> assignment; the two ultimately have little to do with each other.

This looks quite good.  There would be practical concerns, i.e. who 
becomes the custodian of such records, but they're not insurmountable.

> The key quesiton at hand, thus, is whether to continue or curtail the
> mandated copyright assignment to FSF for regular/frequent contributors.
> While I have previously assigned my own copyright to the FSF (*both* as
> "work-for-hire" and "signed assignment form" manner), I personally wouldn't
> assign any new copyrights to FSF at this time for various reasons.
> Therefore, I am personally sympathetic to those of you who do not want to
> assign anymore.
> 
> Nevertheless, I feel much of this discussion is missing a few of the key
> nuances that are highly relevant to ending the copyright assignment mandate.
> Most importantly, the current proposal does not make recommendations on what
> developers should do (and/or how they should organize) to assure that they
> will ultimately keep their own copyrights when the existing copyright
> assignment legal infrastructure starts to atrophy after the policy change.
> By default, most copyrights revert to the employer when you contribute to a
> codebase as part of your job.
> 
> A few commentors on this list claim that *in theory*, this policy change
> opens a world of possibility and diversity of where the copyright ownership
> lands.  However, given work-for-hire doctrine in the USA (and similar rules
> around the world), it's highly unlikely that theory will come to fruition in
> practice without a clear plan.  Most future contributions may well revert to
> emloyer-owned.  Only collective organization by developers *before* the
> policy change takes effect can prevent that.

I strongly believe dropping the assignment requirement makes it easier 
for developers to get involved.  However, I don't see that changing the 
structure of copyright ownership of the glibc code base by much in the 
short or medium term.

The change in copyright ownership may change in the long term, but given 
the current contributions, I still expect the majority to stay with the 
FSF and a handful of companies, some of whom have been targets in the 
past of frivolous copyright claims in Open Source code.  That won't be 
too different from the Linux project, where a bulk of the code in the 
core kernel originates from a handful of companies.  If anything, it's 
likely to be even more constrained.

> I thus strongly urge caution, and more careful consideration about the
> ramifications of where copyright will land going forward, including (but not
> exclusively limited to) a long extension of the current July 1st deadline.
> 
> Three questions that I have yet to see addressed in this thread include:
> 
>        * What do we anticipate the long term mix of copyright holders (say, 5
>          years from now) will be in glibc once copyright assignment is wholly
>          optional?

Like I said above, in the long term the mix may change, but I still 
don't expect the FSF ownership to be diluted by much for various 
reasons.  Even if there were dilution, I don't expect it to diverge too 
much from the handful of organizations that currently pitch in to 
maintain glibc.  I think there are predictable patterns to those 
contributions too in terms of which sources are touched by which 
individuals/organizations.

>        * Will whoever holds the future copyright be willing to enforce the
>          LGPL?  (That's particular important given that LGPL/GPL violations
>          are quite common on glibc.)
> 
>        * Will that copyright holder adhere to well-established community
>          principles and a committment to the public good when doing that
>          enforcement?

I believe the FSF would have enough of a copyright stake in glibc even 
in the long term to have the means and the incentive to do that. However 
like you mentioned in your blog post (and I've heard from others in a 
significantly less polite manner and long before the internal crisis you 
mentioned), the FSF isn't exactly rushing to act on violations and 
enforcement.

I'm under no illusion that for profit companies would actively seek out 
violators and help get them on course to compliance since it does not 
affect their core business.  The SFC enforcement coalition your 
colleague mentioned on the gcc list is a great option IMO.

Thanks,
Siddhesh