Alexios Zavras (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...

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...

Of course, the full tree of children would mean that `Element` class will have a list of (mostly) everything else.

No need to back-port this to 3.0. But I am a little skeptical of the wording that says stuff about "each `to`". Why "each"? Can there be more than one?...

There is a mix-up of two different cardinalities in these comments. I am firmly of the opinion that a `hasConcludedLicense` relationship should never have more than one `to` licenses. Therefore...

We should keep all the calls to `error()`. If we want, `autoconf` may check for its presence, and if it's not there, include an dummy implementation of the function.

This was discovered more than a month ago: https://github.com/spdx/license-list-XML/pull/2245#issuecomment-1818003671 120 cross-refs are affected

Thanks for this, @jimklimov . Honesty, I don't think it's worth going to all this trouble for something that will probably never be used, as the schema will not change....

Internet Archive shows it back in 2020, before spdx.dev was set up: https://web.archive.org/web/20200415003739/https://spdx.org/spdx-specification-21-web-version/

All alternatives described above essentially model the signatures _inside_ the SPDX data. There is definitely the additional use case of modeling (and recording information) about signatures that are _outside_ as...