Gary, As usual, you rock! So may be one small thing that would go a very long way would be to: 1. create a page that has links to the older versions of the LL page 2. link this "archives" page from th

One important thing (to me) that I am not sure I brought up yet: We are pushing new versions of the license lists but we are NOT keeping online the previous versions. They are only in git repos. I thi

The name is fine by me alright. Thank you all for pushing this through so quickly! And I updated ScanCode accordingly FWIW https://github.com/nexB/scancode-toolkit/tree/998-linux-openib-license

Kate: Thank you for this excellent background and research! <kstewart@...> wrote: FWIW, here is some extra information on usage of this license in these user-space packages beyond the

Hi Till, <spdx-legal@...> wrote: IMHO the correct way to handle this is with a GPL-1.0-or-later: this means the same thing to me.

Wayne, Simon, <wayne.beaton@...> wrote: The problem with the EDL is that its text is strictly the BSD-3-Clause. The only differences would be: 1. an extra name that may not be prese

I am not sure what is your use case: for me I tend to always propagate the choices... so my knee jerk reaction would be to say: do not change anything! Here, this is clearly a choice of any of the thr

Jason: The way I have treated the CRYPTOGRAMS licensing proper in the ScanCode toolkit is a set of rules for a choice of (BSD-3-Clause or GPL-1.0+) or (BSD-3-Clause or GPL-2.0) depending how this form

I guess one could run a whole scancode-toolkit scan on FreeBSD and based on the return score this would catch all the likely many other BSD variants if these are not matched with a very high score. BT

Simon: I think this has been discussed in the past: this is exactly a BSD-3-Clause. The only difference is that Eclipse gave it a name. Since this is the same it did not need to have its own ID. For i

OK, so GH licensee does not even make a serious attempt at providing accurate information and instead returns half-baked partial license information. Despite all the good intentions, I find it quite i

Bradley, FWIW, as a tool smith, I have no technical issue with combining the license and copyright holder scans and therefore returning a GPL + rider license if the holder is offering such a rider. It

Richard, say I am a user of 5,000 packages. Some of which come with this L/GPL rider, some not: I could see some value there. But then again, it may be a point minor enough that this may not be worth

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 sourc

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 billion

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.

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 exceptional

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 license? Whethe

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+: please

[...] 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... ... the