Seeking input from developers: glibc copyright assignment policy.

Bradley M. Kuhn
Wed Jun 30 21:54:40 GMT 2021

Dear glibc Software Developer Community,

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

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

These are just a few questions among dozens that will quickly become
paramount once glibc starts its move to a primarily multi-copyright-held
(from a primarily overwhelming-majority-single-copyright-held) project.  Of
course, glibc isn't the only project facing these questions.  As such, in
response to these recent changes under consideration by GCC, glibc, and
gnulib, I've written a comprehensive essay that (while quite long) raises
all the questions and concerns that I have about this change.  If you're
interested, you can read it here:

I also offer myself and my colleagues at Software Freedom Conservancy as a
resource to help you investigate these questions if you're interested (as
one of my colleague already did for (see
<>) Personally, I've
spent a career studying the policy questions and observing their
consequences in real world scenarios, and organizationally Conservancy has
done the same.  I'd be thrilled to share that knowledge with you.

Finally, I saw a few folks in this thread wondering about "what the lawyers
have said" or what they think.  Keep in mind: I personally am not a lawyer,
and Conservancy is not a law firm and we won't and cannot give you legal
advice.  However, I do urge you all to talk to your lawyers about this.

However, keep in mind also that "the lawyers at work" are the lawyers for
your company, not for you personally or the glibc project.  As such, lawyers
at your workplace will gladly give you legal advice that is in the best
interest of the company, but they don't represent your interests nor glibc's
interests.  It's important that you have someone looking out for *your*
legal interests and the legal interests of glibc as a project.  Sometimes
those interests will align with your employer, and sometimes they won't.  If
you're looking for a lawyer for yourself, while I don't know anyone who does
such work pro-bono, I do know a lot of lawyers who would gladly give you a
"low bono" rate.  If you write my privately, I'll try to give you a
recommendation of an attorney to reach out to.

In closing, I ask everyone to consider the efficacy of, enforcement of, and
future compliance with copyleft licenses in making this momentous decision.
Thanks for your time in reading this email, and hopefully -- yes, I know
it's a wall of text -- in reading my longer essay on the subject:

Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
Become a Conservancy Supporter today:

More information about the Libc-alpha mailing list