Dear Richard, Thank you for your reply and for including Joshua.
For us at Karl Storz it would be most convenient to have the extratedText always populated, but in my opinion this can't be the default behaviour because it would go against the SPDX standard, or at least its intent. The extractedText is part of section 10 - Other licensing information, where it says: ...to refer to licenses that are not found on the SPDX License List. What I was proposing is to add as switch like SPDX_ALWAYS_EXTRACT_LICENSE ??= "0", that, if enabled, would override the standard behaviour and slightly abuse said property by always including the extracted license, even if the license has been identified as one of the known licenses. Then, how strict the license matching should be, can be another discussion. On the other hand, if it were at least as strict as the regulatory bodies, we could reconstruct the license text close enough, and that would be a solution too. Best Regards, Wolfgang Brehm ________________________________ From: Richard Purdie <[email protected]> Sent: 13 July 2023 13:02 To: Brehm, Wolfgang <[email protected]>; [email protected] <[email protected]> Cc: Joshua Watt <[email protected]> Subject: [Ext] Re: [OE-core] extractedText for every License in SPDX Hi, I've copied Joshua on this so he sees it since he's done a lot of work on that class. On Thu, 2023-07-13 at 09:29 +0000, Brehm, Wolfgang wrote: > We at Karl Storz need to provide the literal license text for each > software component we use, for legal reasons. There is a property > "extractedText" in the SPDX documents, but it is only meant to be > populated when the license is not a standard license. However even > for non-standard licenses like MIT, the license text can differ from > project to project. > I'm about to modify create-spdx-2.2.bbclass so that it would always > extract the license no matter what, similar to what they did in Mend > (formerly WhiteSource): > https://urldefense.com/v3/__https://github.com/whitesource-ps/ws-sbom-generator/issues/96__;!!Lw1uGqvHvtJ_psGG2Et-1voSwbo!c72CXUOogiQCPQrUf2WMXpPxSYvvWpPhGXfxRbBUipMXsJAgTUwZ0W0gK4b3F54M7jiL0bX5fKkST6flNevCrfnxW7KjAWdjYe1gvxl1nA$ > Would you be open for a patch and what do I need to do to improve the > chances of a patch being accepted, other than sticking to the style > obviously? I think the challenge will be knowing if the text differs from the standard license. Is this a word for word comparison or a byte for byte, i.e. does whitespace matter? What about things like copyright dates? The net end result will likely be that the that the comparison will be pessimistic and end up including it most of the time. That will then mean larger SPDX files and more data for people to process. I'm not necessarily against that but I do worry that if we dump all this information at the end users, it is going to make it hard to them to work out the things they really need to pay attention to. I appreciate there are regulatory requirements and legal departments which will require the exact text but we also need to consider the actions people take based upon this. The likely action is to map it back to some known "good" list :/. The end next result is a lot more data passing around which nobody will actually need to use in reality. So I'm not against patches being proposed or merged but I worry about the overall effect on the ecosystem. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184246): https://lists.openembedded.org/g/openembedded-core/message/184246 Mute This Topic: https://lists.openembedded.org/mt/100117146/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
