Seeking input from developers: glibc copyright assignment policy.

Bradley M. Kuhn bkuhn@sfconservancy.org
Sun Jul 4 23:25:16 GMT 2021


> On 7/4/21 4:55 AM, Florian Weimer wrote:
> > I would prefer something along the lines “Copyright The glibc
> > Contributors”.

IANAL, but my own experience and work with GPL enforcement and lots of
copyright issues, and information I've received from copyright attorneys over
the years have convinced me it's a big mistake to create a copyright notice
that lists as the legal entity as something that has no legal standing.  So,
unless you plan to form an organization called “the glibc Contributors”, I
advise against that notice.

What I recommend, though, if glibc is definitely going to a multi-copyright
held work, that you move copyright inventory to a single top-level file
instead of keeping it file-by-file.

In my years of examining FOSS code, I regularly find that developers,
particularly when working under the DCO, do a terrible job at keeping
file-by-file copyright inventory up-to-date.  The Linux project has
disturbingly taken to *removing* all such file-by-file copyright notices from
the source tree entirely, which is an over-correction and just as bad a
mistake in the other direction.  I just think file-by-file copyright notice
inventory has become so inaccurate in multi-copyright-held works that it
essential becomes a fiction: the copyright notice ends up being just the
first few people who worked on the file in question, and later contributors
simply forget to include an update of the copyright notices in the files.

As others have pointed out, copyright notices aren't mandatory under
copyright law to get move of the benefits.  Paul Eggert is quite correct that
there are some *minor* legal benefits in some countries to keep copyright
notices in place.  (Some folks do argue that those benefits are so strong
that it's imperative to keep copyright notices accurate on a file-by-file
basis; but I disagree with that position).  The fact is, storing copyrighted
materials in separate files on a computer is purely a technical convenience,
as copyright law doesn't generally think in terms of “what file it was in”
but rather “what is the work in question”.  (Licenses like the MPL do have
certain requirements that are file-based, but the LGPL and GPL doesn't have
these kinds of requirements.)

Thus, my usual recommendations to projects is to change the file-level notices
to something like:

/* License: LGPLv2-or-later ; copyright and license notices kept in file
** COPYRIGHT at the top level of this source tree, and available at <URL>
** if you receive this file separated from the entire source tree
*/

and then move all the file-by-file notices, with the long text from the LGPL
about the license details, plus the copyright notices, together into that
*one* file called COPYRIGHT at the top-level, and encourage contributors to
update that file if they want a copyright notice added.

Again, IANAL and TINLA.  I recommend that the Glibc developers talk to
multiple copyright attorneys about these issues before making a change, and
copyright attorneys do disagree about some of these things in my experience.
The issues you're going to face moving to a fully multi-copyright-held work
are going to be many; I urge you to sort all this out before dropping
copyright assignment.

   * * *

Finally, since I'm posting my first email here after the feedback deadline,
I'd like to inquire about what the leaders of the glibc project thought about
all the feedback received and if the plans have been made any more detailed
based on the feedback received — particularly with regard to what, if
anything, the project is going to do to figure out who the real copyright
holders are of various contributors once opt-outs of assignment begin.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter


More information about the Libc-alpha mailing list