Should we require imports for SPDX defined individual elements?

[goneall]

In SPDX 2.X we allow references to listed licenses and listed exceptions without referencing the external document(s) containing these definitions.

In SPDX 3, the spdx3-validator looks for import statements for all element URIs not defined within the document.

In addition to the license list, the SPDX organization element would also need to be added to imports if it is used.

[goneall]

My opinion is that we should exempt any SPDX standard defined elements for the import requirement. and SPDX standard defined element would have a pre-defined URI prefix or namespace.

Otherwise, the SPDX serialized files will become unnecessarily verbose.

This would require an update to the spdx3-validator.

[bact]

Agree that we should have a set of "default imports" and pre-defined URI prefix/namespace.

• See also Specify spdx prefix names in model Turtle file ("@prefix ns2" -> "@prefix spdx-sw") spec-parser#157

[zvr]

@goneall the spec defines a number of Individuals (like the organization you mentioned, but also the None and NoAssertion Elements and licenses). Since SPDX data may be using these, these should be included in the validation data.

And when the ExtendedLicensing profile is used, depending on the License List version used, a corresponding set of definition for licenses and expressions should also be included in the data being validated.

I am not sure of the best alternative technically to achieve this inclusion.

[zvr]

@bact I don't think this has anything to do with namespaces and imports.

[goneall]

In the SPDX Java library, we have an option to copy the full license definitions when referencing a listed license or listed exception.

Since we're now publishing JSONLD files for all the licenses and exceptions we could make an external reference with the requisite import statements if the option to copy is set to false.

I think this would be an acceptable additional level of complexity since we're already opting to use the more complex license expressions.

[goneall]

For the individuals, I'm more concerned about requiring copies or imports.

Currently, we require SPDX documents to include a few extra lines to point to the context file. Adding the definitions would add a significant amount of "boilerplate" that would probably be present in every file.

I'm not sure it would save a lot, however, having boilerplate imports for individuals defined outside the serialized file.

[zvr]

@goneall you wrote:

Since we're now publishing JSONLD files for all the licenses and exceptions we could make an external reference with the requisite import statements if the option to copy is set to false.

That's the part I know nothing about... Can you "include" more data in any way? You seem to say that you can "import" them.

But the JSON-LD specification only uses @import for a context file, i..e defining string shortcuts, not for including more data.

[goneall]

@zvr

That's the part I know nothing about... Can you "include" more data in any way? You seem to say that you can "import" them.

But the JSON-LD specification only uses @import for a context file, i..e defining string shortcuts, not for including more data.

A different import - the SPDX document import.

If we were to reference the import, it would look something like the following for a reference to the BSD-3-Clause license:

"import" : [ {
      "type" : "ExternalMap",
      "verifiedUsing" : [ {
        "type" : "Hash",
        "algorithm" : "sha1",
        "hashValue" : "fdf31b9758c7aa2ca498f205d0be28f4906b46ec"
      } ],
      "externalSpdxId" : "http://spdx.org/licenses/BSD-3-Clause",
      "locationHint" : "https://spdx.org/licenses/BSD-3-Clause.jsonld"
    }

[goneall]

Note that this is related to #932 since any import would require the SpdxDocument.

[zvr]

Ah, right! But wouldn't the solution be, as I wrote above

when the ExtendedLicensing profile is used, depending on the License List version used, a corresponding set of definition for licenses and expressions should also be included in the data being validated

I mean, rather than manually include the single licenses you're referring to, include the license list (an SPDXDocument that defines them all).