So, hi everyone. So we're about to present you the Ermin project. So for those who are
here on Friday, I can't talk close to the microphone.
So it's the same project that we mentioned on Friday and hopefully the presentation will be easier to understand.
Also because I'm with Nicolas Toussaint.
So I'm with Nicolas Toussaint from Orange. We'll introduce you to the general idea of the project.
Thank you.
Okay, speaking loud.
So what's Ermin, so a mine, apart from a really nice animal, which does take an age in French.
So it's quite a young project, been existing for a year now, initiated by InnoCube and joined by five other large French companies.
We're trying, so we're like an open project, we're trying to do things properly.
We haven't joined an organization yet, Foundation, but that's planned.
We have three committees, that's important. Legal committee because you'll see later it's all around legal suspects,
made by jurists, mostly for jurists.
And then, well, you know, we try to use, we do use AFERO, ODBL, and so on and so forth.
Can you move to the next?
Right, so we're building something new, and well, we think so, and we do rely on existing well-established tooling.
All of those have been hearing about it all day. Let's move to the next one, probably know these ones.
Right, so the nice part, what it's all about, so the idea is to really implement your open source policy.
So we take, on one hand, all the license texts from the open source licenses.
We break them down into obligations, so do you have to disclose the source code, mention the authors, and so on and so forth.
On the other hand, we take S-bombs from the project, and we enrich it with legal and technical context.
In the middle, that's where the magic happens. We kind of apply your open source policy,
and out of this, we get, on one hand, we get a validation or not.
Is it okay to use that license in that context?
And on the other hand, you get a nice list of obligations you really have to follow,
because you have plenty of obligations and plenty of context.
Sometimes you have to follow them, sometimes not, depends on the context.
So that's the big picture, and that's next to Kenny.
So before talking about S-bombs itself, you have to have a kind of preparatory phase, so that's license analysis.
The tool was mainly designed for IP lawyers, but we are not familiar with open source licenses.
So what we wanted to do, it's to be able for them to save time while still being confident in the decisions that were made.
So also, it was important, it's a shared tool, but of course, every company has its own open source policy,
so it had to be flexible enough.
So the first aspect is kind of a pedagogical framework that will allow lawyers to systematically and consistently analyze open source licenses,
and that will also mean that if it's analyzed systematically, we can handle the decision programmatically to a certain extent.
And as I was saying, the idea is also to share interpretations, because if you have a broader consensus about interpretations,
then that will increase legal predictability and reduce legal risks.
So when we do license analysis, it's basically break down in three parts.
The fourth part is just the global characteristics of the licenses, like about the copy left level, the types of rights granted,
like if you have patent grants, stuff like that.
I mean, technical things like the choice of law of venue, et cetera.
And the more important is your policy status.
I mean, if you always allow it, if you never allow it, or if you allow it depending on context,
then if you allow it depending on context, well, you'll have to specify which context it's allowed in.
And if your context is based on simple enough facts, you will be able to automate that.
So, for instance, I mean, you can have two subcategories of context.
You will have a technical context.
I mean, typically, I mean, how and if it has been modified or not.
If it's as a type of linking it has with your code base.
And but also you can associate it to a category of your products,
which means that a product for which the IP will be treated differently.
I mean, typically, I mean, in many cases, you won't accept to have a GPL V2.
But if you do embedded Linux, I mean, of course, you will accept it.
So that will not depend of the technical nature of the third party components or it's linking to your code base.
It really, really depends on the business expectations that you are doing on the final projects.
And so we can partly automate that.
And the third party, it's the breaking down of each license in obligation.
And each regulation will be triggered at two levels.
The first one is if it has been modified or not.
Because in many cases, I mean, you have many obligations that you don't care about
just because you're just redistributing unmodified third party components.
And the second one is the type of exploitation, which means do you distribute it?
I mean, a source has been binary or do you provide network interaction extra?
And also, I mean, when you break down different licenses, you will realize that, I mean,
very often you have very similar obligations.
I mean, they're not straight in the same way.
But you can decide, and that's the choice of the lawyer,
that actually the equivalent in the way, I mean, they have to be respected.
And so you can relate that to a generic obligation and then you will only care about a generic obligation.
And you will only care about a specific obligation when they are not related to a generic obligation.
And that's about it.
And so now that you have your policy ready, you can be ready to handle S-bombs.
And I will pass you the microphone.
Thank you.
OK, so that was the right-hand parts, the licensing obligation.
Now we're looking at the left-hand parts.
How do you handle the S-bombs?
So today, we mostly work with the evaluated report from ORT.
You've heard about this morning and all the time.
We're working on working with SPDX as well.
There's a lot of work to be done in this area.
And we will have to go to and support CyclingDX in the future as well.
Right, so when you take this S-bomb, you have plenty of information,
but you don't have all the information we need on the context.
Two types of information we want to add.
We want to add the technical details.
So sometimes you can get it inside the SPDX report.
But I guess there's more automation we can do in this field.
But we definitely need to add manually some extra information like the technical linking,
how your component is linked to your application.
The type of exploitation is what do you actually do with your components?
Are you going to distribute it on the Internet?
Are you going to distribute that to your end user and so on and so forth?
Is that a SAS?
You need to also specify if you have modified the source codes.
That makes a big difference on how you're going to trigger the license, what you're going to have to do.
And we also added recently some funding information.
Where does the money come from for a given component, a given project?
So the scope can be really handy to automate all the kind of things.
There's that development dependency, that build dependency and so on and so forth.
There's plenty of things we can do to automate further.
But yeah, next please.
Right, so there's quite a lot of work to validate the SBOMs.
And this is what you see.
It's really from a legal, jurist point of view, maybe more than a technical one.
So when you get your SBOM in, well, obviously you need a valid XPX expression.
If you don't have the XPX expression, you don't know what you're talking about.
So you need to know what license you have.
Well, number two is a very specific case where when you want to have, give choice to the user.
You say it's either GPL or MIT.
Quite often the developers tend to write it's this one and this one.
But what they really mean is this one or this one.
So we added a specific step to fix this particular problem.
Type of exploitation we mentioned this earlier.
You have also to choose, when you have this choice MIT or GPL,
at some point you have to decide which one you're going to select.
And all those licenses have to be reviewed by legal persons.
They have to be what Kemi explained earlier.
If that has not been done, then you have to go back to your jurist and say,
please analyze this license.
And there's plenty of things that we did to automate this because it can be a lot of work.
We're not going into details now.
But in particular, we're working on exporting the curation methods to odds.
So you don't have to redo this in the future.
Okay, so actually the interest of the tool is to combine the two aspects.
And when you combine the two aspects,
you end up with a list of obligations that you actually have to follow for your release.
And so the idea is that it will really get rid of everything that is not actually needed.
And also we have introduced the idea of a core set of obligation is that you don't necessarily,
I mean it's not always efficient to stick to the bare minimum of obligations.
Typically you have licenses like BSD0 or unlicensed.
And they don't ask you to put a license in the documentation.
But I mean it's more efficient to have the same process for every license and also for,
I mean you have many reasons to do so.
So also it allows you to classify obligations as part of something normal.
I mean you know that you won't have any extra efforts or any special attention to put into your release
because it's in your core set of generic obligations.
And so that gives you free time to actually consider what is specific and more important.
And also another thing that you get is that it gives you a global visibility.
And one of the different sort of components you have in your project,
so it's relatively, for instance, if you have logged for J, you can search for log for J
and it will give you the different product and release which are involved.
And also more importantly for us, you can know which of the third party components you are most relying on
and also it gives you a direct link to funding them.
But it's because it's quite important to actually care about funding and the third party components you rely on.
And that's about it.
Thank you.
So where are we now?
The project is ongoing obviously.
We don't really have a 1.0 version yet.
It's on the way.
It's not really used in production yet.
Maybe you do actually in a cube?
Yeah, but we are not the typical users.
Yeah, yeah, yeah.
But we shall have one soon.
If you have any questions, you can call on GitLab.com.
And we do, so we are talking about this breaking down of the licenses into obligations.
That's a lot of work.
And some of it is already available on GitLab as well.
So you can have a look at this.
And yeah, if you want to come, we speak back English, but we're friendly.
You want to add something?
Because we have some time.
Yeah, yeah, yeah.
I think.
Just to say on this particular side of the legal obligations,
the idea is to also share with the project a set of licenses,
a set of interpretations that can be shared by everyone.
How are you going to deal with the fact that Cyclone DX only has one license field
and does it not differentiate between conclusions and what's detected?
Yeah, so just to repeat, how are we going to...
Yeah, yeah, I'm doing that.
How do we handle the fact that Cyclone DX only has one license field?
I have no idea. Do you?
We have just started implementing it.
Historically, we've always been working with SPDX and that's quite natural, but we realized that...
Well, some tools...
Just to assume it's included when you see something there?
Yeah, I mean, we'll have to see how it goes.
We have first started to submit some peers to their specifications
because we had additional needs like support for scopes and stuff like that.
So we know that they come from security.
They don't come from licenses.
They come from two different worlds.
So I think that they'll have to evolve at some stage.
But they seem very open to suggestions.
But we're still implementing it.
Yes, Thomas?
How would you say her mind is different than Ford's?
Because Ford also has a policy engine and Ford's have already stopped.
So as you know it...
I mean, basically it started as a front-end for Oort
and because we wanted to have a graphical interface.
So technically it's a Django app and we have an REST API based on Django REST.
So we want to stay as close as Oort, including to the concept as possible.
But it works a bit differently.
And that's why when we make curations we wanted to make them exportable as Oort formats.
And we also plan to be able to export your license policy and the Oort format.
The idea is to be as compatible as possible.
But just the fact also, the main difference is that it has a central database.
I mean, just like when you used to use a W360 and it brings the same functionality.
That's about that and we really want to stay as close to Oort
and that's why we contribute to Oort when we can.
Did I answer your question?
Can I just ask?
Sorry.
Thank you.
Yeah, there really is a lot of work around working on the licenses and sharing interpretations.
So this is part...
If you download her mind and you execute it,
it comes with a set of decisions and interpretations that you can use
that you should actually read and make your own.
But I guess that's on top of Oort.
Sorry.
Yeah, so that's not actually a question but a quick comment on the cycle of the X-situation.
So the licenses for your component is actually in the right.
So it's possible for you to give multiple licenses there.
What might get trickier is actually attributing which files in the source tree.
It's not expressing that there are multiple licenses.
Yeah.
And they don't connect to other relationships.
Those things are missing right now.
What I was just asking, is there anything missing in SPDX
that we should be adding into the 3.0 that you need?
Actually, maybe.
I think it is, but for instance,
I mean we mainly rely on the evaluating model of Oort,
which is kind of semi-official.
I'm not sure it's really publicly documented.
The evaluating model.
It's public.
Okay.
Yeah, I mean the code is public, of course.
But I mean, that's really, I mean,
and the kind of information we like,
I mean, it's like we have scopes.
I mean, and we have it in also sub-projects.
Because when you scan, for instance,
you can have your composer.json and your package.json in the same project.
So it's easy to say, okay,
so these are my dependencies for my back-end.
These are the execution dependencies.
And it comes naturally.
I mean, I think it could be implemented in SPDX,
but I don't think it's present in a, okay.
So because initially, I mean,
we wanted to stick as much as possible.
So we say, okay, we will interface with Oort through SPDX.
But it was, I mean, it was not really convenient.
Yeah, sorry.
May I ask one question there?
Because this is really important.
Okay.
You're focusing on copyright balances.
Do we have other legal obligations?
Because copyrights, like 100% of the other legal obligations,
we need to use the word for your customer.
Sorry, could you speak up, please?
Is it only open source obligations?
We have other legal obligations,
like privacy, security,
we need to deliver information to your customer.
So currently, we are focused on legal things
and mostly related to IP.
We tend to also include export control,
because that's quite easy.
Regarding security, it's a whole different subject.
And actually, I mean, in the first prototype,
we had a link with a vulnerable code.
So it can be not, but it's not that trivial.
And currently, I mean, all of the partners
are treating the security aspect with their own tools.
So it's not a priority for us.
But yeah, I mean, we would be happy to be able to handle it.
So did I answer your question?
Okay, thanks.
Sorry.
Well, the points we take,
I mean, the orange, at least,
is that her mind is one part of the whole thing.
And we're going to work on interfacing it
with some of the tools like dependency track
and that kind of things.
The point is being to have one source,
one database of all the components that we use
within the group,
and so you can use it from different perspectives.
How do you handle incompatible source licenses,
like GPL on one side and ACTI on the other,
if they combine?
Good question.
Okay, so the question was,
how do we handle incompatible open source licenses?
For the moment, we don't,
but that was discussed on Friday,
and it's not that trivial
because you first have to understand
the relationship between the two components,
because currently what we handle
is the relationship between a third-party component
and your code base.
But you can have incompatibility
between two different third-party components,
so you have to qualify the technical relationship
between those two.
And that's a bit tricky,
but I think Friday we realize
that many people want to work on the question
and we really want to be part of this discussion.
Yes, so let's...
You can use ORT,
and that's Osado support for license compatibility,
so you can actually do the front-back already.
Okay.
You can transport from Burma into ORT,
from Osado, Osado is a German open source foundation,
and they published a license compatibility matrix,
which has been included in ORT,
and then it was activated.
Is it perfect? No, but it is possible.
Yeah.
Osado has lawyers inside the area.
They're working on the legal side,
but you shouldn't be there.
Well, we do have a few lawyers on board,
so...
And by the way, there's no competition.
We had a very interesting discussion with Osado,
and we really plan to cooperate with them,
and that's on our to-do list in the beginning.
It's just that we lack time, but...
Yeah, I mean, we really want...
I mean, we really will work with them in the future on that,
and anyway, the next one is interesting.
So you have another question.
Yes, please.
That's true.
Sorry, I mean, you're talking about SW360, or...?
Okay.
Yeah, I mean, just for your information,
we contributed documentation back in the day,
and we wanted to go the SW360 way,
but that was before the project was reborn.
No, because there were dislikes,
so we needed it.
I mean, I can talk to you about that a lot,
but we really wanted to go the SW360 way,
and we couldn't.
So once again, I mean, we are all for collaboration.
Oh, yeah, Bradley.
Do you have any plans to assist your users
in meeting their legal obligations,
or are you just trying to identify what the legal obligations are
and not actually assist in meeting them?
Oh, no, I mean, we do.
Sorry.
I'm sorry.
The question was, do we assist the clients
to meet the obligation, or just identify them?
Well, ideally, both, because the idea is also that
for each generic obligation that you have,
so that they can identify a generic process to do it
and to do it the right way.
I mean, that means that that will be really compliant
with each license that requires it.
For instance, like providing the corresponding source code
and stuff like that.
So you're working on a system to prepare
the corresponding source for you?
No, no, no. Sorry.
We don't do executions of the obligation.
Sorry, I misunderstood your question.
We're really happy to be able to branch out,
but I'm not sure if it can be done automatically.
I mean, I know that in some build system,
it can be done.
But the problem is so that it will really depend
on each build system.
And for instance, just for having a notice file,
and we were, I mean, there was a very interesting talk
about build as bottom,
and I really believe in that.
But the problem, for instance, if you take the Node.js ecosystem,
you have many different build systems,
and some of them have this kind of automatic function
to generate notice attribution.
The only problem is that they're wrong.
And so, I mean, we're uncomfortable
relying on something that we know.
I mean, we can't pretend, oh, it's wrong, we didn't know.
You know, I mean, that's a problem that we have checked.
And so, for corresponding source code,
I think, I mean, we had very interesting talks
about embedded system, and I think that they are trustable.
So we prefer to refer to that,
because I mean, they do what they are doing,
and the process will be just, I mean, pointing them to that.
I don't know if I understand.
We do have a REST API,
so the idea is to provide one piece of the whole chain,
and probably...
Okay. Do you have a question?
Thank you.
That's all right.
Thank you.