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 <[email protected]> wrote: > On 2021-06-04, at 13:21, L Jean Camp <[email protected]> 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 > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
