A suggestion to use Relationships for the licence variants use-case
|
Dear all,
On our joint SPDX Legal/Tech meeting today, one of the use-cases that was discussed was No.6: "issue of capturing variants of licenses which match the same listed license per the matching guidelines" It was one of the use-cases for which solving with licence namespaces was least well received (by the informal poll we did). I would like to suggest an alternative solution: to add a couple of new SPDX Relationship types, which could be much more palatable than the much more wider-scope change of licence namespaces. As I understood it, the original suggestion was for the facility to 'group' licence texts together within a licence namespace if they all match each other (as per our matching guidelines), but are textually or visually different in non-substantive ways. My suggestion is to add two new Relationship types: - MATCHES_LICENSE: Relationship: LicenseRef-Weirdly-Formatted-BSD MATCHES_LICENSE BSD-2-Clause ...meaning a claim that LicenseRef-Weirdly-Formatted-BSD is identical to BSD-2-Clause as per the matching guidelines, yet one made in a way that allows the exact text found (complete with weird formatting) to be defined in the SPDX document under LicenseRef-Weirdly-Formatted-BSD. - LEGALLY_EQUIVALENT_TO Relationship: LicenseRef-MIT-With-Spelling-Mistake LEGALLY_EQUIVALENT_TO MIT ...meaning that, although LicenseRef-MIT-With-Spelling-Mistake is a different licence (as per the matching guidelines) to MIT, the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent. It could be said that the MATCHES_LICENSE Relationship type need not exist, since anyone could simply run a licence matching tool over the text themselves. However, the ability to limit the computational time spent matching to only licences that have been claimed to match could still be helpful; being able to make an explicit claim of a match seems like a benefit too. In general, it isn't good to add Relationships types if they aren't needed, but the fact that people want to communicate this suggests a strong reason to add (and thus standardise) the type. I think it's definitely within scope for SPDX. I'd love to hear any questions/feedback about this suggestion, and especially to hear whether it would indeed enable some use cases of the meeting's attendees! Best wishes, Sebastian |
|
|
|
Sebastien,
toggle quoted message
Show quoted text
LEGALLY-EQUIVALENT-TO bothers me since "the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent" - if I understand that these tags are being assigned by the vendor, do I trust their legal determination? MATCHES_LICENSE also bothers me because it feels so binary. But I may be nitpicking there. I would be more inclined to SIMILAR_LICENSE. Best regards, Ria Farrell Schalnat Open Source Program Manager Hewlett Packard Enterprise ria.schalnat@... -----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane Sent: Friday, June 3, 2022 2:22 PM To: SPDX Legal Mailing List <spdx-legal@...>; SPDX Technical Mailing List <spdx-tech@...> Subject: A suggestion to use Relationships for the licence variants use-case Dear all, On our joint SPDX Legal/Tech meeting today, one of the use-cases that was discussed was No.6: "issue of capturing variants of licenses which match the same listed license per the matching guidelines" It was one of the use-cases for which solving with licence namespaces was least well received (by the informal poll we did). I would like to suggest an alternative solution: to add a couple of new SPDX Relationship types, which could be much more palatable than the much more wider-scope change of licence namespaces. As I understood it, the original suggestion was for the facility to 'group' licence texts together within a licence namespace if they all match each other (as per our matching guidelines), but are textually or visually different in non-substantive ways. My suggestion is to add two new Relationship types: - MATCHES_LICENSE: Relationship: LicenseRef-Weirdly-Formatted-BSD MATCHES_LICENSE BSD-2-Clause ...meaning a claim that LicenseRef-Weirdly-Formatted-BSD is identical to BSD-2-Clause as per the matching guidelines, yet one made in a way that allows the exact text found (complete with weird formatting) to be defined in the SPDX document under LicenseRef-Weirdly-Formatted-BSD. - LEGALLY_EQUIVALENT_TO Relationship: LicenseRef-MIT-With-Spelling-Mistake LEGALLY_EQUIVALENT_TO MIT ...meaning that, although LicenseRef-MIT-With-Spelling-Mistake is a different licence (as per the matching guidelines) to MIT, the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent. It could be said that the MATCHES_LICENSE Relationship type need not exist, since anyone could simply run a licence matching tool over the text themselves. However, the ability to limit the computational time spent matching to only licences that have been claimed to match could still be helpful; being able to make an explicit claim of a match seems like a benefit too. In general, it isn't good to add Relationships types if they aren't needed, but the fact that people want to communicate this suggests a strong reason to add (and thus standardise) the type. I think it's definitely within scope for SPDX. I'd love to hear any questions/feedback about this suggestion, and especially to hear whether it would indeed enable some use cases of the meeting's attendees! Best wishes, Sebastian |
|
|
|
Dear Ria,
LEGALLY-EQUIVALENT-TO bothers me since "the producer of the SPDXIndeed, LEGALLY_EQUIVALENT_TO would express a legal interpretation made by the SPDX document productor (which could be the vendor of the software or a third party). Whether or not this is to be trusted is up to the consumer of the SPDX data, in the same way as with the existing 'License Concluded' field in SPDX 2.2.2: https://spdx.github.io/spdx-spec/package-information/#713-concluded-license-field MATCHES_LICENSE also bothers me because it feels so binary. But I mayI'm perfectly comfortable with using another name, although I would like to clarify: I was intending this to be matching in the sense of the SPDX Matching Guidelines (Annex B in SPDX 2.2.2). If I recall correctly, the Matching Guidelines don't specify anything other than 'yes, the same license' or 'no, a different license'. Thank you for taking a look at this; please let me know if I missed/misunderstood anything in your response :) Best wishes, Sebastian |
|
|
|
Steve Winslow
Hi Sebastian, thanks for this — this is an interesting proposal! I want to give it some more thought, but here are a couple initial reactions: For MATCHES-LICENSE, I gather the idea is that this is intended to be a signal that the custom license text “matches” the other license based on the SPDX Matching Guidelines [1]. So to Ria’s comment, it would intentionally be a binary yes/no based on the application of those guidelines. I like this as an idea, though it also occurs to me that (1) the Document creator could be wrong, and (2) the Document receiver could determine it themselves by applying the guidelines themselves. Even so, I could see this potentially being valuable. For LEGALLY-EQUIVALENT-TO, I share Ria’s instinctive cringing at having that be encoded in a Document :) I imagine that producers would be hesitant to use this and consumers would be hesitant to rely on it. More relevant, though, at least for current SPDX scope the spec says that legal interpretation is out of scope [2], and if tend to include this in that bucket. The one other thought is more technical: currently I gather Relationships are between SPDX Elements with SPDXRef- identifiers, which doesn’t include licenses. So I’d guess this wouldn’t be compatible with 2.x, but perhaps could be for 3.0. Interesting idea — we should give it some more thought! Steve On Jun 3, 2022, at 5:43 PM, Ria Schalnat (HPE) <ria.schalnat@...> wrote:
|
|
|
|
Phil Odence <phil.odence@...>
Steve captures my same reactions well.
From:
Spdx-legal@... <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...> Hi Sebastian, thanks for this — this is an interesting proposal! I want to give it some more thought, but here are a couple initial reactions:
For MATCHES-LICENSE, I gather the idea is that this is intended to be a signal that the custom license text “matches” the other license based on the SPDX Matching Guidelines [1]. So to Ria’s comment, it would intentionally be a binary yes/no based on the application of those guidelines. I like this as an idea, though it also occurs to me that (1) the Document creator could be wrong, and (2) the Document receiver could determine it themselves by applying the guidelines themselves. Even so, I could see this potentially being valuable.
For LEGALLY-EQUIVALENT-TO, I share Ria’s instinctive cringing at having that be encoded in a Document :) I imagine that producers would be hesitant to use this and consumers would be hesitant to rely on it. More relevant, though, at least for current SPDX scope the spec says that legal interpretation is out of scope [2], and if tend to include this in that bucket.
The one other thought is more technical: currently I gather Relationships are between SPDX Elements with SPDXRef- identifiers, which doesn’t include licenses. So I’d guess this wouldn’t be compatible with 2.x, but perhaps could be for 3.0.
Interesting idea — we should give it some more thought!
Steve
|
|
|