Taming the SBOM chaos – A legal compass for the CRA and open source compliance

This talk covers the complexities of using Software Bills of Materials (SBOMs) for compliance in open source software. The speaker, Hendrik Schüttler, a lawyer with a background in software development, provides an overview of what an SBOM is and its necessity in the context of regulatory compliance, particularly under the Cyber Resilience Act (CRA). He emphasizes the importance of understanding license obligations and the need to include complete license texts when distributing software. The session also highlights the potential pitfalls of neglecting pre-contractual disclosures and the legal implications of software distribution without proper compliance documentation. Overall, the discussion aims to clarify the legal landscape surrounding SBOMs and their role in ensuring software integrity and compliance.

[music] >> Hey, so um little bit late, but I think we can start now. Can everyone hear me? Yes, that's perfect. Uh strange situation, somehow reminding me of uh COVID times. I just a webinar, you speak to somebody, um at least in the room, that's good. Um but uh usually I'm used to shout, but I think it's uh better to do the opposite in this case. Um

so I'm try I'll try not to speak up too much. First of all, thanks everyone for coming. Um it's a great honor to be here, first time on such a great conference, so many um nice people, people I've seen uh on other occasions before, new faces. Um so I'm a little bit excited, um but um it's always great fun to confuse, especially non-lawyers with legal stuff, and

that's what I'm going to do this time. Um at least I'm trying to, but uh best thing would be I fail and you're not confused, but we'll see whether this will happen. so my name is Hendrik Schüttler. I'm working as a lawyer, partner uh at Osborne Clarke in uh uh Osborne Clarke's Munich office in Germany. Um I've been what I usually say a software developer in my

recent life, so to speak. Recent life means 25 years um before. Um so when I started programming, uh it was the so FidoNet. Anyone knows FidoNet? Wow, okay. Mausnet? No one, okay. That was like the German equivalent to FidoNet. Uh we had some gateways to the internet, where you could send emails not just Germany-wide, but worldwide. That was really um in 1992, I mean. So anyway, um

then I studied law, and uh some of my colleagues went the other way and said, "Okay, we're going to start uh doing um an IT business. I said okay, let's just do it the other way and do IT law while at that time no one knew what it was. Um now I think uh it's rather a question what special section of IT law do we cover? So,

back to the SBOM chaos, um which we are about to tame this time. What is it all about? Um I'm trying to give you a overview on where you might need a software bill of materials, for what purpose you might need it, and how you can achieve um or how you can avoid redundancies, how you can achieve um an efficient approach in order to avoid doing the

same things twice or three times. Cuz there are some urban myths still um wobbling around. There are some misunderstandings uh that I see in my um daily practice every now and then. Um which uh one can avoid if done properly in advance, saves lots of time and money. this is what it's all about. We will start with the question, what is an SBOM? Um we will start

um with uh the main three legal um reasonings behind it. Um there are of course lots of technical implications coming with a software bill of materials. Um we'd rather focus on the legal side then. Um and dive a little deeper into um regulatory compliance, um which actually adds uh on to the um presentation you may have seen uh earlier today here in this forum. Um So, it's

not about the CRA in general, but the very specific questions, what kind of um SBOM is required under CRA and how can you combine it with other um components or other other targets. Recently, you've seen SBOMs uh even in the news. Um you may have heard of these two hacks, trivia and Axios, both being compromised. kind of well concerning hack because it affects the supply chain and

it raised again the question or once more the question, do we need SBOMs? For what purpose do we need an SBOM? Um so that's the practical idea behind it and then come the lawyers with a theory and all these legal obligations that you have to comply with. Um but at least motivation I think should be clear now. Um without an SBOM, you're literally blind with regard to

your software and your software stack. So, what is an SBOM? Um there are many different understandings of SBOMs and I think we can agree on at least a minimum set. generally it's security compliance artifact. Well, can be understood as such a Can be the foundation for license compliance. So, from the legal perspective when it comes to the licenses obligations. And of course can very well serve as

