About this talk
This talk explores the complexities of compliance with EU regulations concerning IT law, particularly focusing on the Cyber Resilience Act (CRA), NIS 2 Directive, AI Act, GDPR, and copyright implications for open source software (OSS). The speakers, both attorneys from a German law firm, emphasize the critical need for organizations to navigate these regulations effectively due to increasing liabilities. They discuss the importance of maintaining a Software Bill of Materials (SBOM) as a key asset for compliance, linking it to legal obligations and risk management. By examining cases involving companies breaching open source licenses, they highlight the emerging landscape where customers are taking legal action, underscoring the significance of robust compliance processes in mitigating risks. Overall, the session provides actionable strategies for organizations to align their compliance efforts with legal requirements, emphasizing a need for structured approaches.
Full transcript
[music] >> Well, our topic today is as you can read behind me, it's the right sizing first compliance balancing risks and effort. I think you're better. Good to hear. It's okay. Everything's good? Okay, maybe first to ask to Anika and me are two lawyers from law firm in Germany specialized on IT law and we're working I'm now for 10 years and my colleague for round about three
years now, three years. Um specially in the first compliance sector. At most license compliance, but in the rather time also regarding CRA and the other EU regulations. Um and that should be the attempt of our talk today that we try to tell you um what is the right approach to handle risk with the amount of regulations you have to handle in this case. Um therefore I would
give asking just go on. Um The picture we have on the our first slide is just to show you that there is a bridge between the innovation and code on the one side and law and security on the other side. You can use all that stuff that you already evaluated for first compliance or that you should have been evaluating for first compliance. All the first the cyber
security topic and the CRA stuff and therefore it's a bridge between the code on the one side, first compliance and security topics on I'll go one more. In the I would say last half a year, more and more of our clients didn't come with specific questions about legal topics to us, but with a general fear and anxiety regarding the upcoming EU regulations. And therefore, I draw the
picture you can see on the slide behind me. The clients or the companies are about an open sea surrounded um by EU regulations, a minefield. And um with every sweep of the radar, the the impact comes nearer and nearer, and they are just afraid of getting drowned in this process. But it's a bit of a sinister picture, but to be honest, there are good attempts to solve
all these issues. And that is the point where my colleague will start with um some general points regarding what are the current EU regulations and um how they are affected by open source. >> Thank you. So, yeah, if this um slide shows the um the ship and captures how the companies feel, um my role is to explain what um are the actual um acts which appear on
the radar, and later we will see um how they um relate to one another. So, um the slide is about um the broader legal landscape. And first of all, I um would like to map the main legal regimes before I turn to the overlaps. So, um these regimes are, as you can see, the NIS 2, the CRA, copyright, AI Act, GDPR, and product liability. And this is
also the post uh the the point where FOSS enters the picture. Because FOSS is not outside the legal scope. You will see FOSS is oft quite in the middle of it. So, let's start with the CRA, the Cyber Resilience Act. And I assume for many companies, this is one of the most relevant um instrument in the product um in the product context. Because software components, including open
source components, can become can become part of a regulated product. So, once a manufacturer builds a commercial commercial product using open source components, the question is not longer only are we using open source, but the question becomes to how can we use open and meet the cybersecurity requirements? So, let's move on to the NIS 2. The NIS 2 is also about cybersecurity, it takes a look at
the cybersecurity issue from a different angle. It's not about product regime, but it's about governance or organization resilience. the importance and this is quite an important regulation and the importance of this regulation is undermined because the shareholders are personally liable if something goes wrong. So, that means they are very very interested and very keen to ensure that the requirements are met. The next act will be the
AI Act. The AI Act is also part of the digital product safety world and it's based on the new legislative framework like the CRA. And it regulates AI system just across the across their life cycle. The focus is on risk management approach. So, the the AI Act takes or focuses on the high-risk AI systems and most of the requirements are just about these systems. So, let's move
on to the GDPR. I mean, this is kind of the evergreen of the digital landscape. It is not always the obvious fit, but as soon as it comes to personal data, you have to think about the GDPR. So, to sum it up, there's just no way to to getting around it and this is why you always have to think about this act. Then copyright. Copyright is the
heart of the open source compliance and we all do know the old saying code maybe available for free but still the license requirements must be met. So we and we also know the to-do's copyright license text but sometimes also source code or copyright obligations must be met. copyright is something what turns the open source from a technical fact into a legal model. So let's move on to
the product liability directive which is the last point on the radar. The key point is here that breach of license does not always remain just a copyright issue. In the product context talking too slow. Okay, I'm sure it will appear soon again. In the product context it may may also become a warranty issue and that can expose the manufacturer to claims from every single buyer at the
end. So the interesting question is to save time and effort the interesting you need to identify the overlaps and I think there are many points where I can do this in the day-to-day compliance. So a very good example is here to see overlaps between copyright the CRA and I mean at first glance these three acts seem to come from different legal worlds but um they are at
the end there are some overlaps and some matches. Even if the sounds like licensing and the CRA sounds sounds cyber security and product liability sounds like um liability if something has gone wrong already. Um but as I said, once you look how compliance is actually built and managed software-based products, those categories begin to converge. Um in the So, let's take a deeper look at these three legal
acts to understand the points where they match. From in the cybersecurity context, Foss cannot be longer treated as background code because if a product company open source or decides decides to use open source components, the manufacturer has to take them into account when they assess the product on a legal basis. That means they have to understand what just what is in the product, which parts come from
third parties, and how they could affect security. When we go over to the copyright side, I mean here as I said before, this is the heart of Foss and you have to be sure that you play by the by the rules of the licenses. Then product liability and I think this is where the risk can really escalate. I hinted at earlier um and identifiable defect caused by
missing Foss compliance might it don't have to, but it might it could in principle in principle give many consumers a basis to sue their manufacturers. And therefore getting Foss compliance in line is not just a technical nice-to-have, but it is really important as a core product liability safeguard. So, as a takeaway here, the overlap is not not that all these three impose the same obligations. We saw
they do not. But the point is that the same underlying facts matter in the um in more than one legal framework. So, a company using open source compliance has to think about security, licensing, and product [clears throat] quality tivity regarding the same component at the same time. And if it does not, a license issue can become um a product issue, and a product issue can at the
end become a liability issue with which would cause lots of trouble at the end of this can cause lots of lots of trouble at the end. So, in a nutshell, this is what right-sizing compliance is really about. This is what uh how we um named our um our um speak today. Um it's not about doing more for the sake of doing more. It's just about identifying recurring
compliance tasks across um across different regimes, and then try to find a way to sum them up into um yeah, work with them in an efficient way. Um and I think here is a good point to hand over to my colleague because now we have spoken a lot of the theoretical point of views, but now um we will talk about something um or about some cases where
this theoretical um the theoretical topic became real. >> [snorts] >> Yeah, everything my colleague was talking about is currently only a theoretical issue because most of these regulations are not in place, or even if they are in place, they are the deadlines are not met. Therefore, everything you can do to fulfill all the specifications of these regulations, you have some time, but you should start to work
with. What is our I would say evergreen um compliance topic where we uh support our cust- our clients for several years now is the open source license compliance. And [snorts] um in the landscape of um uh use cases or law cases for the open com- compliance topic of the first license compliancing, thing, the latest landscape changed a lot. Some years ago, we had a a minor smaller
group of open source individuals or companies that sued um companies or entities because um they were the copyright holder and um tried to get these companies to fix their open source obligations, fix their open source license points, but um that switched a lot in the last years because the new player on the market are the uh consumers, the customers. that is in one point critical because when
you think about it, you have a small amount of motivated open source developers that or entities that try to force other companies um to get uh the the right compliance level for open source, but when you think from a customer perspective, you have millions of people that are potentially not even interested in the open source topic, but they don't like the product. They don't like that the
product is defective. And now they have the possibility to sue from my point of view nearly every company country around the world because open source is everywhere uh and most of them do not fulfill the specifications um that are relevant uh for a compliant and then not defective product. Um and then you can start as a customer to think about, "Okay, I don't like my product. Potentially,
I don't like that they uh don't fulfill all the open source specifications." And then you can go out, take a uh legal company like us or look on in your own and then afterwards um state claims to the company that um provides you the software. And three cases I have provided from the last two or three years. The first one is one that our company on our
own currently uh sued against uh Chinese car manufacturer SAIC. Um they produced the car an MG um MG4, I think it is. Yeah, it is. Um and when we looked first into the car which we leased from a German leasing company, there were nearly No, nearly there were none open source compliance level whatsoever. No license information. You can't get any information where the source code is from,
not even an a written offer to getting the source code. They're really nothing. And that is from our point or not from our point, what we evaluated, currently the point is nearly all the Chinese car manufacturer. They were you have a a big variety of companies that you can sue if you want to. Uh, we tried it with Dike and um from the we have nothing point
to currently we are in the law case. Um, they adjusted a lot. They did a lot of work to get better. There are now some license information. They try to find the right source code for us that we can look into it, but they are far from getting everything we need. And we are I would say 3/4 of a year into the lawsuit. And that is not
enough to be honest. And if you have not a car where maybe some the court will give you some time because it's a big product and yeah, it's difficult to find everything. For smaller ones like the other two cases for example, you can lose this law case in half a year because your um plaintiff says, uh, I want you to fix it. You can't fix it. He
um rejects the contract and want to give you the product back. And then in the end, you have the issue that you don't ask talk about um how can I solve this issue, but you have a customer who wants his money back. >> And these are the two other cases for example a more I would say in a um low price customer segment. That was two cases
that were um supported by the SFC, the Software Freedom Conservancy. Yeah, Software Freedom Conservancy. Um, they copyright owner, but all the other entities um to if they have lawsuits regarding open source compliance. And they on the one side it was a German case with the company AVM with the Fritzbox, um a router in Germany. The local case was settled by a settlement between the parties, so there
was in the end um no ruling by the by the court, but as far as I know from a discussion with the SFC guys on the first time 2 months ago, um they nearly got everything they wanted from the firm. They get the open source license information. They get especially the source code with the installation information, so everything they need. I think the only point they settled
was about disclosure. >> what is allowed to be talked about of the local case and what is not. The other case Visio is still ongoing. There the big topic is because Visio is um using signature processes to secure the software, and now they're arguing about um are they allowed to use these processes, and what about the signature keys, and which part of the software you can get
for the GPL part. So, these are for for us as a legal entity a big lawsuit to get hopefully better information regarding from a court um what you have to do and are not allowed to do in regard of source code disclosure, but the big picture is you have now new players on the market, and they are willing to sue companies. Um and you should be from
our point of view more aware than ever um of your open source license compliance besides that regulation >> with the head of the on the other um slide we already showed you. Okay, now you have some pictures about what is getting wrong and what is the issue, but now [snorts] let's start to try to solve these issues. Um when we talk with our clients, most of them
come to us with um the general question, I have a huge load of open source in my product in my software. How to [snorts] handle that? And their approach before they start talking with us or talking with with their compliance officers is typically panic, do nothing, ignore everything, and run into these cases, or use the same level of open source compliance for all their software which typically
overwhelm them with the processes and information they have to gather and the steps they have to perform to get all the information they needed, do all the documentation they needed. And therefore, the from our point of view, the only viable attempt in this case is to funnel everything down, to get some filters on your project landscape, and then afterwards put these filters on your projects, everyone or
every single one, and then funnel it to different pools with strict license processes behind it in regard of the risk you get from the several projects. And as one example for an easy attempt to get some filters on your project, the easiest one from my point of view is project risk. Do you have a project that goes into the customer market, or do you have an internal
project? Easy to understand if you have a customer portal for portal for example, if that shuts down because to an copyright infringement case or CVE or things like that, then that is a big issue. It's the worst case you can get it, but if you have an internal for example, I don't know, vacation tracking tool, if that has to be shut down, that is inconvenient, but yeah,
never mind. Another filter can be a good and easy to handle one is your supply chain. >> When you have a product that use which is totally developed internally, you most of the time have the information from your developers or it's easier for it to you to to get him to work and tell them what to do to get the relevant information, but it gets more and
more tricky if you are having for example a big operating system with uh two to 10 uh suppliers in a supply chain where especially the communication can take a lot of time. Even if you have the questions you want to ask or the information you need to know um to state your questions through these uh channels and get the answer back. And then if the answer is
not correct or not good enough, state the question again. That could take weeks to months that you don't have in a low case. If someone comes and sues you for for example um first infringement or theory infringement or things like that. two filters easy to handle are the complexity in your supply chain and the complexity in your product or the the distribution channel, for example. A third
level and a fourth level, but that which are a bit more into um that you uh have a thermal knowledge about what the legal topics are could be for example if you could uh take the regulatory risk because most of the ongoing or oncoming um EU regulations um demand the most obligations for critical infrastructure, for example, medicine products or um telecommunication software things like that. So, you
can there um decide is your software that you or all your software projects are they in this critical material or are they just basic I would say a company program that you for example then distribute or not. The last one I often tell the customers because it fastens the process is to when you go to license compliance uh rate your open source licenses that your company is
allowed to use and then take for example really permissive ones. Everything like MIT, BSD, green stuff if you want to uh put a system on it. Um easy to handle, nearly in every use case usable with some obligations that can be handled. On the other hand, you have for example a GPL 3 as the most restrictive one from the known ones. Um can be handled, but for
example, if you have a system like uh an airplane or a car, you should think twice by using them in that product because there are a lot of obligations to be fulfilled for these licenses. Therefore, if you take your licenses in a risk assessment, you can say, for example, good to use, we should talk about it, don't use it at all. And then in the end, what
I already stated on the beginning, just to try to funnel your projects, use one or two of these filters if you want to handle it easily or take more and more if you get it a bit more complicated in the funneling, but then afterwards a more specific system that you can put on the output of everything you get. And for example, at the easiest attempt, complexity in
distribution or the channel and the supply chain channel. If you have a big customer program with a huge amount of suppliers, you should think about contracts with your suppliers. You should think about getting an S-bomb, I would say, once a week is maybe a bit much, but at least once a month and update them especially in the process, not at the end when you are short for
SOP. On the other hand, if you have an internal project without any suppliers at all, I would say, once half a year handling a general S-bomb, going through the CVs and the [snorts] licenses, that should be enough. And that is, I think, the takeaway from this slide is 80% of your sources should go to the we call it level one, that is really critical stuff that you
evaluated goes to customers, has suppliers, has critical licenses, triggers or most of the regulations. That should be your most focused. Most of the other stuff that is more and more or less and less risky, the effort can be, yeah, I would say, feasible, but you should How do I say it? You should um take the approach you need and the approach that is possible for your company.
>> Thank you, Florian. And you've already teased at the S-bomb. And on our next slide, practice and tools, the first assembly line, um we will talk about exactly this, the S-bomb, which is the most practical CRA obligation. As people who work with first every day, of course, we are all familiar with the concept of the S-bomb, but the CRR is raising the importance of the S-bomb to
a whole new level. Because under the CRA, the best S-bomb is not longer just an internal developer list, which is a nice-to-have, but it's part of the manufacturer's compliance setup. Under the CRA, um manufacturers are required to keep an S-bomb on their products. And um just to sum it up, we all know the S-bomb gives a structured overview of this component in a product, including dependencies. So,
it um leads to visibility. And this visibility is important because manufacturers are expected to exercise due care when integrating third-party components. And this is why they need to know what is in the what is built into which product, and they also need to know all the dependencies. And that way, if a security issues appears, they can quickly assess whether the product is affected or not. And if
this vulnerability is identified, the S-bomb helps to lead exactly to the um affected component, and it also helps to uh come in exchange with the supplier and um with the developer. So, regarding the workflow, we think the following is one good option to follow. So, the practical answer is not to treat visibility as a one-off exercise. You already said it, creating the SBOM once and then not
thinking about anymore does not work and is not a good idea for a dynamic process. The real goal is to build visibility into the development workflow and this starts with an automated SBOM which is integrated in the CI/CD pipeline, so during the whole process. Um and when this is the case changed components and dependencies will appear early and ideally before the code is merged because then there
is the that you can react on the situation fast and you have this is only possible when you have this dynamic process. So, the SBOM is not not just something that exists, but it's a living a dynamic document. In our daily exchange with developers and we have many calls every day with developers, we see or recognize that many companies invest in powerful tools and then invest a
lot of money and don't get me wrong, these tools can be very helpful, but buying is the easy part, the hard part yeah, to use this um this tool correctly. So, from our experience, tool tooling works best when it's backed by a functioning process and this is where pragmatic model often works best. So, first the developer has to understand his own build pipeline and then semi-automated tooling
can be a very a very good choice. For example, open source available toolings scanners, sorry, like Fossology, the Alt Scan or ScanCode. And then when the this scanning is done, you can decide whether legal technical questions legal or technical questions so complex that the human brain is still needed and it has to be evaluated by a legal or technical expert. This point is a good opportunity to
introduce you to Octet. Probably some of you will heard about it before. Octet is an EU founded initiative that supports small and medium-sized enterprises and open source project in becoming CRA ready. So it is a tooling with the helps and it offers a practical CRA orientated cool toolkit which bundles many functions. For example, compliance compliance guidance, reporting sorry, assessment methods and much more. So if you're working
with SMEs or if you're working with open source product under the CRA, Octet is really worth taking a look at it. freely available. It is EU founded. So we just tried it and I must say it was quite interesting to to use it to get in first idea of how CRA compliance could work. But the CRA does not start stop at the S-bomb. I said before that's
probably the most practical obligation, but there are some more. In general, the regulation expects manufacturer to build products securely from the outset. So that includes from the beginning risk risk-based development to include security by design and security by default aspects, limiting attack surfaces and um the conformity assessment which can be in-house or out-house. It depends um on the criticality level of the product. And and this is
very interesting, the obligation also continues after market placement. So, um manufacturers need to have processes in place for the case that any um vulnerability issues come up. So, the vulner- um the period um um the support period is quite long. I think the minimum is 5 years. Um and that means the um manufacturer are responsible for a very long time for their products. Um in detail, they
must provide security updates without undue delay and generally free of charge. So, they have to calculate it at the moment they bring the product on the market because they can't um they can't um ask for money when they um have to um clean any uh vulnerability issues or take care of any vulnerability issues. Um then maintain technical documentation. Um they have to define the support period, as
I said before, minimum is 5 years. And um monitor and remediate vulnerabilities during that time. So, it's a very long list and um many uh requirements which which must be fulfilled. So, let's come back as this slide is all about the S-BOM. I think it became clear um during what I just said. It is not just about you need an S-BOM. Um because the S-BOM is not
useful at itself, but it's only useful if it's operational. So, it has to stay current. Um it has to be linked to dependency management. And it has to be built into the workflow. And that's when when that all of that happened, then it turns from paperwork into something um which is um which has real effort and which helps team to work with it. And um that brings
us to our next step. Um, once you have the visibility, what does it mean for compliance more broadly? I'll have a hand hand over to Florian for this. >> Hm, we are running a bit out of time, I see on our timestamp here. Therefore, I will shorten this um, slide a bit because I had two or three more slides I want to talk about. Um, the S-BOM,
as my colleague said, is only the start about everything. And now comes in place what my colleagues also said at the beginning. You should try to uh, summarize your processes for the different regulations into one process at best, or at least in not one process for each of these regulations to fulfill everything. A good example for that is the the S-BOM, as I told you. Um, when
you have your S-BOM, your list of components from the first to the depths, everything you need to know about your components and who they are, then you can start from that point in two directions. The one side is the legal um, the the first license compliance. Because when you have your components, you typically or at best has all of the code you can evaluate with all your
scanning tools, stuff like that. On the other hand, you can do the same um, first step of your process and go to the other side regarding um, Cyber Resilience Act to evaluate are these components affected by CVEs, by known CVEs? And then the big amount is the S-BOM evaluation the the the integration of your system that you can get all the information. The two other steps that
are after that are easier to handle, especially when you have all the information at once that you need to to proceed step two and three. Therefore, um, as one example, use all the processes you have and think about them and try try consume them in one entire process at best or not that good, but even better than having one process for everything, two or three processes where
you can start or in the midst of the process use the same information to get then afterwards to the specific topics you need to talk >> So, thank you. And now after the discussion of how first compliance at the CRA interact with each other, this slide brings it all together. We called it push to button compliance and I kind of kind of like this very visible wording.
Um so, what we what we are really aiming for is auditability, And in practical in practical terms, that means you have to be able to say in what product is which component under which version. Um and at first it sounds simple, but um remember what we said before, we need a dynamic S-BOM to be able to give this answer immediately. Um and and therefore necessary is a
good documentation, dependency tracking, and vulnerability management. Um that means under the CRA, documentation is not optional background work, but it's a basic condition to be able to fulfill the requirements at the end. So, the practical tip is here um to implement quality gates. No release should go out go out unless the S-BOM is current and the evaluation results show that the um vulnerability situations um has been
checked. So, um from a legal perspective and we are lawyers, I would advise my client not to place a product on the market until it has a concept which um makes this push to button compliance possible. So, um if this is not the case, um there is a legal risk um that the company may not be able to fulfill um the CRA obligation, especially because we have
this very really short um short time slots um when an um security incident occurs to um notice that to the authorities. So, the key takeaway is simple. Um push-the-button compliance is not just a slogan, but it's a process. And um if it means making sure that documentation, SBOM, vulnerability uh handling, and first real real part of these relief pass um then um this push-the-button compliance can work.
And when questions come come up, they can be answered quite quickly. >> Mhm. So, this was we as I already said, we nearly had the same speech on the FOSDEM in Brussels here 2 months ago. Um and this was the end of our talk. And afterwards, we had some time for questions. And none of the questions stated were about our slides. It was nearly all about "Am
I an open source steward after this CRA?" And what are the concerns about that? Therefore, we or I decided to include two more slides because after our talk though in the talk, I had no answers regarding everything that was asked because there was nothing more than this CRA and the uh short text in the regulation itself um some titles. But afterwards, the EU Commission itself um published
some FAQs um regarding who's an open source steward and who's not and what are the obligations things like that. Though, this is not based on my own thinking. That is one-to-one. You can read it here in the um slides. One-to-one the uh working sheet for to say it that way um how you can evaluate if you're an open source steward, a manufacturer, or outside of the CRA.
Um to be honest, all of these points are stated in the FAQs, and some of them are described in the FAQs. But still with that, I can tell you for each of them, there are still questions not answered good or not even at all answered. it is just the best we get up to now. Um even with the FAQs of the org project with I heard about
on the first time today, to be honest. I read through the FAQs before our speech to find out if I can find some more information regarding some of these topics, but even with them, there is not much more information than that, and would everyone should read a rather good explanation of 5 to 10 pages, who is an open source steward after the CRA for the EU Commission
Um we only have admin to have a through it. First of all, you have to um your your product or your software has to be a product with digital elements. That is the basis, without that you can't get into the CRA at all. Then you're out of the scope, that's it. It's easy to evaluate for an operating system, but it gets rather complicated when you think about
I have a library I don't know, for a user interface, or I have a cryptography software. I am a product with digital elements or not. I can tell you from scratch for for There is no general answer. You have to each product, and a detailed analysis of what are products with digital element would extend our speech hours, to be honest. The next point is are you responsible
for publishing the first? That is a point that doesn't come out of the CRA itself. It's a something read into the regulation in these FAQs, but I can understand the approach because what they want is they want to get the support of the maintainer of code bases. They don't want to get the information from contributors, which most of the time can't help you with the obligations of
an open source steward or even a manufacturer. Therefore, it aims for the maintenance of software. The next, and that is a critical um switch left or right, is do you or are you placing a product on the market uh as a commercial activity? And that is, I five to six pages of this FAQ is what is understood as I am placing it on as a commercial product
under the market. And uh just some some general information. So, you're selling it on the market. Uh what about if someone supports me with donation? Can be on the market placing if the donation supersedes the uh amount of money I need to uh produce this software? Then I get a profit out of it. That could be placing it on the market. Um what about if a company
uh supports us with minor donations, but wants to then afterwards afterwards um commercialize this product because they supported us? Not placing on the market if the money they supported us does not extend this um amount of creating the product. It's not relevant if a company or a commercial company is included in the developing process. So, it's really tricky and you have to evaluate from the entire project
um are you a person who placing it on the market or not? Then you're most of the time a manufacturer. Uh the only uh exit is if you're a not uh for-profit organization, and then all the money that exceeds um the cost for producing it and for the developer to live on it um should be spent or everything should be done, but no profit uh is allowed
to be gained. Um then you can come back to the open source steward, or if you're just a uh single developer, though no entity, um you can even get outside of the scope of the Sierra A, but I thought with the FAQs I had all the answers I needed, and then I read through it and tried to get some of the points I were asked on the
FOSDEM and find a straight way through the system and I struggled with nearly every of the projects I were told months ago. Therefore, there's a lot of way to go. Maybe the last good point is if you're just an open source steward, if you don't want to care about the CRA, you just don't have to because there are obligations after the CRA. You can see on the
right side there are some, but even if you don't fulfill these obligations, there are no fines for it. Especially open source stewards are excluded from the finding in the CRA. Therefore, there are obligations. You are asked to fulfill them. It is good if you can fulfill them because it helps other people, but you're you can't be fined or sued if you don't fulfill them. You're an open
source steward, you're still free to do what you want, to be That is, I think, our talk for today. Now we have 3 minutes that could be one last question or if no questions, also good. >> [laughter] >> There it is. Oh, wait. We have to Wait a second. >> So, I have two questions, but I'll I'll I'll give you the one that I just thought of
here. Um are there any obligations for an open source steward who, you know, has no obligations to the CRA, no possibility of being fined at least, uh under any of uh laws that you mentioned, particularly the product liability or product liability directive. So, if you are an open source steward, you are publishing an open source product uh that is non-commercial still, you might still be a steward.
Can you be sued under the the product liability directive? >> Though, um from my point of view, but maybe you have another Oh, yeah. Yeah. Sorry. >> So, um I think it it really depends here more or less all open source compliance you find a no warranty disclaimer. So that's quite a evergreen and it's all this licenses, but you're completely right. You have always to check whether
this is valid. Um and here I'd say you can't be 100% sure, but I attempt to as it is license on a license, but you do not have to pay for it. You can discuss what kind of contract it is. Maybe it's just a a gift. So then they are under German law. So we are German lawyers. I can just talk about that. They are only very
very small requirements you have to fulfill and it's quite hard to enter um the border that is liable that there is any liability uh issues. Um but yeah, you're right. It's something this CRA is quite new and um I think this is something >> the product liability regulation. I think um they the new regulation don't wants to switch the in general system regarding open source is for
free and something that it was taken over in the the German law, but all the other EU national laws, if you get something for free though if it's not purchased to you and that is something the regulation doesn't trigger. I think that's the point you want to go. Doesn't trigger that good to be honest because now under the new regulation also open source and software can be
a product that falls under the regulation. Um From my point of view, it wasn't the attempt to put open source under this regulation and even if the regulation itself um there is a possibility to read open source as a product that falls under this regulation. At at at the latest some FAQs will will will finalize this point in regard that open source won't fall under the regulation.
It's more or less the same as for the CRA. If you first read the regulation, you can think, "Wow, we are doomed producing force because we are a manufacturer. We have to do everything. Let's skip everything and run as fast as we can." But, in the end, when you have this not really precise regulation points, I think the first FAQ, and we have some time with the
product regulation point, will clarify if open source is affected. I think potentially will take away in between. Though, it is affected, but you have to you can skip point A or B or C um that you get to a appropriate amount of liability for the open source owner, like the open source stewards, but not the full set of obligations you have to fulfill as a uh manufacturer
is not the right word, or the purchaser um after the um regulation regulation. That is the best answer I can give currently. We talked about that earlier today. Um it's everything in the in the run. >> All right. Thank you very much. Uh we ran out of time. Thank you for the great presentation. >> Thanks, everyone. >> the question. >> [music]
