On Tue, Feb 8, 2022 at 7:19 AM Jan-Simon Moeller <[email protected]> wrote: > > Hi all > > > > Can you given an overview of what meta-spdxscanner does? I'm not quite > > > clear what extra processing would be required here. > > > > Jan-Simon can talk to it better, as he's done some dev work on the layer > > and done tests with it against AGL (and the subsequent Fossology instance > > experimentation), but AFAIK for the actual scanning scancode-toolkit > > does pattern matching based license detection, so in theory it'll catch > > excerpts of or slightly modified versions of the licenses in its > > database, as opposed to just searching for SPDX-License-Identifier > > declarations. If everyone else is happy with the latter, I'm willing to > > believe I'm offbase in my concerns, but either way I do think the > > limitations are going to need to be documented so users (and their > > lawyers) are aware of them. > > TLDR: meta-spdxscanner integrates with scanning tools. Either with fossology > or scancode-tk. An upload to blackduck is also possible meanwhile. > > Let's focus on fossology and scancode-tk. > > a) fossology > > Here we essentially integrate in the task chain and archive the sources after > patching to upload them to a fossology instance. All the scanning/processing > happens then on the server and after some time (a lot ! ;) ) we get a SPDX > report back that we store alongside the package. This is a result of a scan, > so it might catch licenses of files deep in the source tree that may not be > declared in the recipe and so on. > > Also, fossology offers then a webinterface for manual inspection and review. > So this is a thorough but quite manual process. More for release work than > daily or occasional stuff. > > > b) scancode-tk > scancode on the contrary will run on your host during the build and gather the > data. It will write the spdx file out as well. > > > I think for us the interesting part would be to compare e.g. the scancode-tk > scan from b) with what we have declared in the recipe.
Excellent. Thanks for the synopsis. Our perspective on all of the SPDX work we've done hasn't been to necessarily replace or replicate the behavior of these advanced licensing tools. Instead, we want to supplement them because there is a lot of information about recipes and packages that is pretty easy for us to know since we track it as metadata and are the ones actually *doing* the build. I don't know if we can claim to have a "complete" view of the SBoM, but I also don't think any single tool can provide a complete view. The amount of detail you want is going to be driven by you're requirements and some tools are simply better at providing different views than others. Our goal has always been to provide what we can (and especially what is hard for others to discover), and allow users to supplement with other tools of their choice. The license scanning may not fall under the "hard to discover" for others (depending on how integrated they are to scan the build source), but it's certainly something we *can* provide and can be quite useful. I would expect that different scanning tools will generate different results anyway, so as long as we indicate that our scanning uses a simplistic method, I don't think including it is necessarily wrong or a bad idea. If you want a more detailed view, than some other tool should be used to supplement the SBoM. I'm hopeful that someday our core SPDX work can make it a little easier on some of these tools so that they can "build" on our existing framework instead of replicating parts of it. > > > Best, > JS > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161510): https://lists.openembedded.org/g/openembedded-core/message/161510 Mute This Topic: https://lists.openembedded.org/mt/88980079/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
