Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

J Lovejoy <[email protected]>
Newsgroups org.kernel.vger.linux-spdx
Message-ID <[email protected]>

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.