License Expression References to Custom Licenses

[goneall]

How do we represent LicenseRef- custom licenses in the string license expressions?

In SPDX 2.X, the interpretation of the custom licenses is very dependent on the SPDX document containing the reference. We key off the specific string LicenseRef- to determine it is a custom license and know we can find the definition within the document itself. If it is defined outside the document we use a namespace technique of ExternalDocumentIdX:LicenseRef-xxx.

Since the license expressions an be created without an enclosing document, we need a way of identifying the local licenses and finding the license definitions. This could be done by requiring the fully expanded URI's - but that would make for some rather unwieldy expressions.

[goneall]

This issue was move from this comment in issue #372

[davaya]

If license expression strings are to be portable then the individual terms that appear in the string must be globally unique. So the challenge is to map full globally unique IRIs to short globally unique strings, and the shorter those strings are the less meaningful they can be. So is "L13Y4EK95c0si" an acceptable ID for use in expressions like "Apache-2.0 OR L13Y4EK95c0si"? The base64-encoded 64-bit unique ID can be mapped to 2^64 full IRIs if everyone agrees to a managed mapping and meaningless terms.

The term could be shorter (e.g., 32 bits/6 characters, plus optionally a few mnemonic characters) and the mapping just be a truncated hash of the IRI to get started,, but the shorter the term is the sooner collisions occur and the greater the need for the Custom License Registry.

[goneall]

Here's a proposed solution:

• Add an mapping property to the LicenseExpressionClass customIdToUri which would use the ID in the license expression as the key (e.g. LicenseRef-xxx or AdditionRef-xxx) and have the URI for that ID as the value.
• Serializations can apply the same optimization as used for the creationInfo field to reduce redundant information
• License expressions will still be required to prefix any custom license or addition with LicenseRef- and AdditionRef- to allow for unambiguous deserialization.

Since the mapping property is local to the LicenseExpressionClass we don't run into the same conflicts as the NamespaceMap.

Translating from SPDX 2.X to SPDX 3.0 would be straightforward.

This allows license expression strings to be present in single elements.

I believe it is lossless.

@maxhbr @zvr - thoughts?

[maxhbr]

Not sure if that results in a to complex structure. Not sure if that would be accepted.

[goneall]

Not sure if that results in a to complex structure. Not sure if that would be accepted.

Is there a way to test this?

BTW - I'm open to other proposals, but this is the only one I can think of that would work within the JSON-LD serialization.

[goneall]

@zvr @maxhbr - Could we discuss this on tomorrow's serialization call?

[zvr]

Isn't "LicenseRef-1" the value of the name property of the CustomLicense object ?

[goneall]

Example for the proposal above:

Expression BSD-3-Clause and LicenseRef-1 with AdditionRef-2, the LicenseExpressionClass properties would have the following JSON fields (in addition to any of the Element properties):

{
    "customIdToUri": [ 
        { "LicenseRef-1" : "https://myuriforspdx/licenses/customer/someLicense" },
        { "AdditionRef-2": "http://scancode.io/scancode-addition" },
       ],
    "licenseExpression": "BSD-3-Clause and LicenseRef-1 with AdditionRef-2",
...
}

[goneall]

Isn't "LicenseRef-1" the value of the name property of the CustomLicense object ?

I would think it would be part of the ID leaving the name open to a more human readable name.

[goneall]

From the serialization call, there were no alternatives to this proposal, so I'll work on a pull request to implement.

[swinslow]

Isn't "LicenseRef-1" the value of the name property of the CustomLicense object ?

I would think it would be part of the ID leaving the name open to a more human readable name.

@goneall +1 -- I think "LicenseRef-" would be the prefix for the ID, whereas the name could be anything. I think that's in line with the existing "Other Licensing Information" structure for 2.3, which I'd think is the intent here.

[maxhbr]

As far as I understood, this plan here contains no restrictions on the actual SPDXID of the Element representing the custom license (SPDXID="https://myuriforspdx/licenses/customer/someLicense" in the example above), but instead proposes to have a local mapping for every license expression (where "LicenseRef-1" is linked to the ID above)

@swinslow : as you just wrote I think "LicenseRef-" would be the prefix for the ID, there might be still a mismatch. Ar you calling the alias used in the expression ID or do you talk about the actual SPDXID?

[goneall]

As far as I understood, this plan here contains no restrictions on the actual SPDXID of the Element representing the custom license (SPDXID="https://myuriforspdx/licenses/customer/someLicense" in the example above), but instead proposes to have a local mapping for every license expression (where "LicenseRef-1" is linked to the ID above)

@maxhbr - you are correct

As far as I understand, this will have no effect on the actual expression string syntax and semantics. You still need to have an "ID" (not the SPDX URI ID, but an ID used to map to the full URI ID) that starts with "LicenseRef-".

You have to create a unique URI for the custom license in any case. I don't see any way around it since we no longer have the SPDX document to lean on for providing a standard prefix.

We could create a restriction on the URI ID for the custom license, but I don't see any benefit in the 3.0 model.

[goneall]

@swinslow @maxhbr @zvr - thoughts? Is this something we should queue up for a discussion?