spdx
"Usage Profile" to describe the intended usage by package supplier
"Usage Profile", the intended usage and license conditions assumed by the package supplier are appended to the generated package in a manner that supplements those conditions contained in the source code.
Signed-off-by: Yoshiyuki Ito [email protected]
From the SPDX tech call on 10 May 2022: Question on whether this should only be applied to Packages since Package is defined to be a unit of software distributed (or released) rather than to all elements.
Are there known use cases where this would apply to Snippets or Files?
Thank you for this draft @yoshi-i!
I will take a closer look, but one preliminary comment I have is that I would suggest limiting it to describing the supplier's "intended usage". I would suggest omitting references to licensing and license conditions.
If use of a package has license conditions, those would most properly be reflected either (1) through use of an SPDX License Identifier from the SPDX License List, or (2) through defining a customer LicenseRef- identifier via an Other Licensing Information section. I'm guessing that for the intended use case here, option 2 will be the more common scenario.
In those cases, the existing license fields would apply. I would not be in favor of adding new fields in a different profile that have overlapping or different meanings with regards to licensing matters.
But I don't expect that's needed anyway, to express the sorts of things it looks like you're wanting to convey here -- e.g. intended scope of usage, release date, etc.
@goneall -san, thank you for suggestions. I've corrected spellings and I agree that the modifications you have pointed out are more appropriate in line with the wordings.
Are there known use cases where this would apply to Snippets or Files?
I thought that binary blobs (and other set-up scripts) are delivered as the "Delivery in accordance with the development contract" in the supply chain, not in any specific package format but are raw library files which will be used in target product, occasionally. And in some case, raw snippets instead of patch files for set-up scripts are delivered later as a rapid fix-up. So, I prefer to enable this usage scope field not only for the package but also snippets and raw files.
@swinslow -san, thank you for made comments. I've removed descriptions which correspond to license conditions on the usecase field, this time.
I will consider about "(2) through defining a customer LicenseRef- identifier via an Other Licensing Information section" to describe the case like that the any license conditions are affected by build options on the binary package such as "selected specific license from multiple license" in further update of useage profile.
Hi @yoshi-i, thanks very much for the responses to my earlier comments.
As I mentioned on the spdx-tech mailing list, my main objective for this was to make sure that the licensing-related content was removed. I appreciate you having made those changes.
My other comments here were intended to help with clarifying or improving the remainder. I admit that I don't fully understand some of the practical details of how these fields would be used.
But in full honesty, I'm not likely to be a regular user or consumer of these fields. So I'll withdraw any of my remaining comments, and I'll let the other participants weigh in on whether they would like further changes based on my earlier comments or whether they are comfortable with the PR as-is.
Thank you again for the changes you've made to address my feedback!
@swinslow -san, I appreciate your quite important comments. I would like to encourage future discussions to consider making the field more user-friendly for a wider range of uses, not just some sort of specific business uses.
@yoshi-i - We're going to need to wait until 3.0 to add the full usage profile, but some of the fields described in this PR make sense to pull into 2.3 and let folks start using right now. I've created https://github.com/spdx/spdx-spec/pull/709 to include these fields. Can you please review that PR and comment on it. Note: I removed the explicit "Package" in some field names, as the AI BOM profile will want to use some of them as well at the "File" level in 3.0.
Thank you @kestewart -san, I've added the comment to #709 to put the signed-off-by into the thread. I will discuss remained portion of this proposal for 3.0 later on.
Changing the milestone on this to 3.0. Note 3 of the fields have been included in 2.3 as part of https://github.com/spdx/spdx-spec/pull/709
This is stale at this point. I'm going to close it for now. @yoshi-i - if you disagree, please feel free to reopen.