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

spdx / spdx-spec

The SPDX specification in MarkDown and HTML formats.

https://spdx.github.io/spdx-spec/

Other

282 stars 135 forks source link

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

Open kestewart opened 7 years ago

kestewart commented 7 years ago

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 commented 7 years ago

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 commented 5 months ago

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

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

swinslow commented 5 months ago

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.)