public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Bradley M. Kuhn" <bkuhn@sfconservancy.org>
To: libc-alpha@sourceware.org
Subject: Re: Seeking input from developers: glibc copyright assignment policy.
Date: Wed, 30 Jun 2021 14:54:40 -0700	[thread overview]
Message-ID: <877dibhvbz.fsf@ebb.org> (raw)
In-Reply-To: <e13a4072-a53e-d9e1-d5c7-bf4179fead56@redhat.com> (Carlos O'Donell's message of "Mon, 14 Jun 2021 14:52:03 -0400")

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

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

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:
https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

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
<https://gcc.gnu.org/pipermail/gcc/2021-June/236257.html>) 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:
 https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

Sincerely,
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

  parent reply	other threads:[~2021-06-30 21:56 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 18:52 Carlos O'Donell
2021-06-14 19:08 ` Rich Felker
2021-06-14 19:25   ` Khem Raj
2021-06-14 20:05 ` Florian Weimer
2021-06-14 20:22   ` Matt Turner
2021-06-15 20:28     ` Carlos O'Donell
2021-06-14 21:16   ` Paul Eggert
2021-06-14 20:18 ` Matt Turner
2021-06-14 20:22 ` Adhemerval Zanella
2021-06-15  2:48 ` Siddhesh Poyarekar
2021-06-15  3:18 ` DJ Delorie
2021-06-15 17:41   ` Paul Eggert
2021-06-15 18:43     ` DJ Delorie
2021-06-15 19:05       ` Paul Eggert
2021-06-15 19:12         ` DJ Delorie
2021-06-15 19:35           ` Paul Eggert
2021-06-15 19:42             ` DJ Delorie
2021-06-15 20:08             ` Carlos O'Donell
2021-07-02 22:33             ` Carlos O'Donell
2021-07-03  1:59               ` Paul Eggert
2021-07-04  0:40                 ` Paul Eggert
2021-07-04 11:55                   ` Florian Weimer
2021-07-04 18:32                     ` Paul Eggert
2021-07-04 23:25                       ` Bradley M. Kuhn
2021-07-05 15:26                         ` Christoph Hellwig
2021-07-06 18:02                           ` Bradley M. Kuhn
2021-07-05  5:28                       ` Carlos O'Donell
2021-07-05 20:21                         ` Paul Eggert
2021-07-06 18:05                           ` Bradley M. Kuhn
2021-07-06 19:42                             ` Paul Eggert
     [not found]                               ` <YOTTfm12jac/NYe5@ebb.org>
2021-07-07  8:51                                 ` Florian Weimer
2021-07-07 15:01                                   ` Joseph Myers
2021-07-05  5:00                     ` Carlos O'Donell
2021-07-05  5:28                       ` Florian Weimer
2021-07-05 20:37                 ` Joseph Myers
2021-07-03  3:24               ` Bruno Haible
2021-07-05  5:53                 ` Carlos O'Donell
2021-06-15  3:39 ` Daniel Black
2021-06-15 16:09 ` Josh Triplett
2021-06-16 13:01 ` Alyssa Ross
2021-06-16 14:08 ` Adam Sampson
2021-06-16 19:33   ` Joseph Myers
2021-06-16 19:45 ` Phil Blundell
2021-06-30 21:54 ` Bradley M. Kuhn [this message]
2021-07-01  5:24   ` Siddhesh Poyarekar
2021-07-01 19:33     ` Bradley M. Kuhn
2021-07-02  3:29       ` Siddhesh Poyarekar
2021-07-03  6:03         ` Eli Zaretskii
2021-07-01  8:19   ` Alexandre Oliva
2021-07-02  8:59   ` Florian Weimer
2021-06-30 22:21 ` Mark Wielaard
2021-06-23  1:04 Bruno Haible
2021-06-23  3:19 ` Siddhesh Poyarekar
2021-06-24 19:30   ` Eli Zaretskii
2021-06-25  2:23     ` Siddhesh Poyarekar
2021-06-25  6:26       ` Eli Zaretskii
2021-06-25  6:47         ` Siddhesh Poyarekar
2021-06-25  7:06           ` Eli Zaretskii
2021-06-25  8:57             ` Siddhesh Poyarekar
2021-06-25  9:43               ` Siddhesh Poyarekar
2021-06-25 11:32                 ` Eli Zaretskii
2021-06-25 12:07                   ` Florian Weimer
2021-06-25 12:11                   ` Siddhesh Poyarekar
2021-06-25 12:14                     ` Florian Weimer
2021-06-25 12:25                       ` Siddhesh Poyarekar
2021-06-25 12:33                         ` Florian Weimer
2021-06-25 12:48                           ` Siddhesh Poyarekar
2021-06-25 13:44                             ` Eli Zaretskii
2021-06-25 14:06                               ` Siddhesh Poyarekar
2021-06-26  6:31                                 ` Eli Zaretskii
2021-06-28  4:11                                   ` Siddhesh Poyarekar
2021-06-28 12:01                                     ` Eli Zaretskii
2021-06-28 13:06                                       ` Siddhesh Poyarekar
2021-06-28 14:04                                         ` Phil Blundell
2021-06-28 14:57                                         ` Eli Zaretskii
2021-06-25 11:30               ` Eli Zaretskii
2021-06-25 12:24                 ` Siddhesh Poyarekar
2021-06-25  7:24         ` Florian Weimer
2021-06-25  7:52           ` Eli Zaretskii
2021-06-25  8:23             ` Florian Weimer
2021-06-25 11:03               ` Eli Zaretskii
2021-06-25  6:30       ` Eli Zaretskii
2021-07-02 22:23 Craig Topham
2021-07-05 14:59 ` Szabolcs Nagy
2021-07-05 16:48   ` Eli Zaretskii
2021-07-05 18:52     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dibhvbz.fsf@ebb.org \
    --to=bkuhn@sfconservancy.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).