Clarification Needed on SPDX File Relationships in Absence of Direct Mapping
✅ Scenario 1 (Reference Case)
In my project, I have 5 files:
- MyFile1 to MyFile3 are exact copies of OpenSourceFile1 to OpenSourceFile3.
- MyFile4 and MyFile5 are modified versions of OpenSourceFile4 and OpenSourceFile5.
In this case, I’ve used the following SPDX relationships:
- COPY_OF for MyFile1–3
- DESCENDANT_OF for MyFile4–5
SPDX document for scenario 1 : MyProject_Scenario1.json
❓ Scenario 2 (Clarification Needed)
In another case, my project again contains 5 files. All 5 files are either:
Copies of, or DESCENDANT_OF from files in an open-source package.
However:
- I do not have a direct file-to-file mapping between my project files and the original open-source files.
- I only know that all my files originate from the open-source package, but I can't specify which file corresponds to which.
🔍 Question
In this scenario 2, what is the appropriate SPDX relationship to use between my project’s files and the open-source package?
Should I still use COPY_OF or DESCENDANT_OF even without a 1:1 file mapping? Or is there a more suitable SPDX relationship (e.g., GENERATED_FROM, OTHER, or a file to package-level relationship) that better reflects this situation?
If the OTHER relationship is used, what kind of relationship comment would be appropriate to include, especially when none of the standard SPDX relationship types fully capture the scenario?
In this scenario 2, the relationship is modeled from each file to the open-source package. Is this direction appropriate, or would the reverse (from package to file) be more accurate or preferred in SPDX modeling?
Any guidance or best practices for modeling this kind of relationship in SPDX 2.3 would be greatly appreciated.
Thank you, Nishanth
Hi everyone, Just wanted to circle back on this topic to see if anyone has had a chance to look into it or share any thoughts. I’d really appreciate any feedback or suggestions from the community. Thanks again!
@nishanthsankaran do you like to add this to the Tech team meeting in the one of the coming weeks?
Btw, this issue is already in the backlog https://docs.google.com/document/d/1NdHYU_VZtLacD4bEmf2GiUVRTbrcev1beaJpq8s8-pU/edit?tab=t.4wfxhy2gdx3y
Thank you, @bact. It would be great if this issue could be added to one of the upcoming Tech team meetings.
@nishanthsankaran it's every Tuesdays at 12:00 US Eastern Time See meeting link here: https://github.com/spdx/meetings/?tab=readme-ov-file#tech-team
Meeting agenda: https://docs.google.com/document/d/1NdHYU_VZtLacD4bEmf2GiUVRTbrcev1beaJpq8s8-pU/edit?tab=t.t8f4t082ttml
From 16 September 2025 Tech call:
- We lack a relationship for describing the modified files to originating upstream package. At a file to file level, we are coherent. But set of files modified from Upstream package.
- Possibly consider derived from and contains. Also issue of which files are not present needs to be considered. Pick this up again next week. Looking for solution to use existing relationship, or consider adding one for upcoming version.
Thank you @goneall. I believe the "derived from" relationship could be appropriate for scenario 2 — file to package. However, this relationship is not currently included in the SPDX relationship types.
Thank you @goneall. I believe the "derived from" relationship could be appropriate for scenario 2 — file to package. However, this relationship is not currently included in the SPDX relationship types.
Correct - this would have to be a new relationship type
Thank you @goneall. I believe the "derived from" relationship could be appropriate for scenario 2 — file to package. However, this relationship is not currently included in the SPDX relationship types.
Correct - this would have to be a new relationship type
And so would that leave other as the most appropriate relationship type for this scenario in the meantime then?
Thank you @goneall. I believe the "derived from" relationship could be appropriate for scenario 2 — file to package. However, this relationship is not currently included in the SPDX relationship types.
Correct - this would have to be a new relationship type
And so would that leave
otheras the most appropriate relationship type for this scenario in the meantime then?
Agree other is the most appropriate in meantime