a instrument or as a tool for general transparency the moment you deal with larger customers, they will for surely require um such such a document. at least I think we can agree that's a machine readable document inventory of the software components and their relationships to each other. Um what's usually in there and we will take a closer look of course in the next few minutes. Um the

component names, version numbers of licenses license identifiers if any, hashes, dependency relationships and so forth. Um so it can help of course with vulnerability tracking. You know what kind of CVEs you have to cover. It helps with regulatory compliance here, right? But also, um, with license compliance. So, um, when it comes to the question, what kind of uh, documents do you have to provide from a license

compliance side? Um, and S-BOM can also be of of help. however, the S-BOM as such is not the compliance artifact itself. That should uh, regarded separately or it's just a different issue. The one thing is, you know what's in your software, you know what kind of components you use. The other thing is, what do you do with that information? Um, and with regard to license compliance, you

have to provide specific information. We'll go deeper into detail, quite soon. From a legal perspective, we see mainly three different roles. maybe we start with number two because that's the one most people have in mind, a license compliance. So, whenever you distribute open source software components, with 99% of the licenses, you have to provide the license text in full. Um, if you don't, especially under the stricter

copyleft licenses such as the GPL, V2, V3, LGPL, and so forth, lose your usage and distribution rights. Um, so if you don't comply with those you're in trouble. That's what many um, of um, our clients didn't know like 10 years ago. I think it changed for better now, but many companies still think, "Okay, um, I've scanned it. I know what's GPL in it. I checked for copyleft,

so we don't have any copyleft applicable. We're on the safe side." No, you're not because you're not providing any license text. You're just risking uh, that your license your distribution rights, your usage rights will be terminated. in any case, you do have to provide the full license text. It's not sufficient to provide a link. That's what we see in we'll come into detail uh go into detail

with that regard as well. But then, in many cases, the pre-contractual disclosure is uh not being taken care of properly. One thing is to do what the license says. And the license says, you have to provide the text when distributing the software. Civil law says, you have to inform your customers about what's actually being agreed on. So, if you just provide software under the terms of your

end-user license agreement under your general terms and conditions, and you don't mention that there's any open source in it, and you don't mention what kind of licenses do apply, you are um in trouble again with regard to selling um a legally defective product, so to Um I'll also elaborate further on that um in the following slides. Then finally, [clears throat] number three, regulatory compliance. That's where the

CRA comes in, where NTIA comes in, what we referred earlier today. Um that's something where you need to provide And if you do it uh in a smart way, you can um avoid lots of double work. You can avoid lots of um redundancy, or worst case, you will have to do things again that you just did uh only with a slightly different scope, causing twice the effort.

what's uh about the pre-contractual disclosure? What does it mean, and um why is it important? Usually, if you provide software um free basis in terms of offering a download on GitHub um without any contractual uh ties, no at least paywall, uh no register um no register registration um requirement, um you can do so, and you can provide the license text, and everything's fine because the moment uh

the software is downloaded usually the agreement is concluded. but there's one different situation. Whenever you provide license Excuse me, whenever you provide software for fee. You sell your software product, you sell a service, you conclude an agreement with your customer. In that case, the customer has to have the opportunity to get a copy of the license. at least to take a look at the license um in

order for this license to be part of the whole agreement. And many companies uh don't do anything with that regard. So, what we see very often is that companies do have a compliant artifact document, they do have all the licenses, they have um um uh properly set up lists of licenses, the license texts. It's all curated, it took lots of time, but then they simply don't care

for making this part of the And what happens in that case? you sell software under conditions that you cannot fulfill. So, let's take the automotive part, you sell a car, you say, "Okay, here's your car. Um you're standard dealer, you have your terms and conditions, you sell the car subject to these terms and conditions, and they don't mention a single word about software because you're selling cars,

you're not selling software. So, you may talk about um any kind of fees, you may talk about about financing, you may talk about whatever kind of um information uh you want to have in these terms and conditions, but usually you don't think of software. I mean, you're selling cars. Yeah. However, there's this tiny little piece of software in your car called Linux operating system, surprise, um which

