See today's announcement: "Red Hat, Inc. (NYSE: RHT), Facebook, Inc. (NASDAQ: FB), Google (NASDAQ: GOOGL) and IBM (NYSE: IBM) today announced efforts to promote additional predictability in open

Sorry for the long email, but I was asked for evidence... so I went and got some. David A. Wheeler: Philippe Ombredanne [mailto:pombredanne@...] The issue of having to *check* for Apache-2.0 &

David, I understand your point, but __how many times__ did you ever encounter this case in the real world? On my side, I have analyzed 1000+ significant software products, 10,000+ packages and

Trevor, You are making an excellent argument against adding this to the syntax. And I am with you there that it is OK to have it too, but unlikely needed. -- Cordially Philippe Ombredanne +1 650

If most everyone were to agree to add this, I am reluctantly OK. Technically the implementation is easy-peasy so that's not the issue. I still think these rare cases and exceptions are not

gary@... [mailto:gary@...] Yes, it does. --- David A. Wheeler

I do have a use case where being able to represent partial conclusions would be useful. As a provider of audit services, I am often confronted with unclear documentation on licensing where there is

But how many of those authors would use a partial-conclusion syntax if it existed? I expect most npm package authors are also core developers for the packaged software and know the package license.

I just completed testing all of the license XML files against the license text from the current license list or text copied from the upstream “other web pages for this license”. I found a few

David A. Wheeler: Philippe Ombredanne [mailto:pombredanne@...] Yes, there are a number of cases where it's important. The usual reason is because I'm trying to link Apache-2.0 licensed code

David: You are bringing good points. Here are my counter points: You are making assumption about what the common use case might be. To me the common use case is more simply: what's the

Philippe Ombredanne: Respectfully: There *IS* contention. I'm contending. Sure, but all summaries, and all models, omit something. Indeed, a SPDX license file *also* cannot capture all the

Hi,   I would like to now if this could make sense to add the "EDL - Eclipse Distribution License" to spdx ?   I ask the question because it seems this is a

That makes sense to me, even if it doesn't work with GitHub's current license-reporting API [1] or UI [2]. But confidence percentages are part of Licensee's output [3], so the current limitation is

As you may know, the Linux Foundation Leadership Summit is in Sonoma, March 6-8. Additionally, there will be group meetings on the Monday before and Friday after for SPDX and Open Chain

David, Speaking as the author of a fine license detection engine, I think this is a red herring. A license detection result can be: "I am 95% sure this is GPL-2.0-only but it could be GPL-2.0+:

[...] I think there is no contention there at all. A summary (e.g. a license expression) cannot ever capture all the nuances of the details.... This is a lossy "compression" by construction... ...

Sorry, hit send too soon :/. [2] was sent on Thu, 9 Nov 2017 11:54:14 -0800. [5] is at https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html Cheers, Trevor -- This email may be

I think a copy of the GPL alongside source code (e.g. [1]) is ambiguous. And the article you link mentions “confusion” in the URL, “foggy” in the title, and “ambiguity” in the subtitle.

J Lovejoy [mailto:opensource@...]: Yes indeed, that's my point :-). The tools are currently *required* to be incorrect, because they cannot report the information they have ("I have GPL-2.0,