Yes, added. As for the previous versions – even the Code Project website itself doesn't have the text of those, but just a note explaining the changes, which sound minor (see below). We can

Back to a point that Phlippe made earlier, while we are not really taking sides, I certainly do not think SPDX should be party to encouraging license proliferation. It would probably make sense for us

Thanks Zak! Hi Jilayne, This appears to meet all of the criteria. Would you please put on the agenda for the next legal teleconference? As Zak notes, there is a CPOL 1.00 and 1.01, but

Dear SPDX-Legal, I attended an SPDX-Legal call for the first time last week and I look forward to attending further meetings and making contributions to the group. In compliance with the process for

I think that the best way to implement this in the future is to be able to specify domains in the identifiers. Something like ninka.bsd3, fossology.afossolyname, spdx.bsd3 and default the domains to

The SPDX Legal Team will be have a face-to-face meeting Tuesday afternoon at the Linux Collab Summit in San Francisco. (exact time, TBD) We will endeavor to finish work on the License Matching

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

It seems this is part of this use case http://spdx.org/wiki/license-list-extension Does [OK] mean it will supported by SPDX 2.0 ? If yes, I guess that it means that implementation for SPDX 2.0 will

<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 fully agree on this, all licenses should be on the list (including Licenses such as Oracle Binary License). A prefix to identify local/private maintained licenses would be great. è use one license

Hi Guillaume and SPDX Legal, I believe that we will be best served by having as broad a license list as possible, and to have every license on the list be supported. If the Leptonica license

Guillaume, We will be putting out a more formal announcement with details this week, but yes, there will be a fair amount of SPDX activity including fact to face at the Collaboration Summit starting

Guillaume, You have to request an invitation here: https://events.linuxfoundation.org/events/collaboration-summit/request-an-invitation Martin * Guillaume Rousseau <guillaume.rousseau@...>

Jilayne, Ibrahim, Phil, I wonder if you have some "seat available" during summit for people attending spdx face2face meetings ? If yes, I can check if I can arrange a short trip,

Indeed we have been many time through the issue concerning "rare license". I understand very well that spdx can not cover/support every licenses. But should be able to extend internal

This license text appears to be from Leptonica: https://github.com/rajbot/autocrop/blob/master/leptonica-1.68/leptonica-license.txt The tortured grammar of this sentence is unique and I don't think

We came across this license in a recent open source review. Fossology mis-identified this as GPL which is clearly a bug and it's being fixed. However, my question is... would this match any

Yes, Phil and Tom are correct that we should list both versions. This is precisely what we did for the French and English versions of the Cecil license. I did think of this yesterday on the call,

Hello Till, Thanks for being engaged. One of the principles of the SPDX license list is that there is a reliable short identifier, full name and exact text match (other than white space and some

It seems to be we should have two licenses on the list each with its own text for matching purposes. Perhaps: D-FSL-1.0 - Deutsch FSL auf Deutsch G-FSL-1.0 - German FSL in English