linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bradley M. Kuhn" <bkuhn@ebb.org>
To: linux-spdx@vger.kernel.org
Subject: Re: clarification on -only and -or-later
Date: Wed, 22 May 2019 12:04:42 -0700	[thread overview]
Message-ID: <20190522190442.5geeckoxfvj3fdvw@ebb.org> (raw)
In-Reply-To: <20190522154511.GA17763@kroah.com>

We should take care not to conflate changes made because: (a) all
relevant copyright holders consented, vs. (b) consent not available from the
copyright holders.  (a) and (b) differ greatly, both politically and legally.

With (a), we can certainly ask copyright holders for any notice changes that
seem useful, expedient, and would help Linux as a project.  (e.g., if, as
Thomas says, Red Hat is sole copyright holder of some code and agrees to
relicense it from GPL-1.0-or-later to GPL-2.0-or-later, I see no reason not
to gleefully accept that and make the change (copyright holders assent
well-documented in the commit log with relevant Signed-Off-By: , of course).
Similarly, (to "cross" the two active threads a bit), that we really have no
worries about old-notice-preservation if all relevant copyright holders
assents to replace their old notice with an SPDX Identifier.

However, with (b), judgment and risk analysis, both of legal and political
nature, will always be required.

During the "Great SPDX GPL Identifier Change" last year, Jilayne and I dug
deep on the legal judgment/risk-analysis about some of these notices -- in
collaboration with FSF (as license steward) and many others in the FOSS
licensing community -- to come to conclusions about the two ambiguous cases
Jilayne listed as (1) and (3) initially in this thread.  Jilayne's
suggestions for these cases were presumably informed by that, and I suspect
that's why she's recommending them as -or-later conclusions.

Nevertheless, if there is political risk (or even, as Greg points out,
annoying work not worth doing) involved with moving GPL-1.0-or-later code to
(say) GPL-2.0-or-later instead, then there is no reason to do so.
Furthermore, such a change also relates to this point:

There is danger of taking things that legal analysis concludes are
'-or-later' and turning them into '-only'.  Narrowing from '-or-later' to
'-only' is always permitted by downstream (and also the effective license of
the whole work of Linux will undoubtedly remain GPL-2.0-only).  However, so
many people have expressed a desire for accurate, complete, and
as-broad-as-legally-possible file-by-file licensing inventory.  This project
exists, presumably, to serve those requests.  We should strive to make sure
that, on a "file-by-file level", this project doesn't inadvertently narrow
permissions unduly.  Furthermore, combining the work of notice-replacement
with license *changing* adds undue risk; the two activities should be fully
separated by both time and workflow.

If the upshot of this *also* means we live with more GPL-1.0-or-later
notices floating around, I don't think it's that big of a deal.  Better
that than annoyed contributors, and, more importantly, downstream users
who wish to take a the more liberal license for some code in the Linux tree,
etc.

As always, IANAL and TINLA,
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

  reply	other threads:[~2019-05-22 19:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 18:40 clarification on -only and -or-later J Lovejoy
2019-05-20 18:52 ` Greg KH
2019-05-20 19:26   ` J Lovejoy
2019-05-20 21:35     ` Allison Randal
2019-05-20 22:09       ` J Lovejoy
2019-05-20 22:19         ` Allison Randal
2019-05-20 22:52           ` J Lovejoy
2019-05-20 23:15             ` Allison Randal
2019-05-21 17:24 ` Bradley M. Kuhn
2019-05-21 18:05   ` J Lovejoy
2019-05-22 13:23     ` Greg KH
2019-05-22 13:53       ` Allison Randal
2019-05-22 14:00         ` Greg KH
2019-05-22 14:20           ` Thomas Gleixner
2019-05-22 14:30             ` Allison Randal
2019-05-22 15:45               ` Greg KH
2019-05-22 19:04                 ` Bradley M. Kuhn [this message]
2019-05-22 14:22           ` Allison Randal
2019-05-22 15:03           ` J Lovejoy
     [not found]   ` <5EB6B416-F24C-4741-BC0E-6C1896E7A705@jilayne.com>
2019-05-21 21:14     ` Bradley M. Kuhn

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=20190522190442.5geeckoxfvj3fdvw@ebb.org \
    --to=bkuhn@ebb.org \
    --cc=linux-spdx@vger.kernel.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 NNTP newsgroup(s).