is licensed under GPLv2. you just sold the car plus the software, under standard terms and conditions. So, your customers come. They open the product in terms of opening the door of the car. And suddenly seeing some kind of entry on the menu on the display, legal stuff, licenses, third-party licenses. And they start scrolling and say, "Okay, um never heard of that before. I've been sold a car

without any kind of third-party terms to apply. I don't want to provide license text when I sell this car. I just want to sell the car on to someone else. So, by the way, we never agreed on that. You just sold me the car. You didn't tell anything about GPLV2 and providing license text and copyright notices, warranty disclaimer, whatever. Now, please, um get me the user rights

to that software without any restrictions in terms of license text provision, patent uh clauses, uh DRM provisions, whatever. And as the dealer, you can only say, "Oops, uh sorry, I didn't mention that. Um by the way, there's open source in it." Um so, that's what the lawyers call uh defect of title. You simply provide a legally defect product in terms of it's not that it's not driving,

it's not that the motor's not working, it's simply that there's a there's an issue with IP rights, with user rights. Um and all because you simply forgot about uh the provision of the license this is something um that you have to take care of. When you sell your products, you have to make sure that the terms become part of the sad thing is, if you follow the

playbook that's written in the licenses, you provide the license text together with your software, it's too late. That does not help you in terms of ensuring introduction of these terms into the specific agreement, it simply helps you with complying with the license requirements. They could also say, well, you have to on a billboard screen or you have to put it on the internet or you have to

sing it loud loud whenever you sell 10,000 copies of your product. Anyone knows the chicken dance license? No? Okay. that's the kind of license where with every I think like 10,000 copies of the product C-level management has to perform perform the chicken dance. In German it's Ententanz, the most silly song ever been created in the '80s making you happy that '80s are long gone. Um, and it

has to be put on the internet um, just for fun. So, um also a solution, but it does not have anything to do with proper introduction of these terms into the agreement. what do you do? Um you simply ensure that prior to conclusion of the agreement, your customers have the chance to take a look at the document. To take a look at the compliance artifact that you

provide which has to contain all the license Um, you don't have to provide it physically. Um, at least depending on what your local law says from a civil law perspective, but in Germany I think uh, like only um, 40 years after the invention of the internet, German courts decided yes, um, it's okay if you link uh, internet. Um, so it should probably be fine if you have

a landing page for your products just mentioning the products and then if you go down by uh product ID, whatever, however you you um, classify your plus specific software tag, then you should be led to the very specific terms um, of this product. the last point here, you have to ensure that you have a right to introduce changes. Why is that? I mean, um you probably know

that software may um come up with some uh vulnerabilities, uh flaws, bugs, any kind of issues that you have to patch and fix. So, there will be updates at some point in time. And if these updates lead to new contractual terms to be introduced, you have to take care that these terms can be introduced into your agreement. so, that's something which is from a legal perspective I'd

say to a certain extent a grayish area where you say, "Okay, I have to provide for the right to change the agreement in terms of I can introduce new licenses. I can introduce uh new software terms in case I have to." you provide an update of one um library that you replace maybe um with another library which comes with different terms simply because you have to for

security reasons. Um in that case, you have to ensure that you have the right to change the terms you just agreed with your customers. Not that easy, but uh I would say from a legal perspective not impossible. and then of course, once more, you have to ensure that your customers have the possibility to get hold of these terms prior to installation of the update. And that can

be uh um more difficult Um I mean, usually you think of your desktop computer and you install some software and you see this uh click-wrap agreement, yes, I agree to the new terms. Um but if you have yeah, over-the-air updates, if you have devices without any display, um it may be difficult to inform the clients or the customers that now with the installation of an first of

all, that that not it isn't installed at all. Um I mean, that's by the way required by the CIA, but that's a different story. Um second, um what terms come with it? And third, that you somehow agree to it or at least are made aware of it. but in any case should, if you want set up a such a process consider all channels where you distribute software

um in all kinds of ways. I mean, we've seen it all in our legal practice, uh firmware updates provided via download just as a binary. Um suddenly license texts were missing, or they were even contained in the binary, but only if you have the proper hardware. We had cases where clients of us distributed hardware with a firmware update provided as a binary on the internet. The binary

