Bradley: this is an excellent offer and idea. Please go for it!

<jbuttura@...> wrote: Jason: there is a good reason for this: The use of the V1.0 license was limited to a brief period in time and a long seven years ago. Cases of actual reuse of code under th

<tom.incorvia@...> wrote: This is an interesting case. I am not sure that we should support as broad a list as possible. The current SPDX spec has support for direct reference (LicenseRef)

I reckon there is a value in having a comprehensive and universal list of licenses, but I sincerely doubt this is something that should in the SPDX list as it is today, for the reasons I mentioned in

Let me bring my 2 cents to the discussion. A while back I wrote down this little language to compose licenses. The point was to : - make this easy enough for humans and machines to read, write and und

Guten Tag Wolfgang! and thanks for your feedback. You are absolutely right there and being a programmer I had hesitated a little about the implications then, and thought that it would be OK to forego

Exactly! The intent when I wrote down an example starting with "I think" is to show where such a syntax could capture eventual interpretations that a user/adopter of SDPX would want to express. I am N

<michel.ruffin@...> wrote: Michel: My 2 cents, I would possibly express this either: * as lplg-2.1+ {mit bsd-3-clause and a long list of licenses .... } using my 'little language' OR *

Howdy:! I am replying on the legal list that would be the right place ... Thank you and good point ... this is the original URL, but ever since Oracle bumped it to 1.1 it has disappeared... as many ot

The only material difference with BSD-3-Clause seems to be in the disclaimer : [...] FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE DISCLAIMED [...] where "AND NON-INFRINGEMENT" is added I

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

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.

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

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

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

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

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

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

<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

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