Hi Warner, Steve: <snip/> Steve: I am siding with Warner and I do not see changing the license expression syntax adding a PUBLIC-DOMAIN as a viable solution. If anything this would lose all traceabili

Hi Jilayne: This is awesome! I guess that "LicenseRef-Fedora-Public-Domain" is now the de-facto way to use namespaces for LicenseRef in the same way I have been using them and advocating for this all

Hi: If you drop by FOSDEM, there is this one day event before FOSDEM, on Feb. 3rd 2023, in Brussels. https://opencollective.com/aboutcode/events/fosdem-2023-fringe-event-foss-license-and-security-comp

Dear David: You are not interfering at all... and I found your reply and insights super useful. I do not know your background, but it is clear that you have experience in this domain. So please do not

Hi David: Thank you for your detailed feedback. See some comments inline below: On Wed, Jun 15, 2022 at 12:16 AM David Kemp <dk190a@...> wrote: I am not sure I read you correctly but if are you

Hi Till: You have eagle eyes! <jaeger=jbb.de@...> wrote: This is IMHO a total and complete mess and non-sense, eventually non FOSS at all. Anyone from Microsoft or GitHub to fix this monstr

Steve, Max: FWIW, I already voiced my objection on this topic in the past and I think this is going to be a source of confusion and ambiguity. Why would we need to change the SPDX text for the purpose

Hi Neal! If this can help we have tracked this in ScanCode for as long as I and git can remember: https://scancode-licensedb.aboutcode.org/fraunhofer-fdk-aac-codec.html We use this SPDX identifier: Li

Dear Warner, Armijn and Jillayne: So with a bit of digging in CVS (yeah!) ... on only one file (gmatch.c), it looks like the original commit had this caldera license header alright and that must have

Hi Karsten: <karsten.klein@...> wrote: A big +1 for this. (And until then, namespaced LicenseRef- are an OK approach)

Dear Sebastian, Max: That's the source of the issue. License texts in SPDX have never been designed to be used as a reference for attribution. This is unfortunately commonly done but ends up more ofte

Alexios, Jilayne: IMHO it would be a good time to revisit this. The case of license identifier does not and never did really matter otherwise. It does not matter to users. And most tools do not care e

Hey Max, You wrote: Has this been discussed publicly? I think that you stated explicitly this is not a new license, just a clarification (optional one?) that providing both texts when referencing LGPL

Hi Richard:

Hi Warner: See some comments below. Hi Thomas: This is FYI as you may be able to provide some insights and recommendations based on the Linux kernel journey towards SPDX that could help Warner and Fre

Dear Special People Doing eXceptional things: FYI, I have been working with the Python community to specify how Python package distributions can use SPDX license expressions for their Core metadata. T

Hi Richard: Then in this case you can take the same approach as Debian's packaging: your package in d) can be under its own license unrelated to the license of the things it contains. You could state

Hi Richard: <richard.purdie@...> wrote: I think there may be a different perspective to consider: Why include the GPL text if it does not apply (or for that matter for any license)? A

Hi Jilayne: On January 31st a compliance tooling meeting and hackathon took place in Brussels before FOSDEM [1]. One of the session topics was SPDX. Everyone there agreed that SPDX license inclusion c

Dear David: David A. Wheeler <dwheeler@...> wrote: I think these are generated by this fine Python code [1] [1] https://github.com/creativecommons/cc.license/blob/a134299fdb0e882b84a2c181afc5588e1