Apologies, but I seem to have misplaced my notes from the last meeting and never posted the minutes. I'm truly baffled as I am generally pretty well organized along this dimension. Meeting Time:

Great, Bradley. When I find someone who will *do* that work, we will definitely ask for you input! - Jilayne

<peter.williams@...> wrote: Agreed. In this general forum we've heard that the existing SPDX license list approach does not meet the needs of Linux distributions (in the case I raised,

Is that really the best choice? This issue seems to be cross functional issue in that it concerns both the license list and the technical details of representing license data in SPDX files (and in the

Polite request: Could we shift this discussion off of the General Meeting list and onto the Legal Team list only? TThis is GREAT discussion for the legal team. This is not a big problem, but I want to

Bradley, See spec http://www.spdx.org/system/files/spdx-1.0.pdf on pages 23-24. There's a section in an SPDX file called Other Licensing Information Detected to handle licenses not on the standard

As long as the licenses are - Carefully named and vetted for exact license text - Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to

SPDX files don't require that the licenses they refer to be present in the "SPDX License List". The license that you find in a source file can be represented on its own in the SPDX file. The primary

FWIW, one of our FOSSology contributors (thank you Camille) put together a spreadsheet (HarmonisationLicenseIDs.ods) highlighting the differences between the fossology license list and the SPDX

Jilayne Lovejoy wrote at 16:05 (EDT) on Wednesday: I'm not clear on what the value of SPDX's license list unless it's comprehensive. Can you explain how SPDX is still useful if the licenses for

Jilayne Lovejoy wrote at 16:02 (EDT) on Wednesday: IMO, "implementing" is trivial. The tough part is careful cataloging to know *what* to add to the list. For example, obviously, no one did the work

No, of course not. There are simply too many licenses which almost exactly correspond to existing, known licenses. It is the 'almost exactly' that raises the issue. If all of these were to be included

Do you expect the SPDX License List to cover every license you find? Does any list? It would be great to align your list with the SPDX List (and make sure the short identifiers are consistent, as the

(I have included the legal list on this response) This has been discussed a couple times and part of this issue is listed as a "to-do" on the legal

A few upfront items: At the end of Thursday's meeting Ibrahim Haddad from the Linux Foundation will brief us on the recently announced Barcode Tracker and will explain how complementary it is with

"Possibly" is not a term you want to use in a contract because it means something and its contrary. For instance we had problems of defining the i) definition of FOSS-for-contracts (I put the

Good one!

Ciaran Farrell wrote at 15:45 (EDT) on Saturday: This is interesting; I'd suspect this might be the case for other distributions, too. Debian, for example, basically has always kept a full text file

Hi Everyone, I just got back from europe. Please give me a couple days to catch up on my email and I will reply early next week. Ibrahim

To chime in on this, at openSUSE we have exactly the problem described above - we'd like to adopt SPDX, but the license list does not provide anywhere need the coverage that we need. What we've done