I want to go very quickly because I'm rushing through because I don't want to keep you from
the very juiced part.
So we are presenting a complete, as complete can be, compliance toolchain for yacht projects.
So this in the context has been produced for a project we are part of called Eclipse Oniro.
It's an Eclipse Foundation project, it's yacht-based, and it provides an all-scenario platform project.
It's very complex, the numbers are quite impressive, cannot run through, but they are quite learning,
and everything is based on CI, so everything is CI.
We also needed to have a completely CI-ed also compliance process, so we needed to build
with the existing parts and building parts that did not exist, by providing a dedicated
toolchain.
This toolchain for compliance has been made not just by us, but by the Neuropath Tech Park.
People are in the room as well, and they have done much of the heavy lifting of programming,
and Albert of course gets the credit for the software.
It's also an Eclipse Foundation project, and it's alright, there is a REPL, and you can
look at everything.
It's based on an already existing, the no-subjects of compliance for soldiers can code, but we
have to create a dedicated new custom set of tools also being distributed as open source.
Of course we use SPDX all across the toolchain for many things, and this is important, this
is not just for this project, this is meant to be a toolchain for all the Octobase project,
not just for this.
Through this combination of tools, we have been able to complete a very lengthy process
of compliance, reaching 100% of coverage of all the components.
I don't want to skip, thanks to the Damian providing a lot of the information that we
have really used.
Here you can see very quickly the dashboard, so you can track the evolution and the status
of compliance.
You can also go and have many more details of the single packages.
That is just for knowing what components and what license is there, but we cannot stop
there.
We want to go farther, and we have what we call the second phase of the compliance toolchain,
and we decided to go for a graph database for many technical reasons, because there
are a lot of interactions we have to traverse the database very easily.
We need to do the missing part, which is software composition analysis, dependencies analysis,
and incompatibility checks, and everything must be done automatically as much as possible,
so this must be entirely into the CI pipeline, which it does.
In order to do this, we need several things.
This is really important, map all licenses data from the source to the binary, and at
file-level mapping, by file-level mapping, we mean every single file, including patches,
everything that goes through needs to be checked, checked some, and tracked through all, in
order to make sure that everything that goes inside is tracked.
This information comes from many sources.
We had an audit team who has done a lot of work, and finally, we need to find a way to
automatically, as much as possible, see if the inbound and outbound licenses are compatible
with each other through automated tools.
This is in the very short time, the general description, here an example of the relationship
between components in the database, and there is the next bit, which is perhaps more interesting,
and I give the floor to Alberto.
So thank you, Carlo, and so the question is, why do we need this?
So Yacht of Warflow, for those who are already familiar with that, is quite simplified here.
We have recipes, recipes that can map to a single upstream source component, but possibly
also two different upstream components, maybe the main application, then some plug-ins.
So you can have here many different upstream sources combined together, fetched, and together
combined into a single work here, in the unpacker stage task of the build process.
Then there are other tasks, configure, patch, whatever, basically build.
We got binaries, and binaries are combined together to form the final image.
But the problem is that when it comes to upstream sources, we have upstream components that
have multiple licenses inside it.
Maybe we have different components with different sets of licenses, but the thing is, we have
only a small subset of the binaries that we could generate for all this stuff, and the
binaries, you don't know what the actual license is, especially when here you have kind of
a mess.
And the thing is that you risk that some dirty stuff ends up in your image.
I mean, I don't know, if you have a package with a blacklisted license or compatible combination
of licenses, you may have in your final image something that is not compliant, and this
is something we need to avoid.
So the thing that we have to do is to follow a process.
So to find out the relationship with third-party upstream code, the inbound code, then we need
to find under which license the inbound upstream software is, therefore the inbound license.
And if there is a possible combination of that, because not all combinations are allowed,
and depending on the context, they may be allowed or not, like other talks pointed out
this morning.
And we need to match this combination with the abound license, is the wanted abound license
compatible with the inbound licenses.
And this for each artifact, we cannot do that, especially in the embedded field at package
level because the package may contain a lot of stuff.
And we need to know about the files, not the generic about the package.
Here we have an example, I hope it's readable.
This is GPGME component that GPG made easy.
It's a very small component.
In our project, we found it out that we generate only three binaries out of it.
If you look at the license and the recipe, you find the GPL, I guess, three or LGPL two
or something like that.
But this is nothing, sorry, not or, but and.
So the thing is that this binary is that GPL, is that LGPL, is that something else?
We don't know from what we have from source license information.
So we collect in this graph database multiple sources of information.
So on the yellow dots are the information coming from our auditing, working on physiology.
So file level, source, license information, the purple dots are, comes from Yachta metadata
and also the information about which files are being generated by, to generate, they
have been used to generate this binary, comes from Yachta from the create SPDX class presented
before.
Basically, we now have MIT, MIT, GPL two, GPL three, sorry, GPL two or later, or LGPL
three or later, and then we have GPL three or later.
What's the license of this file?
So usually the audit team comes to us and we discuss to find out which is the license
of the binary file.
But this is not scalable.
This is error prone.
We cannot do that for every single binary file, for every release, for every snapshot
of the project.
This is another example.
This is another binary you can generate from the same component.
Here you have MIT, MIT, MIT, LGPL two, point one or later.
This is another story.
Maybe it's easier here.
And we can have also more complicated, I won't go into the details here.
So how can we handle that in an automated way?
So the idea is to have kind of a battle between license cards.
So you put together every time two, two cards, and you need a set of rules to decide which
card wins.
And then you iterate and you look over all the possible combinations of license until
only one will survive, hopefully.
So to do that, we are trying to define a language to define those rules.
We need to define the two license cards, the two license cards that are fighting against
each other.
We need to fight the called battlefield kind of context.
Is that static linking, dynamic linking, whatever?
The authority who said that, because the answer by the lawyers always, it depends.
So we need to say who said that.
In this case, FSF, we kind of trust it, especially when it comes to GPL compatibility matrix.
And here we are the result of the battle.
We have a winner or we have kind of invalid.
So this kind of combination is not possible, because GPL two only is not inbound compatible
with Apache 2.0, while GPL two or later may be inbound compatible with Apache 2.0.
If you make it become GPL three, because GPL three is allowed to be inbound compatible
with Apache 2.0.
So this is kind of an example.
I don't have time to go into details.
The rules in action are like here, when you have disjunction, a disjunctive license expression,
you need to calculate the Cartesian product.
So you need to have, in this case, MIT, GPL two and GPL three fighting against each other.
Then MIT, LGPL three and GPL three fight against each other.
You find a list of the decision and we know that GPL three or later is the license that
prevails here at the end.
So the time is up, sorry.
So the thing is that, how I already said, we consume data from different sources, from
physiology, from Yachto, and for now we have proof of concept.
The aim is to upstream everything into the Creator Speedyx class in the Yachto project.
I don't think we have time for questions, but here and in the slide you find all the
information to contact us.
So thank you.