Gary O'Neall
Gary O'Neall
Since we have a 3.0.2 milestone, I'll close this issue. We can decide what we label the release if and when we get to that point.
My opinion is that we should exempt any SPDX standard defined elements for the import requirement. and SPDX standard defined element would have a pre-defined URI prefix or namespace. Otherwise,...
In the SPDX Java library, we have an option to copy the full license definitions when referencing a listed license or listed exception. Since we're now publishing JSONLD files for...
For the individuals, I'm more concerned about requiring copies or imports. Currently, we require SPDX documents to include a few extra lines to point to the context file. Adding the...
@zvr > That's the part I know nothing about... Can you "include" more data in any way? You seem to say that you can "import" them. > > But the...
Note that this is related to https://github.com/spdx/spdx-3-model/issues/932 since any import would require the `SpdxDocument`.
This has been fixed in the SPDX java tools by creating the imports for any listed license IDs in use - closing this issue.
I wonder if there is a way to specify a property must be of class `Element` or not of any class at call.
Note that the [spdx3-validate](https://github.com/JPEWdev/spdx3-validate) utility handles the external imports correctly. We could adopt the spdx3-validate utility as the "official" SPDX validator and not require the SHACL file to handle this...
My suggestion would be `GENERATES` if the binary package is created from the source files.