only ran on that our most favorite customer, um you may know him, uh Linux kernel developer, I won't say his name right now, you can ask me afterwards. He sued the company um for non-compliance. Um company said, "Well, but it's on the code." And with good reason, uh the attorney on the other side said, "Yes, but you can't see it if you don't own the hardware." Now,

you may ask yourself, why would I download a firmware update for a hardware that I don't own? But unfortunately, legals don't think that way. Lawyers simply say, "Okay, you're distributing software, you're not complying with the terms, so you have a case." Um anyway so that has to be taken care of um if you think of pre-contractual disclosure. So, simply make sure that the terms of are introduced,

are part of uh your agreement that you conclude with That's the one part. With that regard, uh as I said, it's for instance sufficient to link to a website, a landing page that contains all the documentation, all the um license texts and you're fine from a civil law perspective. And then come again the lawyers and say, they have the licenses. And the licenses say you do have

to provide the license text with the software. Linking is not sufficient. We even have case law in Germany on that. So, um it's not sufficient to say, "Well, but I got everything on the internet. You can just click that link and then you have all the texts." No, the texts do have to be together with the software. Like you have to be able to read it in

flight mode. That's what I usually say it comes to analogy uh analogies, um you have a product, it's not connected to the internet, but you have a chance to see the license text. Then it's to deliver together with the software. If you don't do it, once more, as I said earlier, um that's breach of licenses, which can lead uh and does lead, for instance, in case of

the GPL, to um termination of user rights and Coming from the other side, if you do that, it's fine, because you comply with the licenses, but this does not ensure incorporation into the agreement. So, you have to do both, actually. You have to provide it before conclusion of the agreement, and then you have to deliver it together with the software in case of distribution of the software.

Otherwise, um you either have the problem with the defect of title, or you have the problem with um breach of of license. In addition, um obligations go further than just mentioning the license text. You may have to provide copyright notices, for instance. Um you may have to provide the warranty disclaimer, the already very famous written offer in terms of uh GPL compliance uh with regard to the

source code, which, by the way, is not always sufficient, um but that's a different story. So, there are some cases, GPLv3, where you do have to provide a download possibility, written offer is not sufficient, even though >> [clears throat] >> some of the organizations say differently. But unfortunately, it's written in the license. It's a clear case, and if you just take a lawyer who's never heard of

anything with regard to open source, but takes a look at the license, the lawyer will say, or the judge, worst case, will that's where it's written. You have to provide a written offer. Excuse me, you have to provide a download possibility. Written offer not sufficient. But in any just ensure that you comply with these obligations as well, and this can be done by using for instance an

SBOM as a basis document from which you derive the compliance artifacts. I mean, technically, you would store it in a database. You will have your tooling where all this information is stored in a database, but the idea behind it is you have a curated list of components, you have a curated list of licenses attached or assigned to these components, and altogether they provide the information you need

in create these compliance artifacts. Yeah, you should do so in a structured form. SPDX is one solution, but it doesn't cover all the aspects, and I don't want to go too much into detail with that regard here, but the idea behind this you have a machine-readable document, which is then converted into a human-readable document. Again, it is a technical document, yes, and no one reads it. I

mean, it's like with all these small script legal texts, no one reads it, but if someone would want to read it, that person should be able to do so. So, you should spend at least some effort in making it possible. And that's I mean, we are not discussing on that level yet, but I'm frankly speaking just waiting for courts to say, well, you can't just provide a

scroll-through list of 500,000 lines of license text without any index, without navigation possibility, where you're simply lost." And that's what you can see here. Many smartphones still use such a solution. Here you just go file-wise through the whole software stack and say, "Okay, those are the files that are licensed under a specific license." You In general, you do have two possibilities. Either you go file-wise, what you

can see here, or you go component-wise, that's what you can see That's a earlier version of LibreOffice. In any case, that's how it's done in that case. You list the components, you link with an internal link, not external, because you know distribution of license text have to take place, but you have an internal link to the Apache in for this case in this case here. Which means

