SPDX as package manifest does not work for CONTAINS relationship

[kikofernandez]

Describe the bug

I create a SPDX as a package manifest (spdx/spdx-spec#439) and the relationship DESCRIBES does not appear in the analyzer output result (because of this, it does not appear either in scanner nor in a final SPDX report)

To Reproduce

Steps to reproduce the behavior:

1. Using as example Elixir language, create the following SPDX package, which simply helps to create some structure for the end result SPDX report.

https://github.com/elixir-lang/elixir/blob/main/project.spdx.yml#L156-L174

2. ./gradlew --no-configuration-cache cli:run --args="analyze -i elixir -o . -f JSON"
3. Observe how the end result does not contain any relationship. (But if we use the STATIC_LINK, the analyzer does create that relationship in the analyze-result.json)

Expected behavior

Expected the contains relation to appear in the analyze-result.json and also in the final SPDX report

Environment

• ORT version: 51
• Java version: 21.0.5
• OS: Ubuntu

And specify (relevant parts of) your ORT configuration (config.yml):

Elixir config link, copy-paste below

# SPDX-License-Identifier: Apache-2.0
# SPDX-FileCopyrightText: 2021 The Elixir Team

ort:
  enableRepositoryPackageCurations: true

  scanner:
    skipConcluded: false
    includeFilesWithoutFindings: true

  analyzer:
    allowDynamicVersions: true
    enabledPackageManagers: [SpdxDocumentFile]
    skipExcluded: true

Comments

I have observed the same thing for Erlang/OTP and other projects where I tried to create CONTAINS relationships.
Another example is this fork of jesse, and this is the SPDX manifest (here):

SPDXID: "SPDXRef-DOCUMENT"
spdxVersion: "SPDX-2.2"
creationInfo:
  created: "2025-02-25T10:13:22Z"
  creators:
  - "Organization: Example AB"
  licenseListVersion: "3.26"
name: "jesse-code"
dataLicense: "Apache-2.0"
documentNamespace: "http://spdx.org/spdxdocs/spdx-document-jesse"
documentDescribes:
- "SPDXRef-Project-Jesse"
packages:
- SPDXID: "SPDXRef-Project-Jesse"
  description: "Jesse JSON Schema Validator"
  copyrightText: "Example"
  downloadLocation: "git+https://github.com/kikofernandez/jesse.git"
  filesAnalyzed: true
  homepage: "https://github.com/kikofernandez/jesse.git"
  licenseConcluded: "Apache-2.0"
  licenseDeclared: "Apache-2.0"
  supplier: "Organization: Example"
  originator: "Organization: Example"
  name: "jesse-project"
  versionInfo: "6"
  packageFileName: "./"
- SPDXID: "SPDXRef-Package-jesse-doc"
  description: "Test"
  copyrightText: "Example"
  downloadLocation: "git+https://github.com/kikofernandez/jesse.git#doc"
  filesAnalyzed: true
  supplier: "Organization: Example AB"
  originator: "Organization: Example AB"
  homepage: "https://github.com/for-GET/jesse"
  licenseConcluded: "Apache-2.0"
  licenseDeclared: "Apache-2.0"
  name: "jesse-doc"
  versionInfo: "6"
  packageFileName: "./doc"
- SPDXID: "SPDXRef-Package-jesse-src"
  description: "Test"
  copyrightText: "Example"
  downloadLocation: "git+https://github.com/kikofernandez/jesse.git#src"
  filesAnalyzed: true
  supplier: "Organization: Example AB"
  originator: "Organization: Example AB"
  homepage: "https://github.com/for-GET/jesse"
  licenseConcluded: "Apache-2.0"
  licenseDeclared: "Apache-2.0"
  name: "jesse-src"
  versionInfo: "6"
  packageFileName: "./src"
relationships:
- spdxElementId: "SPDXRef-Project-Jesse"
  relatedSpdxElement: "SPDXRef-Package-jesse-doc"
  relationshipType: "CONTAINS" # Should be CONTAINS, issue with ORT
- spdxElementId: "SPDXRef-Project-Jesse"
  relatedSpdxElement: "SPDXRef-Package-jesse-src"
  relationshipType: "CONTAINS" # Should be CONTAINS, issue with ORT

FYI @maennchen

[kikofernandez]

I noticed that SPDX as a manifest does not work either for DOCUMENTATION_OF and TEST_OF relationships

[fviernau]

Do I understand correctly that you assume spdx file -> analyzer result -> spdx file should yield the original SPDX file?
(Or at least retains the describes relationships?)

I believe this assumption is wrong and therefore I remove the "bug" label. Note that SPDX BOM files produced by ORT use the documentDescribes property to refer to the root package representing the project. I believe what could be done, in scope of this ticket, is to check whether this should be refactored, so that a DESCRIBES relation is used instead.

[kikofernandez]

(Or at least retains the describes relationships?)
Yes, I thought that if we use a manifest file, the resulting analysis or meta information about the package was going to be kept.
If we declare a DOCUMENT_OF relation, it should be preserved.

Note that SPDX BOM files produced by ORT use the documentDescribes property to refer to the root package representing the project.
Yes, I thought we have a root project in the documentDescribes, and then I can create many small vendor dependencies existing within the root project. For example, in Erlang we could have:

SPDXID: "SPDXRef-DOCUMENT"
spdxVersion: "SPDX-2.2"
creationInfo:
  created: "2025-02-25T10:13:22Z"
  creators:
  - "Organization: Ericsson AB"
  licenseListVersion: "3.26"
name: "Erlang/OTP"
dataLicense: "Apache-2.0"
documentNamespace: "http://spdx.org/spdxdocs/spdx-document-erlang-otp"
documentDescribes:
- "SPDXRef-Project-Erlang-OTP"
packages:
  # PROJECT
- SPDXID: "SPDXRef-Project-Erlang-OTP"
  description: "Erlang/OTP programming language"
  supplier: "Organization: Ericsson AB"
  originator: "Organization: Ericsson AB"
  name: "erlang/otp"
  versionInfo: "28.1.1"
  packageFileName: "./"
  ...

  # ERTS package top-level
- SPDXID: "SPDXRef-Package-erts"
  description: "Erlang Runtime System for Erlang/OTP"
  packageFileName: "./erts"
  ...

  # ERTS 3pp vendor
- SPDXID: "SPDXRef-Package-pcre2"
  description: "PCRE vendor library"
  name: "pcre2"
  packageFileName: "./erts/emulator/pcre"
  ...

relationships:
- spdxElementId: "SPDXRef-Project-Erlang-OTP"
  relatedSpdxElement: "SPDXRef-Package-erts"
  relationshipType: "CONTAINS" # Should be CONTAINS, issue with ORT

- spdxElementId: "SPDXRef-Package-pcre2"
  relatedSpdxElement: "SPDXRef-Package-erts"
  relationshipType: "PACKAGE_OF" # Should be CONTAINS, issue with ORT

This describes a ErlangOTP project, which CONTAINS the runtime system (ERTS), and a vendor library PCRE2.
For the same reason, using this approach, we can easily categorise DOCUMENTATION_OF and TEST_OF for documentation living inside packages and tests living inside packages.

Does this make sense? If not, why is CONTAINS relationship ok but not the others 😃 ?

[fviernau]

Does this make sense? If not, why is CONTAINS relationship ok but not the others 😃 ?

Hm, an analyzer result is a model which is different from SPDX. The SPDX model gets mapped to
packages, scopes, package-references / dependency-graph. This is a mis-match with these relationship types, so that mapping is lossy.

And then, the mapping back from ORT's model to SPDX is about choosing the relationship types which seem the best fit for exporting the data from ORT's model (which does not know (besides the Identifier type) that it's been imported from SPDX).

Does this make any sense to you?

[kikofernandez]

Yes, I follow your logic (but I am clueless about the internal mappings, of course).

Question
Would the CONTAINS relation be preserved? Currently, STATIC_LINK relation now kind of preserves this, except that in SPDX it generates a DEPENDS_ON. I was wondering if there is a mapping that allows us to keep the CONTAINS relation.

Example:
STATIC_LINK relations in SPDX manifests produce (this is for the jesse example from above when I replace CONTAINS by STATIC_LINK):

  "relationships" : [ {
    "spdxElementId" : "SPDXRef-Package-SpdxDocument-Example.AB-jesse-doc-6",
    "relationshipType" : "GENERATED_FROM",
    "relatedSpdxElement" : "SPDXRef-Package-SpdxDocument-Example.AB-jesse-doc-6-vcs"
  }, {
    "spdxElementId" : "SPDXRef-Package-SpdxDocument-Example.AB-jesse-src-6",
    "relationshipType" : "GENERATED_FROM",
    "relatedSpdxElement" : "SPDXRef-Package-SpdxDocument-Example.AB-jesse-src-6-vcs"
  }, {
    "spdxElementId" : "SPDXRef-Project-SpdxDocument-Example-jesse-project-6",
    "relationshipType" : "DEPENDS_ON",
    "relatedSpdxElement" : "SPDXRef-Package-SpdxDocument-Example.AB-jesse-doc-6"
  }, {
    "spdxElementId" : "SPDXRef-Project-SpdxDocument-Example-jesse-project-6",
    "relationshipType" : "DEPENDS_ON",
    "relatedSpdxElement" : "SPDXRef-Package-SpdxDocument-Example.AB-jesse-src-6"
}

So I was wondering if it is not too difficult to add a CONTAINS relation that is preserved in the mapping (back- and forth) from SPDX manifest -> ORT model -> SPDX manifest

(To reiterate, I understand that some relations are not easy to express, just checking if this one is simpler 😃 )

[tsteenbe]

@kikofernandez The SPDXDocument analyzer by design does not support the full SPDX spec but was implemented as fallback - the question is now should we patch it up to support your use cases or invest efforts into supporting SBOM as first class input to ORT per #9878?

[kikofernandez]

Even if I want this mapping, maybe from maintenance perspective #9878 is more important.
I can close and follow SBOM as first class 😃

Thanks for the discussion 😃