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

[1] https://spdx.dev/license-list/matching-guidelines/
[2] 
https://spdx.github.io/spdx-spec/composition-of-an-SPDX-document/#53-what-this-specification-does-not-cover


> On Jun 3, 2022, at 5:43 PM, Ria Schalnat (HPE) <ria.schal...@hpe.com> 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.schal...@hpe.com
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Spdx-legal@lists.spdx.org <Spdx-legal@lists.spdx.org> On Behalf Of 
> Sebastian Crane
> Sent: Friday, June 3, 2022 2:22 PM
> To: SPDX Legal Mailing List <spdx-legal@lists.spdx.org>; SPDX Technical 
> Mailing List <spdx-t...@lists.spdx.org>
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3142): https://lists.spdx.org/g/Spdx-legal/message/3142
Mute This Topic: https://lists.spdx.org/mt/91530333/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to