you just have the license text once, and you refer from various packages into that license text. Lots of work from compliance perspective, but keeps the text smaller. Whereas this option here gives you all the flexibility from the tooling side. You just um um put in a huge text blob of all the licenses, and then assigned um with respective links. Um Either way is legally fine, as long

as it's possible for a layperson to get hold of the license text. So, that's something you should do in order to ensure that you um, comply with the license requirements as such. we have the pre-contractual disclosure, which means the license becomes part of the We have the license compliance, which says, "Okay, you simply have to do what's written in the license." >> [snorts] >> I mean, technically,

it was probably the same intention, provide the text together with the software in terms of make sure that it applies. But legally, it's too late. Uh, so you do have to deal with this, uh, well, dual approach, so to speak. You have to provide the text, um, before conclusion and then afterwards, plus afterwards in a specific format, linking not sufficient, and so forth. Both can be backed

by proper S-BOM management, um, and you will now see, um, why it makes sense to combine, uh, these steps together with the regulatory compliance efforts, um, especially with regard to the CRA. so what does, um, or what kind of framework do we have? First of all, we have the, uh, Cyber Resilience Act, uh, came into force in 2024. Um, full application, um, December next year. We have

some, um, guidelines from, at least in Germany, from the, um, Federal Security, um, organization, Bundesamt für Sicherheit in der Informationstechnik. Um, plus we have, uh, US, um, stipulations that actually came up earlier. Um, SolarWinds was, uh, the, the hashtag to be added to that, uh, law, uh, some hack, uh, back in 2019, um, when the idea of S-BOMs as a legally mandatory instrument came up, actually. So,

the CRA, what does it say? Um you've heard it earlier today, uh so I won't bore you too long uh with that regard. Um it says that you have to identify and document vulnerabilities of components contained in products with digital elements. In non-legalese, anything that is connected with the and that software that you distribute, has to be safe from a technical includes drawing up a software bill

of materials in a commonly used and machine-readable format, covering at minimum the top-level dependencies of the products. That's what the law says. Um so, actually everything that you put on the market that contains software and is connected to the to the internet, um has to comply with that um regulation. With with with that act. Um minimum level of top-level dependencies. Even though the BSI says now you

have to go through the whole software stack, and that's where already the combination of license compliance and CRA compliance comes into play. License-wise, it doesn't make any difference on what kind of level your component is hidden in your software So, whenever we see um a software bill of material by a client, by a client's customer, stating I'm selling Linux in terms of I'm providing Linux as part

of my products, license um GPL, we say, "Okay, um I you mean the very kernel?" Yes, it's GPLv2 licensed, but even if you download the software package from kernel.org and scan it with a standard tool, you will find uh about 90 additional licenses, not all of them being applicable, some relating to documentation, some relating to whatever kind of test kits, um to um reference implementations, but at

least there will be some more licenses. So, you just scanned on the very highest level, that's not sufficient. So, from a legal perspective, you simply have to provide all license text for all components, no matter if they are hidden in some container, no matter if they are hidden in some piece of firmware. Um if it's respectively licensed software and you distribute it, you have to comply with

the terms. So, already with that regard, it definitely makes sense not to just check the highest level, but to go into detail recursively throughout uh the whole um just in case you wondered whether you may just start with the first level. And of course, security-wise, the same. I mean, uh doesn't make any difference uh where you have your CVE hidden in the software, um whether it's first

level or second level. Um if if it's there, if you can hack it, you can hack it. Um and hackers, uh at least I'm not aware of any ethical code for hackers not to attack uh components uh in uh second level or below. Um so, probably um there's no security coming with uh scanning on first level. software bill of materials uh under the CA does not require

any public disclosure. That's your internal document, but of course, um in the supply chain, it goes up and down. So, the moment you purchase any kind of third-party components, um these components um will come or will have to come with an SBOM um because you have to have it internally um in in in any case as well. So, it doesn't help um to say, "Well, I don't

