joshua-zivkovic commented on PR #2095: URL: https://github.com/apache/buildstream/pull/2095#issuecomment-3596947680
> how about we at least look at what other people decided to put in those weird SPDX fields ? From some looking around. I haven't found much on real world uses, yocto generates this data itself so there's no written examples in the yocto world, but there have been plenty of talks on the subject which describe the included fields; all of which align with what we're aiming for. As seen in the likes of - http://events17.linuxfoundation.org/sites/events/files/slides/A%20Smart%20Way%20to%20Manage%20OSS%20Compliance%20with%20Yocto%20SPDX.pdf#page=11 - https://events19.linuxfoundation.org/wp-content/uploads/2018/07/OSLS-2019_-Building-on-Builds-YoctoSPDX.pdf#page=35 We can see that > concluded-license: the license for the "source" as chosen by the authors copyright-text: copyright notices declared-license: specific license declared for some source description: description of what the "source" is external-references: references to any related assets or information that is relevant to the "source", important to include as to not potentially lose any important data associated with the "source" name: the name of the "source" originator: the original author of the "source", necessary when consuming from source supplier: whoever provided the "source", should it not be direct from source. Is what we should be targetting, all of which are basically self explanatory fields. There are also the official exmaples use case from the spec we can reference where needed https://github.com/spdx/spdx-spec/blob/support/2.3.1/examples/SPDXYAMLExample-2.3.spdx.yaml -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
