Plans to split out the SPDX libraries from this repo

[coderpatros]

The SPDX libraries were originally added to this repo to make it easier to initially iterate on the implementation in step with the CDX libraries in this repo.

I'm proposing to migrate the SPDX and SPDX Interop libraries to their own individual repos.

There's a couple of potential benefits including:

• reduced notification fatigue for maintainers who are focused on the CDX libraries and not the SPDX ones
• finer grained scope for potential future maintainers to be onboarded
• the opportunity to more easily open up SPDX libraries to external collaborators from the SPDX community

I can't think of any real downsides except library versions will start drifting between the core CDX libraries and the SPDX ones.

[coderpatros]

@mtsfoni tagging you for visibility and to get your opinion on this

[andreas-hilti]

@coderpatros I see some drawbacks: I'm mainly considering the usecase of the cli (which use both aspects); if you now do a breaking change in the datamodel, you first need to get a release in the "core" repo, then a release in the "spdx" repo (which uses this release), and then a release in cli.
Already right now the cli is actually lagging behind quite often and doesn't get the updates from the library. And I would argue that the cli gets more usage than direct usage of this library... In general, I fear that it will only become worse.

[coderpatros]

That is a good point. Although I would like to ultimately move the SPDX related functionality out of the CDX CLI tool. Maybe a better approach is to move the SPDX parts to a repo specifically focused on the CDX and SPDX interop use case?

[mtsfoni]

First of all, I'm always cautious about these kinds of moves; they often turn out to be lateral changes that consume a lot of time without really improving anything.

That said, I do understand the problem, because SPDX represents a strong domain specific niche here. Personally, I don't really feel confident reviewing SPDX PRs or answering questions about it. That was actually a bit of an issue when the Spanish Checkmarx team implemented a larger change. Hygiene also speaks in favor of the split. This library maps the model to .NET classes at a very fundamental level, and SPDX is just one specific use case on top of that. For other use cases like creating SBOMs or merging, we already have separate repositories anyway.

Andreas' point is of course valid too. One option might be to trigger a build in the new SPDX repo whenever a release happens here. Alternatively, the SPDX project could be folded into the CLI.

I don't have a strong opinion either way; if you want to split it out, I have no objection.