linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: J Lovejoy <opensource@jilayne.com>
To: "Bradley M. Kuhn" <bkuhn@ebb.org>, 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: Wed, 8 Jun 2022 22:51:53 -0600	[thread overview]
Message-ID: <fb857d69-b5aa-03d5-e8b0-10d734cbbfe1@jilayne.com> (raw)
In-Reply-To: <YqE/aNK+YXH1Bs5n@ebb.org>



On 6/8/22 6:31 PM, Bradley M. Kuhn wrote:
> J Lovejoy wrote today:
>>   a second question of: and then how does "capturing it in some way" get
>> practically implemented?)
>> We are NOT answering the second question at this point in time.
> Nor did I expect you to have an answer for that question this quickly!  (But,
> hopefully we agree it's a really important question!)
I agree it is something that deserves attention and careful thought, yes.
("really important" is relative and at this time of night, other things 
that have nothing to do with
licensing of software may be really important. like going to sleep! :)
>
> I think Fontana and I just for the first time stated clearly the root cause —
> namely: the inability for SPDX identifiers to capture non-standard
> disclaimers.  (I suspect this is something that no one noticed when this
> issue was debated previously [0].)
>
> 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.
*sigh* I am well aware that you are not a fan of SPDX (nor me, 
probably), but let's please not over-state this.
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! :)

As for non-standard disclaimers in a license notice - this is not a huge 
problem as it seems you are making it.
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
standard license notice (defined in the SPDX License List as, "text 
intended to be put in the header of source
files or other files as specified in the license or license appendix 
when specifically delineated")
- of those approx 46, about 30 have some form of disclaimer type 
language (I was being generous here)
- of those 30:
- - 9 of them are GNU licenses (GPL - all 3 versions, LGPL - 2 versions, 
AGPL, and GFDL - all 3 versions)
- - then there's Apache-2.0
- - and the rest are old (e.g. SISSL, CPAL), rarely used, and/or 
entity-specific licenses (APSL, W3C).
So that's really only 10 licenses that are in use.

I have not seen this be an issue with Apache-2.0 and I doubt it's so 
much an issue with GFDL, so we are really only talking about this 
potentially being an issue with GPL and LGPL.

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

>> #1 QUESTION: How much deviation from the language in the text of the
>> standard header for GPL rises to the level of being legally significant to
>> warrant capturing it in some way?
> If anyone but the copyright holder and/or original placer of the warranty
> disclaimer makes this determination, there is increased risk of McHardy-style
> lawsuit.  So, while I agree with your other point that it's a risk
> assessment, the stakes are presumably rather high here.
Whether this increases the risk or whether the stakes are considered 
high or not is all part of a risk assessment.
Assessing risk is not simply - could a bad thing happen, it's also looks 
at the likelihood of it happening and the impact, etc.

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.
>
> OTOH, if everyone is cool with the idea of the Git repository being part of
> the CCS, I think that's a fine solution from my perspective.
That is answering the second question before we've answered the first. 
In any case, your position is heard on this part! ;)

Cheers,
Jilayne

  reply	other threads:[~2022-06-09  4:51 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 [this message]
2022-06-09 15:03                           ` Bradley M. Kuhn
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=fb857d69-b5aa-03d5-e8b0-10d734cbbfe1@jilayne.com \
    --to=opensource@jilayne.com \
    --cc=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).