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: Thu, 01 Jul 2021 12:33:11 -0700	[thread overview]
Message-ID: <87eechbzig.fsf@ebb.org> (raw)
In-Reply-To: <c6dc096b-a996-f882-4eb3-480656486df1@gotplt.org> (Siddhesh Poyarekar's message of "Thu, 1 Jul 2021 10:54:53 +0530")

Siddhesh Poyarekar wrote at 22:24 (PDT) on Wednesday:
> I strongly believe dropping the assignment requirement makes it easier for
> developers to get involved.

I absolutely agree, and as I indicated in my longer essay, I personally
prefer a model where there is a good mix of copyrights held by individual
contributors and charities both.  That is not a new position of mine.  My
affiliation with the FSF ended in 2019, but when I previously had
affiliation with the FSF, I was one of the few internal voices who advocated
to relax the copyright assignment processes for GCC, *provided that*
individuals rather companies held the non-FSF-assigned copyrights.  I argued
for that internally at the FSF on a semi-regular basis from 2002 right up
until a few moths before my affiliation with the FSF ended in 2019.

*However* … 

> I still don't expect the FSF ownership to be diluted by much for various
> reasons.

I think we can't know that for sure one way or the other — unless someone
does the work to:

  (a) comb and collate VCS logs to document who the major contributors are,
  (b) figure out who their employers are (or were, or will be),
  (c) clearly examine how the copyright assignment / disclaimer of copyright
      relationships between those companies and the FSF are currently
      structured, and
  (d) do an analysis of what's likely to happen to those agreements once the
      copyright assignment requirement is lifted.

Keep in mind that the copyright assignment/disclaimer arrangements have many
forms and structures; IIUC, most can be revoked.  Furthermore, I note that
the deadline day for input on this momentous change is nearing its end, and
there are no statements on this thread from the well-known major employers
involved in glibc about what their intended copyright policy if the FSF
copyright assignment mandate is lifted.

Absent assurances and more information, we must assume the worst case: that
the all new copyrights are owned by the contributors' employers as soon as
the copyright assignment mandate is lifted.

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

This has led to many bad outcomes for Linux.  While those outcomes can and
have been (mostly) mitigated, I don't recommend glibc aim to emulate that
model.

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

Those organizations likely do not share a belief that copyleft should be
enforced for the good of downstream users, so I think that point is bad
news, not good news … which relates to your later point …
> 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.

… with which I agree.

Meanwhile, on the matter of potential Conservancy involvement:
> The SFC enforcement coalition your colleague mentioned on the gcc list is
> a great option IMO.

I'm glad you think so, and Conservancy does have that form of arrangement
with the Debian project.  Debian's primary home in the USA is Software in
the Public Interest, but they have a limited arrangement with Conservancy
regarding voluntary copyright assignments for some contributors, and
enforcement proxy agreements for those who own their copyrights.  The best
resource for how that program works is the original announcements:
           https://sfconservancy.org/news/2015/aug/17/debian/
           https://sfconservancy.org/blog/2015/aug/17/debian/

Most importantly, keep in mind that major Debian contributors approached
Conservancy to request this.  Conservancy doesn't unilaterally start these
kinds of programs; we do them when project contributors ask for them.  We've
offered to help generally, but no one has asked us for any specific
assistance in the case of glibc, GCC, and gnulib.  Beyond general comments
and thoughts (such as this email), we *wouldn't* impose ourselves on the
situation unless explicitly requested.  IOW, at the moment, I and
Conservancy aren't involved, other than to give our opinions as folks
knowledgeable on the subject — in response to the public call for comment:
    https://sourceware.org/pipermail/libc-alpha/2021-June/127581.html

> I still expect the majority [of the copyright] … to stay with … a handful
> of companies, some of whom have been targets in the past of frivolous
> copyright claims in Open Source code.

I suppose it's possible that companies who contribute to glibc have also
faced frivolous copyright claims on FOSS.  (However, such incidents are
extremely rare, though — and, I'm admittedly wondering if you're referencing
the same widely exaggerated tale that I'm thinking of.)  Regardless, I think
it's a moot point.  Such a situation doesn't imply those companies will
later have the goal of defending the rights of users under copyleft.  If
relevant at all, IMO, it cuts the other way: those companies may seek
copyrights for escalation/counter-claims against any enforcement action
(even a legitimate one brought to defend users' rights).  Note that, when
they enforce the LGPL and GPL, Conservancy and FSF are both accused of being
“copyright trolls”, and the Defendants *always* call those claims “frivolous”.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter

  reply	other threads:[~2021-07-01 19:35 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
2021-07-01  5:24   ` Siddhesh Poyarekar
2021-07-01 19:33     ` Bradley M. Kuhn [this message]
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=87eechbzig.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).