Need to be able to describe relationships between SPDX license-list files (new element?)

[kestewart]

Problem: how do we capture sets of related licenses, esp. Translations

• Proposed solution: treat every license as separate file, then describe relationship w/ new element?
• Any way to describe relationships among license groups such as official/unofficial translations, ported/unported, etc.?
• For EU Public License in German, that might look something like this:

   <relatedLicenses>
      <relatedLicense relationshipType="official-translation" targetLicenseIdentifier="EUPL-1.1">EUPL-1.1</relatedLicense>
   </relatedLicenses>
   ...
   Note: Up to 24 for EUPL, etc.

• Could this include license stacks (like newlib)? License stacks used as licenses? How to differentiate from license stacks used as informal package-license manifests?

[kestewart]

From discussions in brainstorming google doc

• May 16 - Thomas is interested in help here, but Gary will take point on it.
• May 16 - Kate: Separate spec or appendix for license list representation?
• May 23 - Gary: xml input - with rdf & json format output being used. Key is maintaining the same property names. Spec out what rdf will look like in addition to xml. Use same terms from spec, so bias is to making it an appendix in next rev.

[goneall]

I believe this is non-breaking - so moving to 3.1.

@kestewart - if you disagree, please move back to the 3.0 milestone.

[swinslow]

To the extent this was about representing "official translations" of licenses, there was a discussion in license-list-XML at https://github.com/spdx/license-list-XML/issues/438 about this a few years ago, with the general outcome deciding not to implement changes to the license-list-XML fields or syntax.

If there is anything here to be discussed, I'd be inclined to suggest moving the discussion to license-list-XML since I suspect that's where any changes would be implemented. (At least, unless / until the license-list-XML fields are documented formally as part of the spec itself, which I think may be part of what #32 is about.)