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:
Sebastien,
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
