Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

[L Jean Camp <[e-mail]>]

If MUD is only used to obtain the SBoM then there is already a license of
the MUD-File (and a place to seek updates) in that case because the
MUD-File that is obtained is itself a bom.  So including licensing
information about the MUD-File is a structure that will require repeating
information that is already embedded in the file itself, and thus increase
the chance of conflict.

The component licensing in the (why are there 2? I do not know) data
structures are just YANG specifications to enable consistent XML or JSON
descriptions of licensing requirements, enabling a list to  point to
licensing of the SBoM itself as well as any level of specific per-component
or sub-component licenses.



On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann <[e-mail]> wrote:

> On 2021-06-04, at 13:21, L Jean Camp <[e-mail]> wrote:
> >
> > Given the explicit inclusion of licensing in the data structures of SBoM
> I think that SHOULD would be too strong in the case that MUD is extended to
> SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuanced
> and consistent manner.
>
> The current discussion is about the license under which a MUD file is
> offered, not about the licenses governing the components of an SBOM.
>
> > SHOULD would create  a conflict with the extension unless there is an
> alternative in the SBoM extension data.
>
> Unless you envision an SBOM for the SBOM, I think we are clear.
>
> (But we sure can try to be consistent with license description schemes
> employed by SBOMs.  Please tell us more about those.)
>
> Grüße, Carsten
>
>
>