have to disclose it anyway." The moment you distribute software, the moment you have customers um that receive software, um there's a big likelihood that they will ask for SBOM in the future. And once more, CRA is not license compliance. If you comply with CRA, you're not compliant from a open source legal licensing perspective in terms of did I provide the license text? If you provide an SBOM,

and the SBOM does not have to contain the license text in full, um, you're not in compliance from, uh, the license compliance point of view. So, there's these three aspects all come with different obligations. However, if you do it in one row, you save a lot of with regard to timing, I would not go into detail, um, here. Um, so now we're at the point where the,

um, CRA is, uh, um, became into force, uh, came into force. Um, the conformity assessment bodies, the respective framework, um, when it comes to certification should apply with the, um, with mid-June. However, there are no, um, conformity assessment bodies yet. So, what you do, you will have to get, uh, an assessment by a third party, but you can't because there is no third party able to give

you that assessment. Um, you'll have to wait, but, um, recommendation is to be prepared anyway. Doesn't make any sense to wait, um, in not in all cases you need an external assessment. Self-certification is in most cases, uh, sufficient. Um, you simply should make sure, um, that you do comply with these obligations in general. what's required under the BSI, um, um, uh, guidelines, um, with regard to an

SBOM, you have to provide, uh, information on the creator of the SBOM. You have have provide the timestamp. Um, that's something that should be doable. Um, Um, and then it goes down per component, um, component creator, component name, version. Um, also things that you don't uh, need for um, license compliance purposes. You have to under for license compliance, you simply have to assign the license text to

the component. Um, plus maybe the copyright notices, but that's it. Dependency relationships, um, SPDX license expression, hash of executable. Um, that's all information that you have to um, provide together with the component. Um, and then there are some recommended fields, um, the SBOM UI, um, URI of the executable form. If any, I mean, thinking in terms of open source software, in most cases you may find uh,

an URI of the executable, not in all cases. Sometimes it's source only. Sometimes, of course, when it comes to interpreter languages, PHP, JavaScript, whatever, um, there won't be any uh, executables at all. Um, and uh, yeah, as I said, it's not a mandatory anyway. Um, formats, uh, we also heard it today, CycloneDX or SPDX in specific versions. And um, yeah, recursive on every dependency path, um, at

least to the first component outside the delivery scope, which means actually full scan. At least that's my interpretation. And once more, it's necessary anyway from a general compliance perspective. Um, then we have the executive order, which has actually been revoked. Um, still I wanted to let you know or some obligations of it have been Um, the executive order came earlier than the uh, CRA said, "Okay, you

have to provide more or less the same information." yeah, some uh, information about supplier, component name, version, author, and so forth. Um, though in slightly different formats, SWID also a um, format sufficient under the um NTIA executive order, whereas it's not sufficient for the CIRA. So, better then try to agree on one format that works for all processes. Um it's been a set rescinded in January this

year, 20th of January. Some political background probably. Um however, from a legal perspective, you're not required anymore to attain self-attestations. Um as a federal agency, but different story, US law. Um just wanted to let you know um they step back whereas EU steps forward. In any case, better ensure compliance with both sets, even though they're not 100% matching. Here you see a table of the obligations. Where

it's required, where maybe some information is only recommended. Um and here you can see that the license is not required under the NTIA stipulations, where it it is under the BSI recommendations. Um plus some some other information. what are the key takeaways? Um maybe looking into your faces, I kind of achieved my goal in order to confuse you. Um but hopefully at least some clarity remains. First

of all, there is not the SBOM. different SBOMs depending on what purpose you pursue. You should know what has to come into your SBOM that you have to build. Think of license compliance in the same way. the license terms have to be part of the contractual agreements. You have to scan your software for licenses. You have to make sure that these texts are available before the contract

is concluded. Otherwise, you simply risk a legal defect in terms of you're subject to damage claims. Uh maybe your customers may revoke the agreement. Um that can happen if you don't uh comply with um these And then CRA compliance is not the same as license compliance, two different um goals behind it. if you have an S-bomb, complying with the um CRA, it doesn't necessarily mean you have

