<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Hello all</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">I give some time to make a good overview over our current state.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Let's tackle the issues first. The SPDX definition file over our metadata is possible, but not in the way we expect.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">There's no formal way to declare "subpackages" per se, like a source that produces several targets.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">The normalization of SPDX analysis is the main source (tarball/git) that produces a build, and specific version as well.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">So in raw terms, we can assign as example that the repo/project karchive depends on the repo/project kconfig, but the projects are treated as their own.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">References itself is the second issue, because we need to assign proper dependencies, not simply a range of "from version xx minimal". In this case, the yocto reference is more aligned.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">This complicates if we intend to have the formal spdx declaration direct on the repository.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">So, based on last sentence, one thing i'm working is on the fly generate the official spdx metadata from the Yocto bb packages, as a bitbake class, and the generated files can be a template for distributions as well.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">The key goal is deployment, so offering a way to generate the current correct output from be Yoco, deb, rpm would be the logical; way, because the final release package has always a 1 <-> 1 mapping fro dependencies.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">For the repository itself, what is possible is get the metadata generated on current tooling, and update the files based on current state of the repo metadata. This is feasible and automatized, but will do need us have some personal policy that everytime we properly require a new or different version deps to update the metadata correctly.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Said that, I think we should see the results on how the yocto output will go for an initial case.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Another suggestion that can improve our solution, is to adopt conan files for real.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Not necessarily as mandatory usage, but as reference. Scanning tools can create the files using Conan inclusing the proper dependency check. This will theoretically reduce the work on the metadata, and focus in a single place, conan, where we can rely on results for all states.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Anyway, this is my initial findings and i hope on the weekend I can have more concrete results.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">[]'s </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 22, 2021 at 9:26 PM Andreas Cord-Landwehr <<a href="mailto:cordlandwehr@kde.org">cordlandwehr@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, here is a short wrap-up of our today's BoF<br>
(activate participants*: Helio, Volker, Johan, me)<br>
<br>
The whole topic about license checking can be grouped into three areas:<br>
<br>
1. Correct statements of copyright & license information in source files<br>
- we think that we are on track here with our REUSE/SPDX statements<br>
- it is agreed that it is not a big problem that we do not have full REUSE <br>
compliance in most of the older repositories (specifically, missing license <br>
information in build system config files)<br>
<br>
2. Statement of outbound licenses == what is the license of a compiled lib or <br>
application?<br>
- we discussed the option to extend our yaml files with license information <br>
about the specific artifacts<br>
- if the artifacts are too complicated, a fallback could be to look folder-<br>
wise (though that would have several draw-backs)<br>
- outbound license information files in the yaml files could be helpful input <br>
for packagers, definitely they will help for Yocto packaging and for Helio's <br>
tooling<br>
<br>
3. Full distribution check of dependencies<br>
- question here: if our lib links to another lib, is this legally right?<br>
- we got the insight that this very much depends on the precise versions at <br>
compile time (because licenses of libs may change; e.g., see openssl)<br>
- for now we excluded the correctness checks of interdependencies of such <br>
licenses of different libs<br>
- what is thinkable right now: CMake could generate a list of dependencies <br>
with the precise versions as they are used for configuration/compilation<br>
<br>
Next Steps:<br>
1. come up with a proposal how yaml files could be extended to state artifact <br>
licenses<br>
2. Helio will check how helpful the existing yaml metadata are already for his <br>
tooling<br>
<br>
Stretch:<br>
3. check if existing ECM outbound license check tooling can be adapted to use <br>
the metadata from the yaml files<br>
4. integrate updated metadata files into Yocto tooling to get rid of manual <br>
maintenance :)<br>
<br>
Cheers,<br>
Andreas<br>
<br>
* == unmuted themselves at least once :)<br>
<br>
On Dienstag, 22. Juni 2021 08:29:11 CEST Andreas Cord-Landwehr wrote:<br>
> Hi, yesterday morning Helio and me had an interesting discussion about<br>
> metadata for license check tooling. There are a few different use cases:<br>
> <br>
> - Helio needs those for his FOSS license tooling<br>
> - I would really like to improve the generation of Yocto license metadata,<br>
> which we currently have to keep in sync manually<br>
> - maybe this is something that distros would also like to use in their QA<br>
> processes...<br>
> <br>
> Bottom line, we ended in scheduling a BoF for this evening (Tuesday), 6 PM<br>
> (UTC) i.e. 8 PM in Berlin time.<br>
> <br>
> Key question is: Do we see a convenient way to generate package metadata for<br>
> the binary artifacts and/or dependencies to other libraries without<br>
> creating a horrible maintenance burden?<br>
> <br>
> Cheers,<br>
> Andreas<br>
<br>
<br>
<br>
<br>
</blockquote></div>