Thank you Gary. That was quick!

Excellent! Note that none of the generated files are valid HTML. See http://spdx.org/licenses/Glide for instance With the .html extension, the browsers deal with the quirks somehow: http://spdx.org/li

How about ~ 6000+ pages on Google [1] and ~ 90.000+ files in Github [2]? [1] https://www.google.com/search?q="intended for use in the design%2C construction%2Coperation or maintenance of any nuclear f

<tom.incorvia@...> wrote: Agreed for me: this should be in either as a license or an exception I agree ++ and practicality beats purity.

I am not a lawyer and I see several claiming on this list that this license would not comply with various FLOSS definitions. But how this extra clause would be a use restriction of any kind? If I am r

[...] David: I know this as I was part of it and that does not make it more right ... FWIW, I have been around SPDX for quite a while ;). See "A Short History of SPDX": https://spdx.org/about-spdx/wha

I am not confusing these at all. The gist of what I am saying is that the plus is a legacy that should not be there. It does not make sense to add to the large majority of GPL in the wild a + just to

Gary, I cannot envision a simpler implementation than splitting on spaces. A plus sign specified as a suffix that is not attached to a license key would no longer be a suffix to me, but something enti

<tom.incorvia@...> wrote: Yes, exactly that, and the related text found in the proposed notice text found at the end of the GPL text: ======================== This program is free software;

On Mon, Nov 2, 2015 at 7:02 PM, Gary O'Neall <gary@...> wrote: This + is a suffix and not a freestanding character, right? So "GPL-2.0+" is valid but "GPL-2.0 +" would not be valid? In t

David: I think you are misquoted my reply for being from Sebastian. Pardon me, but I think the text(s) of the GPL define how the the software is licensed... As I said initially I agree this is indeed

<sebastian.schuberth@...> wrote: I not see any reason why a + would not be allowed in a reference, and there is no ambiguity since the + always something attached to an id or ref string, not some

Yes and No: ScanCode uses an SPDX-inspired/derived markup, but instead of reusing the markup directly from the main license texts, markup is transformed in a simpler {{mustache-like}} syntax added to

Jilayne: The subsequent comments are fine indeed. I still think that markup for detection and reference texts would be best handled separately in the long run, yet the volume is still rather low and G

Adding matching markup inside the reference license texts will eventually lead to un-resolvable conflicts: - markup will make a license text no longer a reference - it will make it less readable or un

Here is my understanding of how the "AND" thread started: Mark brought up a concern about the meaning of AND. He felt this could be misleading to have to say AND in a top level package without details

On Fri, May 15, 2015 at 12:57 AM, Alan Tse <Alan.Tse@...> wrote: IMHO yes. This is really left to the SPDX authors to provide the level of details they want to provide. More is better but not mand

One more thing to consider for this "technically-an-exception but exceptionally treated in SPDX as a regular-license-and-not-an-exception".... From the license text: "This version of the GNU Lesser Ge

This would indeed be accurate but both odd and confusing. This is IMHO the only sane thing to do. Practically beast purity. #2 aka LGPL-3.0 is the only thing that makes sense to me.

Sam: I agree with you, both licenses are common enough in the wild. Both the MD4 and MD5 notices are found in RFCs, which is a good reference URL IMHO as they were crafted and submitted there by Ron R