So, from circuit it is, and we are about to start a larger block about the cyber
resilience act, and we will kick it off, Jimmy will kick it off with the talk on the CAA
contribution applications and challenges.
Cool, let's see, yes, this works, that's awesome, that's a great start.
So my name is Emelberg, I work as director of open source policy at the Ericsson open
source program office, for those of you that are wondering, yes, Ericsson are still around,
we don't make mobile phones anymore, but we do make mobile networking infrastructure
such as 5G network equipment that we sell to CSPs and making sure that you can stay
online at all times.
Dear phones, the views in this presentation, since I am a lawyer, full disclosure, are not
necessarily those of my employer, so these are my own views.
My job at Ericsson, I said I am director of open source policy, of course, that's a made-up
title, right, doesn't mean anything.
So what do I do?
Well, I am partly a lawyer, I am partly a guardian for Ericsson, in terms of risk, IP, copyright
and so forth.
I am also a bit of a gardener in the sense that our work is to, oh, I should be here.
Cool, I need to curb myself, yes, I am now glued to this quote.
Okay, some bit of a gardener in the sense that we help grow open source both internally
and a culture of that, but also externally, in the projects we are engaged in, a bit
of a translator between engineering, legal and business management, trying to explain
like this strange things of open source, why does it make sense?
Why should we be doing that?
Why should we be giving away stuff for free, right?
And I am also a little bit of a cultural anthropologist, that is a very hard word, I will
take a moment to explain that.
A cultural anthropologist is, you know, those brave people that go out to the Amazon live
there for 12 months, among the local population, instead of study how they act and work.
I am not quite so adventurous, I will not travel down the Amazon river and live with the natives.
Instead, the culture and tribe, I study are software developers and, like today, I am dressed
as the warrior cast of software developers, the open source people.
And I also sort of occasionally need to go back to the human village with the grown-ups
at legal departments, that is way less fun.
So open source at Ericsson, why is what I talk about relevant towards the scale we do?
I think about mobile communications network, there is something quite closed, there is no open
source in there.
Well, there is a lot of open source in there and we do use a lot of open source at Ericsson.
So this is the number of new components, top level components, not including dependencies,
new components we introduce each and every year.
That might be a new version, but no components or something completely new.
So we have a lot of new open source components coming in each and every year that we need
to manage.
And that is of course high-per-relevant from a CRA perspective, one we need to deal with
that.
That is not exactly what I am going to talk about, but I have figured, I give you a reason
to listen to me, right?
So the CRA awareness curve, how does that look like?
How does that look like for any person or organization?
And those of you that heard me talk before, I usually use a version of this slide and I'm
lazy, so I'm going to reuse it and just rename it, CRA.
So at the first stage, you're at the denial stage, we're not going to be impacted by CRA,
right?
That's some weird legislation.
Either we're not going to be impacted because we're not in Europe, or not European
company, or what we sell doesn't have any problems, right?
And I go, like, oh, this is a huge risk for us, we really need to deal with the CRA.
And then, I'm going to bring the boring stage, like, if we please just not impacted by this,
if there's someone at the Commission, we can talk to, could we not sell stuff in Europe,
like how do we get out of this huge compliance and regulatory burden you have just created
for us?
A huge depression stage, we are screwed, there's no way around this, right?
So hopefully, in the end, you will get, like, the acceptance stage, the final stage of
grief.
This is okay, we just need to be smart about it and develop strategies and most importantly,
processes to manage the CRA and CRA implementation.
So for those of you who don't know, I made a stupid assumption of thinking, I would
not be first among the people talking about CRA.
So everyone knows what CRA is.
Lots of people know that CRA has, even people raising their hands, great.
But for those of you who may be joining us on the stream, that doesn't know about CRA already,
this is the very simplified version of what it is.
If you don't know about CRA, the focus taking the 36 months of started, so we better start
looking at this.
And this is a legislation from the European Commission that concerns all product with digital
elements.
Essentially, it's a C-marking for software.
Fundamentally, it's about not shipping software with known vulnerabilities and reporting
of vulnerabilities you find.
And if you have fixed stuff, you need to fix it upstream as well.
And about shipping as bombs, or at least have them available to ship and provide to the
national bodies.
And potentially, it's very expensive if you don't comply.
That's why you should care about it, at least if you're a company.
So a little bit in detail about the CRA.
So let's highlight what's important and what we're going to cover in more detail here.
So where manufacturers have developed a software hardware modification to address the vulnerability
in the component.
They shall share the relevant code or documentation with a person or entity manufacturing
or maintaining the component.
We're appropriate.
They should do it in a machine readable format.
So this is, in my view, a really, really big change in the way we need to think about open
source and the economics incentives around this whole thing.
Because it used to be that, you know, you could take stuff, you could consume them.
It didn't necessarily need to contribute back.
There's plenty of good reasons why you should.
Don't get me wrong.
But you didn't really have to.
So if we run through this scenario that we have an open source component, we like this
open source component.
We're going to put it in a product, but after a while we discovered that this has a vulnerability
to it.
Okay?
What happens then if we go back to this text, what should we be doing, right?
We're going to run this exercise.
So open source component into our product, we find a vulnerability.
The first question that I would ask is, have you developed a fix for this?
Yes or no?
Well, if no, then you need to report the vulnerability to the owner.
And I do, I use that's not the term in the CRA, but it's, it's fitted within this box,
right?
It was easier than manufacturer or open source keyword.
So let's use the term owner for now.
Zinn is reported to the owner.
And, you know, that might get implemented and addressed in that component going forward.
This could, at this point, be a proprietary component or it could be an open source
component.
We're going to assume that's an open source component, because that was a bit put up there.
Okay?
So, assume that this is an open source component, we found a vulnerability, we have actually
developed a fix for this as well.
So, the next question we need to ask is, is this a permissive license?
There is it BST, this is MIT or something similar.
Or is it a copi-left license, like, for, in that case, that leaves us with a number of options.
In the case, where this is a permissive license, I mean, we can either contribute the fix-up
stream under that license or a compatible license, upstream to the project and, you know,
they can do what they want with it.
But the CRA also leaves us due to language, the opportunity to contribute this on their proprietary
license.
There's no requirement to provide it under the same license.
However, in the case of a copi-left license, then, of course, in both these cases, it's a derivative
work, right?
And we know that under copi-left derivative works needs to be licensed under the same terms
of conditions.
So, the same license needs to apply.
So, for companies, this becomes really, really interesting, because normally, at the
large corporation, your open source policy might be that, well, we're not going to contribute
to the IPL projects, or we don't contribute at all, or we have a long and winding process
to contribute into a project, even if it's a small bug fix, because we're really super scared
about this open source thing.
So, this really changes that, right?
Because, like, under permissive license, these companies that are scared of it, they can still
provide under proprietary license, or provide it in some way, shape, or form, or they
can provide it under permissive license, which may be less scary.
But, for copi-left, they really need to do it under the copi-left license.
So, yeah, here I talk about a little bit of a significant substance, right?
And it sort of, for me, the significance here is that it's truly shift, that's the voluntary
nature of this.
This is no longer something you can choose to do, especially in Northebut Steepel.
You need to contribute this back up stream, like historically companies, like it or not,
yes, there's everyone they do, what's good for them.
They contribute, what benefits them, when it benefits them, I have 15 minutes left.
So, for me, that poses the question, right?
Building this with the CRA, will this impact what open source companies select?
Will they be less likely to select non permissive licensees with this?
Because all of a sudden, they don't have the option, if we go back, they don't have the
option to go with a proprietary license and contribute the back in, they don't have the
option to contribute under that, they need to contribute up stream under that.
Will it impact companies' contribution policies?
Will the requirements in the CRA necessitate that companies make it easier, quicker, faster
to contribute these bug fixes and fixes?
Will it impact the policy of fixing contributions?
So, if I'm a company and I'm scared of this thing, or if I'm for some reason don't want
to do this, will my policy be, I'm not going to fix this, I'm just going to report it,
and let someone else do it up stream, we're not going to fix it until because we don't
want to be contributing off stream to these projects.
I think those are important questions to ask.
I don't think they necessarily were asked during the CRA process, but I think it's something
that should be asked now.
Also, CRA for me, it's supposed to be a question.
Is it likely how easy it will be for a company to fulfill its obligations under the CRA?
How easy a project makes it for them to do that?
Will that impact their choices?
So, for example, if I have an old abandoned component, will I now be less likely to select
that due to the fact that if I discover a vulnerability, there's definitely no one upstream
that's going to react to my report, and I need to fix it myself, but then I also have the
requirements contribute that back off stream, but there's no, if there's no one receiving
it, like have I really fulfilled my obligation then?
So will this mean that sort of abandoned where will be even less interesting to use?
Maybe that's a good thing, and maybe not, right?
But I think it's an interesting question to ask if this forces us to sort of be on more
current versions or newer software or active maintainers.
For example, if I put on my boring lawyer hat and ask the question, like, okay, so we
have developed this fix, we have shifted, no one is answering us, do we know they have it?
Have we fulfilled our obligation?
Because I'm going to be a lot happier if that project responds, hey, thank you so much
for your contribution, we have received it, your obligation under this theory is fulfilled.
That's going to make my life a lot easier, because I can take the box like we did what
we were supposed to, we can cover that a little bit again, and also with software as a service,
it's normally, you would think that, okay, we offer this as a service, we don't distribute
it, DPL doesn't really impact us in that way.
What I find interesting is that the CRA also contains this language around remote data processing,
meaning data processing at the distance for which the software is designed and developed
by the manufacturer or under the responsibility of the manufacturer and the absence of which
would prevent the product, which is the elements from performing one of its functions.
I, if I sell you a product and I remove the data processing, does it do everything I told
it would do when I sold it to you, and if we remove that, okay, but in that case, then it's
covered under this scope of the CRA, and if this remote data processing then contains
a vulnerability, we need to fix it, but if that's remote vulnerability, due to the couple
left, effects will also impact my fix, mean that fix needs to be couple left, all of a sudden
normal GPL is a lot closer to AGPL than what it used to be.
So in that sense, the CRA shifts to AGPL to something that is a lot closer to AGPL, I think
that's an interesting thing, it's not necessarily a good or a bad thing, but I think it's
interesting.
So software as a service, that's not necessarily a shield behind any more for these things,
which I think should have implications for the compliance work on these things as well,
and the homework the companies should do even if they're offering a software as a service.
We can look at one more interesting detail here, because this is the text, and it also
says, or documentation, about this GPL thing, and it's a couple of things, is it an
off that we supply documentation, and documentation doesn't necessarily have to be a derivative
work.
The documentation could be, well, you know, don't run that function, or remove this, right?
Have we satisfied our obligation then, is that sufficient, or are we still impacted by
co-pileft in that case?
Well, maybe maybe not, I guess we will see, right?
I don't think that's the intention of this language necessarily.
I think it's probably meant for when there is no, when this is not possible to fix,
via software, it might be that this is a hardware issue, it might be something else, right?
So, I'm not necessarily thinking that this is what they intended, but this might be the
result of that.
I don't know that that's necessarily something we should be happy with, I think it's
probably better if people contribute, they actually fix, rather than do the work around
the flag.
Yeah, we have the fix, but now we're going to rewrite that fix into documentation, and
you guys have to implement this.
Okay.
I think we've gone over most of this, so what I would like to do is talk like some potential
issues, right?
So, for example, and I will move into QINA.
All of you guys look like you're really following, so I'm not sure there's going to be
any questions, so there's going to be lots of them, we'll see.
So, say for example, you're on the exclusivity agreement with one of your customers, and
that's exclusivity agreement says that everything we develop under this contract for
you, that belongs to you, that's your stuff, right?
We have to develop it for you, that's very standard.
Or you have joint ownership with them of what you develop in an R&D collaborations, like
we own everything together, and we all need to agree with what we do with it.
Or you have issues of patent ownership, like patent ownership is one thing that could come
in.
Or other questions that could be potentially issues.
If anyone could come up with more of these, let's bring them up during Q&A.
I don't know if these are good solutions or not, but I mean, to the issue of if you
have exclusivity with your customer, the problem then is, of course, that I have promised
you exclusivity with everything I developed, even the things that were derivative works
of copyleth software.
But now I'm forced to make that available, I'm in breach of my exclusivity towards you
my customer, because this is the array says you need to contribute this, my contract with
my customers says I'm not allowed to make it software publicly available, because it's
his.
But I have developed a fix, and I have it.
I mean, at reasonable solution would be to talk to your customers, say, hey, where
this serial obligation and this fix is really not that important, but that's, of course,
the reasonable thing, and like if people were reasonable, I'm a lawyer, I would be out
of a job.
So maybe that doesn't work, maybe it's better that you take into writing, in these
agreements, that well unless it's for CRA purposes, then I'm allowed to, to fulfill my
legal obligation on the CRA top screen this, right?
And of course, most contract has this, like, abiding by applicable law clauses, but is
that sufficient?
I don't know, maybe it will be, maybe it won't be, but it definitely can't hurt, at
least in terms of your relationship with your customer, say, hey, this situation might
come up.
We need to deal with it and do that upfront rather than relying on those clauses, because
even if you're allowed to do it, that relationship with the customer will certainly be
more stower if they are not being reasonable.
And another thing is like, well, this might impede you, but not your customer, if the fix
is developed in the US, for example, by your company, but you have the same open source
software that's also deployed in Europe, and you know the same vulnerability applies.
Well, then your US customer, it's definitely going to say, well, abiding my applicable
laws, I mean, the applicable law is here at US laws, so I really don't care about the
strange CRA thing in the Europe, you're not making my software available source.
So the question is, do we need more specific language on CRA?
Maybe.
And another question is, can you require an NDA to be signed, along by the code being provided
up screen?
I don't know that there's anything to say, preventing it, it might not be a good thing,
but that might be a path to be built take, I'm not sure that's a good thing, but it's
also might be so that to provide the fix, you would be provided, you would need to show
some stuff that are either trade secrets or stuff that you're simply not willing to
share, you shouldn't be sharing, like personal data or so, so maybe you need to
require science NDA sometimes, that might be a solution.
And then, back to the question, can you provide documentation?
Maybe?
Other ideas for how to solve these things?
I think with that, we can move into, like, the Q&A part of this.
Anyone with a question?
Okay, let's start this.
And it would be great if next guys, really, for from us, that guy had to run really far.
So, thank you for your presentation, and hello from Sweden.
One question is that we have issue with software where we discovered a security vulnerability
in, and we did a report and also right how to reproduce it, and we're very lengthy, and
it got to response, nah, it's not the security issue, but we could show them that it's
a real issue, how did you do that?
Well, I would say that that's the case where you have done what's up on you, and it would
be upon that project.
They have no responsibility to implement what you give them, right?
Just because you have developed a fix, it doesn't mean it's a good fix.
It might be something that's not relevant, or it might be something that's, you know,
it's the garbage and trash, and we'll sort of, like, hey, all developed fix is that
as soon as you hit the run on this, it just shuts down the program.
Okay, well, it fixes the security vulnerability, but you introduce another of other bugs, right?
So there's no requirement on the project actually take your fix, but they have to receive
it.
And in my view, that's kind of where that, that obligation ends, right?
Then there's other things on the project that they might need to do, but in terms of the
relationship between you, the project, that's where it ends.
They have received it, now it's rest up to them.
Hi, thanks by the talk, it was an interesting insight on, yeah, interesting questions.
Like I thought about, I'm aware that many companies fear using a copy left software if they're,
especially if they're based on, like, proprietary business models, but you mentioned several
times that these companies might also fear contributing back to some, yeah, a copy left software,
so in the first place, why should they contribute back, even if they don't use this software
at all, the first place, and even if they would use copy left to software, what's the
metric with contributing back?
So there's no, I don't see the legal risk here for all the companies.
Okay, so in the first place, I think there's very few people that use absolutely zero
GPL code or copy left code.
I think there are companies that may think they don't, they don't use it, but I think
during the process of CRA, they will become aware.
We've seen that time and time again, so it's like, yeah, you're telling me this, but
I'm pretty sure that somewhere in your stack that sits a few DPL libraries, so they are
using it, and reasons might be, right, that they simply don't understand it or they don't
have, like, in large organizations, there's processes for most things, right?
There's no process for this, like, we don't know how to conceptually deal with this,
that might be one thing.
Another thing might be that the GPL, at least GPL version, three contains patent provisions,
that they might be seeing that as a problem, no, we don't want to contribute it out, because
we would expose these patents towards that, because that functionality is not previously
introduced into that project, and we have no intention of contributing that, that might
be one such reason.
Did that somewhat ask you your question?
Hey, great talk, thank you.
One question that I had was you, one of the things that you had on your list that you kind
of glossed over was abandoned projects, and I was wondering if you could elaborate a little
bit on that specifically, I'm thinking about server-side components that might be
part of such types of abandoned projects or abandoned products.
Okay, so I will try, and this might not be a good answer, but essentially my fear here
from, like, again, boring corporate lawyer, printer-reduced risk is if we have one of these
components, and it's an abandoned project, maybe even, like, we have the source code,
but since the website has shut down, we have no way of contacting the former owner of
this.
It's pre-github.
It was available on something else, or this is anonymous user on stack.