I think image manifests would fall into the external reference use case. The category would be other, we can provide the type URI in the best practices document and any other material covering container usage. The URL of the actual descriptor would be the locator value.
The information in these manifests, such as source, license, etc could also be used by tooling to generate SPDX documents. And on the subject of inter-specification integration points, perhaps there’s an interesting discussion to be had about touchpoints between SPDX and OpenAPI. There are cases where implementation details may be significant to API consumers – and, in the case of AGPL-licensed components, disclosure may even be mandatory. I would imagine SPDX documentation would fall under the external documentation use case (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#externalDocumentationObject). From: Michael Dolan <[email protected]> Date: Friday, October 7, 2016 at 12:03 PM To: Yev Bronshteyn <[email protected]> Cc: Kate Stewart <[email protected]>, "[email protected]" <[email protected]> Subject: Re: SPDX to describe containers? From a scanning perspective, it might help that we added a Source descriptor to the OCI image specification manifest file to identify the location of the source code in the container image. If you're not familiar, OCI is the upstream container standardization project started by Docker, Red Hat, IBM, etc. Through that URL someone should be able to obtain the license for the package. It would be much easier if they used the SPDX short identifiers.
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
