Sebastian Schuberth

> If ORT adopts Package URL for bom-ref field instead of ORT identifiers it will make it much easier for ORT users to compare CycloneDX SBOM with each other and...

> @sschuberth are you a user of this property? Yes, we heavily use it throughout the code base of https://github.com/oss-review-toolkit/ort. > Would you be opposed to its renaming and/or removal...

> How about this option: we move this property into an optional module `log4j-api-kotlin-autoprop`. People who want to use the property just have to add that module into their dependencies....

Or maybe renaming the properly would really not that bad after all, as users could easily account for it with as import alias.

Slightly off-topic, but regarding the performance impact and combining it with convenience, I wonder whether we could have an annotation / Kotlin compiler plugin that auto-generates code for classes that...

Couldn't that be solved by finally migrating the Stack implementation to the dependency graph (see https://github.com/oss-review-toolkit/ort/issues/3825) and comparing the more compact representations?

FYI, there is https://github.com/Ricky12Awesome/json-schema-serialization which might become handy.

@takahirom, you might want to give https://github.com/SMILEY4/schema-kenerator a try.

Let me start by saying that SPDX's `licenseConcluded` field does not necessarily have the same semantics as ORT's `concludedLicense` field. You already mentioned one difference: Whereas in SPDX the `licenseConcluded`...

> Because the SPDX attribute licenseConcluded is mandatory It's actually not required by the SPDX specification, but it was required by ORT's deserialization by mistake, see https://github.com/oss-review-toolkit/ort/pull/10547. > I would...