Paul, There is no escaping manual input from the process that leads to an SBOM, SPDX or CycloneDX. Someone has to input the data somewhere in order for it to be available at SBOM creation time.
If you are concerned that manual entry occurs somewhere in the process that ultimately results in an SBOM then I don't think this concern will ever go away. Manual effort is an inherent part of software creation, and yes, human error can, and does occasionally occur. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council - A Public-Private Partnership Never trust software, always verify and report! T http://www.reliableenergyanalytics.com Email: [email protected] Tel: +1 978-696-1788 -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Paul Sherwood Sent: Saturday, January 14, 2023 3:31 AM To: [email protected] Subject: [spdx-tech] SPDX - true or false? (was Re: Getting started...) Hi folks, five years ago (!) I raised some questions on this list about SPDX in the email below. I'd love to link to the thread, but as far as I can tell the messages have been lost from the public archive [1]. The answers caused me to lose interest in SPDX, because - SPDX tooling had in fact led to false claims about the mis-licensing of the keyring project [2] (you had one job... :-) ) - most of my questions didn't get any comment or response at all Now I've been asked/advised to look again at SPDX, to figure out whether my original concerns have been addressed. Obviously since 2017 the project has grown in stature and importance. I'm please to see that Philippe Ombredanne picked up on part of the original keyring discussion for python projects [3] and ran with it all the way to a pep [4]. However it's not obvious to me whether the underlying issue still remains, so I'd like to explain it as follows: - in many situations, people create metadata manually, to signify some property of a project or document - even with the best intentions, human-crafted metadata may or may not correctly describe the property it claims to represent - for example people often put "Version X" in the header of a Word document - then someone else edits the doc, but fails to update the header. We now have two different versions of the document, both claiming to be "Version X" - or someone specifies licence that they believe applies for a project, as metadata in a build tool (e.g. yocto bitbake recipe). Then someone adds additional content to the project, where a different licence applies, but no-one updates the metadata So the underlying problem I see is that manually created metadata can be misleading and lead to false confidence (as demonstrated by the keyring example). What mechanisms can be applied to ensure that license assertions based on SPDX metadata are actually true? br Paul [1] https://lists.spdx.org/g/spdx/search?p=created%2C0%2Cdmg%2C20%2C1%2C0%2C0&q= sherwood [2] https://github.com/jaraco/keyring/issues/263 [3] https://github.com/pombredanne/spdx-pypi-pep/issues/1 [4] https://github.com/python/peps/pull/1625 On 2017-02-16 18:40, Paul Sherwood wrote: > Hi all, > I attended a couple of SPDX-relvant talks at OSLS and am now trying to > get from 'vaguely aware and positive' to 'practitioner/advocate' in > the shortest possible time. > > I'll begin by stating I'm supportive of anything that will actually > improve the reliability, efficiency and effectiveness of complex > software delivery. In theory SPDX can be that, so here I am. > > Now - I'm a newbie and you can only get first-impressions from those, > so here are mine: > > - the website is no use to me at all. I need to know how to get > started in the smallest number of steps > - don't force me to read all the background, explain licensing etc... > just tell me what i need to DO > - you've moved to GitHub but there are still bugzilla links lying > around. please use GitHub issues and be done > - maybe worth trying to get a CII badge for SPDX :) > > Moving onto my own experiences with SPDX so far > - interesting conversation with Gary O'Neall, as a result of which I > understand some of the context and issues more > - so far I'm failing to understand what to *do* with it for the > projects I am involved in > > At Kate's talk [1] (can't find the slides online, btw) she showed a > Wind River dashboard which mentioned that the WR scanner > (proprietary?) identified keyring as having no license info. > > While the talk was happening I raised this as an issue upstream [2]. > > Basically, he would be an ideal candidate for adopting SPDX - he wants > to avoid confusion and licensing errors. But he has gone his own way > (even while acknowledging the 'too many standards' joke) because when > he checked out the SPDX project it 'seems it's not well defined what > it means to include SPDX metadata." > > I completely agree with him. On the SPDX homepage, there should be the > equivalent of hello world instructions, for maintainers to follow, in > clear english. > > Bonus points if the text answers all of the following questions: > > - can I just create one file, and leave everything else as-is, or do i > need to edit all my copyrightable files to insert metadata? > - what precisely do I put in my files? (and bear in mind I have C, > python, Assembler, Go, Javascript, haskell, generated code, yaml, > json, bitmaps etc) > - should i delete existing license texts? what if someone else put them > there? > - do i still need LICENSE, COPYING or similar files? > - is this a one-shot deal? once i've 'done SPDX' do i ever need to > think about it again for my project? > - if I make a mistake (eg spurious license files lying around) what > happens? > > Thanks for reading > > br > Paul > > [1] https://osleadershipsummit2017.sched.com/event/9Ki3?iframe=no > [2] https://github.com/jaraco/keyring/issues/263 > [3] https://xkcd.com/927/ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4919): https://lists.spdx.org/g/Spdx-tech/message/4919 Mute This Topic: https://lists.spdx.org/mt/96263894/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
