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
