Expand §8.3.4 Annotation Type with new values (LICENSE, PATENT, COPYRIGHT, EXPORT, TRADEMARK) and change cardinality

[kestewart]

Thomas: Expand §8.3.4 Annotation Type with new values “LICENSE” | “PATENT”. Enables annotator to more precisely indicate type of annotation
Discussed use case brought up by customers - will save research. OpenCV is case cited. Be able to annotate that a patent has expired, etc.
Use LICENSE when its not 100% clear, so may want to provide information about equivalence or not with another. Zlib 1.0.6 and another close to it.
Different lawyers handle different roles, want to give lawyers comments that apply to the appropriate reviewers.
Thomas: Copyrighter holder may be out of business, so may want to have a “COPYRIGHT” as well.
Discussion of who adds the and roles between Alexios & Thomas.
Desire to permit multiple TYPES to be used with ANNOTATION

1. Add in new values LICENSE, PATENT, COPYRIGHT, EXPORT, TRADEMARK as valid types.
2. Permit cardinality from one to many.
   Gary ok with cardinality change, sees as useful for automation.
   Looking at this as a 2.2 feature.

[kestewart]

TO BE DISCUSSED FURTHER: Do we want LICENSE here in this, as we can’t point Annotation to License at this point in the model for this. Adding Annotations to Licenses? Will this hold up in the data model. Open question is how you can express for a complex license expression?

[mcjaeger]

Export will be about ECC information, such as in:

https://github.com/openssl/openssl/blob/master/README (last paragraph)

in a file?

There is another file case which could be considered for marking in a similar mode, not citing examples here, but files exists in OSS which say in their header like

• This file is confidential, proprietary or both
• can be used only with (written) permission by copyright owner

-> how about marking such file for avoiding this for use?

[swinslow]

If you have some concrete examples of e.g. what the fields would look like in practice, for these use cases, that would be helpful to see. I might not be understanding the request here, and also might misunderstand the use case for Annotations. =) But here's my gut reaction on these.

• For COPYRIGHT and LICENSE, what would be the reason for adding this sort of information via Annotations? Rather than using e.g. the PackageLicenseConcluded / PackageLicenseComments fields (and similar equivalents, for copyrights and each of those for Files)?

• For PATENT, the current SPDX spec takes a pretty definite stance that patent info won't be addressed:

1.5 What is not covered in the specification?
. . .
1.5.3 ​Any identification of any patent(s) which may or may not relate to the package.

• For TRADEMARK, I don't know that it's explicit, but I'd feel pretty similarly. Trademarks are relevant in the context of goods and services being offered in commerce. That means that pretty much any questions around use of trademarks, and whether a use is "okay" or not, is going to be context-specific. Feels to me like it's outside the scope of SPDX documents' purpose of defining a software bill of materials.

• For EXPORT, I could see some relevance here, in terms of flagging Packages or Files that could contain encryption code. (I note that this is a very US-centric view of export controls...) Though from the OpenSSL statement that was linked above as an example, that's just pointing to a generic statement that some countries have export controls and you should talk to a lawyer. What would be the sort of field / data that you'd imagine would go here, from an export perspective? And, should those be in an Annotation or in an export-specific field in the Package and File sections?

[kestewart]

Moving to 3.0 based on discussion on weekly call.

[kestewart]

Possibly we should also consider adding in "STANDARD" as the AI & FUSA profiles will reference this.

Also, Arm has gone about creating "Standards" fields in Comments, so let's see if we want to have it as annotation, or include directly as package property.

[goneall]

Since this is a non-breaking change, moving to 3.1