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: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE
Date: Thu, 9 Jun 2022 08:03:02 -0700	[thread overview]
Message-ID: <YqILppVZUrD19M6D@ebb.org> (raw)
In-Reply-To: <fb857d69-b5aa-03d5-e8b0-10d734cbbfe1@jilayne.com>

Jilayne, thanks for your response!

I'd written last night:
> > Nevertheless, the flaw is big enough that it calls into question whether
> > one *can* effectively use SPDX identifiers *alone* to mark licensing
> > information for anything other than a brand-new project that has no
> > license notices yet.

J Lovejoy replied:
> SPDX identifiers are used, have been used, and will continue to be used
> effectively for many open source project as a way to express the license in
> a source file. Whether you like it or not! :)

I am actually neutral on that part of the issue.  My goal here is to make
sure licensors' rights and choices are respected.  What Fontana and I are
mainly pointing out is that replacing license notices with SPDX identifiers
has surprising consequences that we've just realized.  For example, in this
project, it leads to the Git repository as a whole needing to be part of
the CCS under GPLv2.  That outcome is not necessarily bad — it's just an
implication of linux-spdx that will surprise most redistributors.

> As for non-standard disclaimers in a license notice - this is not a huge
> problem as it seems you are making it.

It's not a numbers issue; once there is *one* of those notices that varies,
it needs to be handled somehow.

Also, does SPDX have some clear documentation that the intention is that the
SPDX identifier means not just the license text, but *also* the standard
notice as recommended by the license steward?  Maybe that documentation
should be included/linked to somewhere in the Linux tree so that folks know
that?

(While I'm no longer an active SPDX contributor, I'm pretty well versed in
SPDX (more than the average FOSS person for sure), and I didn't know that,
so I suspect it's not well known.)

> Let me put some numbers to that:
> - of the ~400 (I've lost track) licenses currently on the SPDX License List,
> only about 46 of them even have a
> - - 9 of them are GNU licenses (GPL - all 3 versions, LGPL - 2 versions,
> AGPL, and GFDL - all 3 versions)

Your set of numbers seem mainly an argument of: “copyleft licenses are often
more complex than non-copyleft ones”.  Anyway, since, as you say, Linux's
overarching license is “GPL-2.0-only” (full stop — with no additional
permissions), the key issue for this project is that GPL-2.0-only *does*
allow variable warranty disclaimers and/or notice terms.

> So, here we are - I suppose the Linux kernel is the appropriate place to
> have it come up, given that!

I agree.  But it will come up in any project licensed under a GPL Agreement.

> What would be helpful is if we (or I guess, really I) can try to ask
> lawyers versed in interpretation of these kinds of things and get some idea
> as to the scope of what changes we see here may or may not be likely to be
> consequential.

That's a useful data point to be sure, but what matters most is that
representatives of the licensors / copyright holders consent to modifying
their license notices and/or agree to switch to the standard one.

Fontana has already said that if we find a Red Hat copyright with a
non-standard warranty notice, that it *was* likely intentional and is
meaningful (though I expect in retrospect, IBM's Red Hat would be willing to
relicense with a more standard warranty disclaimer).  For linux-spdx to
be successful, it seems, it will either (a) need to contact copyright
holders of non-standard license notices to change them, (b) keep
the file in the manner designed at the April 2019 meeting, or (c)
the Git repsoitory stays part of the CCS.

All of the solutions seem workable to me.  Bugs can be fixed. :)

  -- bkuhn

  reply	other threads:[~2022-06-09 15:07 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 19:58 [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Thomas Gleixner
2019-05-21 17:58 ` Meta-question on GPL compliance of this activity Richard Fontana
2019-05-21 18:59   ` J Lovejoy
2019-05-21 21:08   ` Bradley M. Kuhn
2019-05-22  9:40     ` Thomas Gleixner
2019-05-22 13:30     ` Greg KH
2019-05-23  4:41       ` Bradley M. Kuhn
2019-05-23  5:42         ` Thomas Gleixner
2019-05-22 16:14     ` J Lovejoy
2019-05-22 21:10       ` John Sullivan
2019-05-23  1:19         ` J Lovejoy
2019-05-23  6:06           ` Thomas Gleixner
2019-05-29 20:57           ` John Sullivan
2019-05-29 21:30             ` Greg KH
2019-06-01  3:22               ` John Sullivan
2019-06-01  9:31                 ` Greg KH
2019-06-01  4:21               ` Richard Fontana
2019-05-24  4:33       ` Richard Fontana
2019-05-24  5:20         ` Greg KH
2019-05-24 20:24           ` Allison Randal
2019-05-25  1:07             ` Richard Fontana
2019-05-27 21:23               ` Allison Randal
2019-05-25 16:56             ` Greg KH
2019-05-27 21:54               ` Allison Randal
2019-05-28  7:21                 ` Dominik Brodowski
2019-05-22 13:27   ` Greg KH
2019-05-22 14:16     ` Thomas Gleixner
2019-05-22 16:33       ` J Lovejoy
2019-05-22 16:52         ` Thomas Gleixner
2019-05-22 17:00           ` J Lovejoy
2022-06-06 20:11 ` [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Richard Fontana
2022-06-06 20:17   ` Thomas Gleixner
2022-06-07 18:12     ` Bradley M. Kuhn
2022-06-07 23:05       ` Thomas Gleixner
2022-06-08  8:33         ` Allison Randal
2022-06-08 14:04           ` Bradley M. Kuhn
2022-06-08 14:59             ` Allison Randal
2022-06-08 17:18               ` Bradley M. Kuhn
2022-06-08 18:54                 ` Richard Fontana
2022-06-08 19:29                   ` Bradley M. Kuhn
     [not found]                     ` <02f4021f-63a5-4796-d790-2bacd37b90d2@jilayne.com>
2022-06-09  0:31                       ` Bradley M. Kuhn
2022-06-09  4:51                         ` J Lovejoy
2022-06-09 15:03                           ` Bradley M. Kuhn [this message]
2022-06-09  2:35                       ` Richard Fontana
2022-06-06 20:31   ` 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=YqILppVZUrD19M6D@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).