all the information you need NTIA then finally is not same as CRA. There are some different license uh fields or there are some different data fields um that you would be expected to provide. and uh this makes it necessary to take a close look of what you need and uh ensure that you have both of it. Um CRA reporting uh obligations apply um and apply quite soon.

So, um if you didn't start yet, uh you should do so. Um otherwise it may be a close run. and once more, please don't run separate processes, at least if you can manage in your company to um unify this, you should do so. Um you should make sure when caring about CRA um you do in the same instance care about license compliance or the other way around.

If you have already processes for license compliance, just put the CRA on top. Um and you you will pretty um sure and save uh save time and effort. So, maybe three questions you could ask yourself. Um is the license information incorporated in your uh into your contract? Is it ensured that uh all the information becomes part of the contractual relationship? If no, you should take care of

that, including update mechanisms in terms of caring for software updates, patches. do you fulfill the license obligations of every single component, not just top level, but every single component contained? If you don't, once more, um ensure that you do. Attribution notices, um source code, disclaimers, and so forth. And of course, finally, um are you ready for the CRA with regard to the S-bomb? So, keep that in

mind when you set up the processes accordingly. So, with that regard, we do have 4 minutes and 5 seconds left. Thanks for listening. Um thanks for being here, actually, and of course, I'm very happy to take questions. Thank you. >> [applause] >> I think we need a Hello. Uh question about saying that being compliant with BSI recommendation makes you CRA ready. Isn't that a bit of a

shortcut? Cuz there's a lot of potential problems in the BSI recommendations. I mean, sure, ensuring that you comply with BSI um is kind of a shortcut, but it's only half of the story. Um you still have to ensure that license compliance is achieved. Um that does not come from a regulatory perspective, but from the legal perspective, so to speak. this comes with different requirements. Okay. Um I

have more question to the license compliance uh topic. Um when you build something like an open source library, okay, you put your whatever license in there, and it's just library with no as in nothing else packed in there. That's clear. But when you do something like a a full product, like a a Docker image with a lot of software and stuff in it, where do I put

my licenses there? Because I can put it in my readme.md, I can put it on my Docker Hub page, but I have to deliver it with my software. Is there any best practice how to do this? Um, well, in the old days, I would have said, uh, you have a zip wrapper and then you put the S-BOM information on top of the binary or whatever it is.

Of course, it doesn't work with Docker files. So, I mean, best or as close as as you can get to full compliance would be, first of all, ensure it's in the Docker file. Ensure that it's in the Docker file, accessible with, um, on-board means in terms of plain text file that you simply can access somewhere located in, yeah, readme at, uh, root location. Um, and then, of

course, also put it on wherever you publish the Docker container, uh, in terms of some web, uh, sites for, uh, separate download. So, basically, a readme.md in the root with all the licenses in there and what component uses which license. For instance, yes. Uh, basically, for but for everything in the Docker container, not only my part. Exactly. Okay, that's >> That's why I love, uh, distributing compose

files, but not Docker images. Um, you just provide the installation information, so to speak, um, and not the, uh, complete software. The moment you distribute software, you have to comply with the terms. If you just provide a build script downloading all the sources from somewhere else, um, you don't have to comply with the software you're not distributing in that case. Okay, thanks. Here, I have two questions,

actually. One question is for the verification of this all these checksums down to the source code, uh, basically, get commit ID. And the second question is, um, how does patching source code, uh, how does how does these patches need to end up in their spam. Um, long story. Um, so first of all, everything that's in the source code has to be covered by licenses respectively. Um, patches

uh usually just become part of the whole software and thus subject to the very license applicable in that case. Um, we can discuss for the next 2 hours about the question in what case um the patch is complex enough to um achieve copyright protection or where it's just two bytes that you flip in order to make it I think time-wise, we have nine more seconds and before

I'm thrown out here coming from Munich and where you've ever been to the Oktoberfest, you know that there are strict time slots. You don't mess with security. As I'm not uh acquainted with uh um Belgian security politics, I'd say we can continue the discussion outside. Very happy to take any more questions. Um, in any case, thanks for being here. Thanks for discussing uh showing your interest and

it's been a pleasure.