EU cybersecurity regulation and Open Source governance
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 43 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/67124 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FOSS Backstage 202423 / 43
8
11
00:00
MenütechnikMereologieFormation <Mathematik>BitProzess <Informatik>MultiplikationsoperatorOpen SourceVerkehrsinformationSoftwareVollständiger VerbandSoftwareentwicklerComputeranimationVorlesung/Konferenz
00:52
SoftwareRechter WinkelSchlüsselverwaltungOpen SourceSoftwareentwicklerSpannweite <Stochastik>UML
01:33
Open SourceRegulator <Mathematik>Produkt <Mathematik>Projektive EbeneComputersicherheitAuthentifikationMinkowski-MetrikSystemidentifikationKartesische KoordinatenDigitalisierungAusnahmebehandlungGemeinsamer SpeicherMAPHardwareMultiplikationsoperatorMereologieCybersexSoftwareArithmetisches MittelFlächeninhaltSchaltnetzRichtungBitProzess <Informatik>QuellcodeOffene MengeImplementierungStandardabweichungDienst <Informatik>Basis <Mathematik>IdentitätsverwaltungComputeranimation
04:32
SoundverarbeitungCybersexComputersicherheitProdukt <Mathematik>DigitalsignalHardwareSoftwareOperations ResearchEntscheidungstheorieMAPSystemprogrammierungBrowserKlasse <Mathematik>PasswortPlastikkarteStandardabweichungBefehlsprozessorRouterRechnernetzKonfigurationsraumDefaultAutorisierungBenutzerbeteiligungCybersexComputersicherheitPasswortSoftwareProdukt <Mathematik>SoftwareschwachstelleStandardabweichungRegulator <Mathematik>ProgrammierumgebungKartesische KoordinatenSchlussregelGesetz <Physik>VektorpotenzialDigitalisierungGüte der AnpassungKlasse <Mathematik>Stochastische AbhängigkeitSoundverarbeitungBefehlsprozessorComputerspielProjektive EbeneDreiecksfreier GraphOpen SourceDefaultEntscheidungstheorieGruppenoperationDifferentialSoftwareentwicklerVersionsverwaltungKernel <Informatik>HardwareApp <Programm>KonfigurationsraumNichtlinearer OperatorInstallation <Informatik>FlächeninhaltPhysikalisches SystemSelbst organisierendes SystemEinfügungsdämpfungMAPDADSBrowserDatenverwaltungExploitComputeranimation
10:48
Produkt <Mathematik>KonfigurationsraumDefaultComputersicherheitAutorisierungGruppoidSchlussregelCybersexAggregatzustandUmwandlungsenthalpieDatenfeldMarket Access <Datenbank>SoftwareNichtlinearer OperatorOpen SourceKomponente <Software>Element <Gruppentheorie>DigitalsignalBasis <Mathematik>Spannweite <Stochastik>Open SourceMaschinenschreibenCybersexSoftwareentwicklerSoftwareMailing-ListeProdukt <Mathematik>Kartesische KoordinatenDifferenteComputersicherheitTermGesetz <Physik>Selbst organisierendes SystemMereologieDatenfeldAggregatzustandAdditionBitInverser LimesFreewareProzess <Informatik>Projektive EbeneExogene VariableZusammenhängender GraphProgrammierungDifferentialSpannweite <Stochastik>MaßerweiterungPlastikkarteArithmetisches MittelResultanteDigitalisierungUmwandlungsenthalpieRegulator <Mathematik>SchlussregelBasis <Mathematik>PunktGrenzschichtablösungSummenregelRandwertOffene MengeZweiElement <Gruppentheorie>Metropolitan area networkComputeranimation
17:03
Element <Gruppentheorie>DigitalsignalProdukt <Mathematik>Basis <Mathematik>SoftwareOpen SourceSpannweite <Stochastik>Open SourceProjektive EbeneDreiecksfreier GraphProzess <Informatik>ComputerspielGruppenoperationMultiplikationsoperatorWeb SiteBitRechenschieberOffene MengeComputeranimation
17:45
Natürliche ZahlOpen SourceRechter WinkelEinfache GenauigkeitGrenzschichtablösungProjektive EbenePunktMultiplikationsoperatorGesetz <Physik>GruppenoperationDigitalisierungSelbst organisierendes SystemAssoziativgesetzTopologieZusammenhängender GraphSoftwareentwicklerPunktspektrumSichtenkonzeptOffene MengeVorlesung/Konferenz
22:19
SoftwareentwicklerTermSoftwarewartungOpen SourceVektorrechnungGruppenoperationCMM <Software Engineering>SoftwareFrequenzFunktion <Mathematik>ComputersicherheitProdukt <Mathematik>SoftwareschwachstelleProzess <Informatik>VerkehrsinformationImplementierungStandardabweichungProjektive EbeneOpen SourceCybersexFrequenzMultiplikationsoperatorSoftwareentwicklerMAPBitProdukt <Mathematik>Exogene VariableSoftwareTopologieComputersicherheitComputerspielVerkehrsinformationProgrammfehlerService providerSoftwareschwachstelleFunktionalDreiecksfreier GraphProzess <Informatik>SoftwarewartungTermMaßerweiterungComputeranimation
26:49
Produkt <Mathematik>SoftwareOpen SourceImplementierungSoftwareschwachstelleVerkehrsinformationStandardabweichungFormale GrammatikComputerspielOpen SourceTermRechenschieberProjektive EbeneKette <Mathematik>NormalvektorCASE <Informatik>Gesetz <Physik>Formation <Mathematik>MathematikOffice-PaketSoftwareProdukt <Mathematik>KoalitionElektronisches ForumComputersicherheitGüte der AnpassungMAPProzess <Informatik>BildschirmmaskeFlächeninhaltBefehl <Informatik>Rechter WinkelGeradeFunktionalData MiningErwartungswertVorzeichen <Mathematik>CybersexNatürliche ZahlMultiplikationsoperatorSelbst organisierendes SystemBitPunktwolkeMessage-PassingVorlesung/KonferenzBesprechung/Interview
Transkript: Englisch(automatisch erzeugt)
00:08
Thank you for joining. I'm Oker Boerma with the Linux Foundation. I do community development at Linux Foundation Europe. And as part of that, I spent a lot of time in Brussels, as you can imagine, talking to or engaging with policymakers
00:25
who are starting or in the process of making software a regulated industry. And that's a promising thought on one side, but also a bit scary. So, today's talk will be a little bit of a report from what we're doing there.
00:43
And a collection of insights kind of projecting into the open source community how we have to adapt to that. So, before we go in, well, why is the EU generally interested in regulating software in general,
01:01
including that and open source software? It's because it has a huge impact. It has a regular impact on the EU economy in the range of 65 to 95 billion euro per year. And that is, of course, something that is significant. And it also has a lot of promise in encouraging further growth
01:22
and the development of key industries in Europe. And therefore, naturally, there is a lot of interest. And how does this interest manifest itself? Well, in many, this is like an acronym soup of upcoming legislations.
01:41
We have the Cyber Resilience Act. I'm going to talk a little bit about that today. As a regulation that focuses primarily on cyber security, we have the Product Liability Directive, which now starts to cover everything that is a digital product, meaning hardware, software, combinations of both.
02:03
But we also have other areas where the impacts are sometimes really difficult to discern. For example, the regulation on standard essential patents comes with a transparency register that patent holders are supposed to use to declare the essentiality of patents for certain applications.
02:26
And that's one of the key questions. One of the key questions here is then does that influence the open source community or not? We're assuming that improved transparency here actually makes things better for everybody, including the open source community.
02:40
But it's essentially an ongoing controversy. We have the AI Act, where you have a little bit of overlap or a little bit of impact on the open source community. With the mentioning of foundational models, which could mean a lot. Many of these foundational models are developed in open source projects or at foundations.
03:02
But here, for example, one difficulty is that we don't really have a definition of what open source in AI is. It's like what is an open AI or there is no open source definition as we have a software source code for AI applications. There's upcoming regulation on data or European identity and digital identification,
03:26
authentication and trust services regulation. And all of that impacts the space of digital products significantly. And one thing that we say today is you can't regulate the ICT sector
03:43
without impacting the open source ecosystem. The open source ecosystem has become an integral part of the digital economy. And therefore, that's one mistake, I think, that our regulators made in the early stages is to think that it can basically be technology neutral
04:02
and not touch open source except like with a careful exception of non-commercial activities. I don't think this is going to work because, as you know, all of our communities are not just working on like a voluntary basis and contributing in their spare time.
04:22
A large share of our projects are contributed to primarily by people doing this in their day job. And therefore, they're part of industry. So, that was just mostly an overview. You may have seen this book. There's an understanding, especially since GDPR kind of impacted the whole world.
04:43
In a slightly unexpected way, that if you regulate the internal market in the European Union by saying if you want to offer something here, no matter where you are, where you're from, and where your business sits, then you have to basically work according to the rules set here.
05:02
If you do that, you regulate the whole world. And that's what we've seen with GDPR. And this is an excellent book that explains all of this and much more. For example, that if you have a progressive and a forceful regulator somewhere in the world,
05:21
others will kind of follow their lead. Why? Because it's easier for most manufacturers to work according to the toughest rules and then sell their products everywhere. And this impactful and forceful regulator is the European Union right now. And now we're getting to the Cyber Resilience Act,
05:44
which is drafted with this intent to play an internationally leading role. So, that's new. Until now, the Brussels effect was kind of either accidental or hoped for, but maybe a side effect.
06:02
Here, the law says we intend to play an internationally leading role. We intend to export this regulation. We intend to affect the whole world with what we're writing in the Cyber Resilience Act. So, what does it say? It has three policy goals. Reduce the vulnerabilities in digital products.
06:20
I think we can all sign up for that. Ensure that cyber security is maintained throughout the product's life cycle. Very good. And, of course, to inform users, to enable users to make informed decisions when they select products and operate them. It's a horizontal regulation. That means it applies to everybody who wants to be active commercially in the European internal market.
06:45
And it covers all digital products, software or hardware. And it intends to be objective oriented and technology neutral. So, a law that has high-level policy goals with regards to improving cyber security is written in a way that it's horizontal, that it covers the whole European market
07:02
and everybody who offers something there, and intended to be exported. For that, it basically says we're classifying digital products in three key groups. All of them should be developed according to essential cyber security requirements.
07:21
And they're laid out in the law. It says design with security in mind, apply secure by default, configurations and things like that. All smart things. And, yeah, so what falls under this class? Basically, you're in the all group if you're not one of the important or critical that I'm getting to in a minute.
07:42
So, all our projects at Linux Foundation are in this group. All digital consumer devices, because they all include software somehow, and all software that is installed on consumer devices. So, even if you're just a software vendor and somebody downloads your app and installs it,
08:00
it's also covered. That's also covered by that. And then, so that's kind of the baseline. And then you get to important products. Important products should have their compliance with the cyber security requirements assessed against harmonized standards. Very interesting. Or if those standards don't exist or it can't be done like that,
08:21
then through an independent audit by a third party. The products that fall into this group are, for example, web browsers, password managers, CPUs with a trusted execution environment. So, products that have a potential of security vulnerabilities kind of sprawling from there into other areas,
08:42
like consumer applications from the CPU, et cetera. Now, a little caveat here is that these harmonized standards that are mentioned or referenced in the law, they don't exist yet. There's an outstanding request to send Senelec, one of the European recognized standards development organizations, to develop these standards which will happen in the next three years.
09:03
And that's a huge risk because we basically say, well, we know what the law says, but we don't know yet what the standards say. And if the standard doesn't fully say what we need to do, then we need an audit by a third party. And it gets more critical than that.
09:21
That's like the last class of products. Here, operating systems, network and routing software, et cetera. Here, compliance should always be ordered by a third party. There will be accredited independent assessment bodies for that. So, yeah, so that's basically, that's how the law looks at digital products.
09:42
What do you then need to do as a manufacturer? You should develop all digital products according to the essential requirements. And then the more vulnerable the consumers of digital products are, the higher up you are in this class of classification of goods and in the stricter the requirements get.
10:02
So, for example, that means products should be designed and developed in accordance with these requirements. When you ship a product, it should be shipped without known exploitable vulnerabilities. Now, here you can already see that initially there was no differentiation between an open source community releasing a new Linux kernel version
10:23
and a commercial product. And if you want to ship the Linux kernel without known exploitable vulnerabilities, you can ship it. Because there are unsolved problems in there that we are aware of. You ship all products with a secure by default configuration. Interestingly, interesting for consumers,
10:43
price should be designed so that vulnerabilities can be addressed to secure the updates. And that's protected from unauthorized access and a lot more. So, you basically find, I think, a pretty smart list of basic requirements in this text that will make products, digital products, more secure.
11:04
That's clear. There are some boundaries, like, for example, we are in the EU and this law will have to be also implemented or at least supervised in the different member states. So, there are some limitations where, for example, the member states cannot add additional cyber security requirements on top of the law
11:22
to harmonize the European market. But they may, for example, define additional rules for specific fields like medical devices and especially mentioned here are national security, defense and things like that. However, there's a strong, like, hint in the law that when regulation gets updated,
11:45
it should be harmonized with the Cyber Security Act. So, this was all just to give you an overview of what is coming. Like, to what extent does the EU go into the digital market and start to regulate it?
12:02
And now we're kind of making a shift and say, what does this mean for the open source community? So, kind of starting from that point that the open source community is not, like, fully a part of the digital industry because there is also a part of the open source community that is outside of industry. But it is a part of the industry.
12:23
We need to delineate how open source development efforts are separate from commercial development efforts. And here, the provision of open source products that are not monetized are not considered a commercial activity under the CRA.
12:40
And that's good. It basically means that if an open source community develops software in a kind of typical decentralized fashion, openly governed, and then releases that, that community does not monetize what it distributes. So, it's not considered commercial. This activity is not considered commercial and the community is not a manufacturer.
13:01
The development by nonprofit organizations is also not considered a commercial activity. And here, this was not part of the original draft. So, this is the last state after the open source community engaged with policymakers here in Brussels and explained the differences between nonprofit foundations and manufacturers.
13:23
And a very interesting clause in there is that the manufacturer that takes a piece of software from upstream and integrates it into a product to bring this product into the market commercially, that manufacturer should exercise due diligence to make sure that this open source component is viable for the application that the product is intended for.
13:44
So, the owners of responsibility for bringing a piece of open source software into the market in a commercial fashion is with the manufacturer that takes it from upstream and integrates it into the first product. And also unclear a little bit until now but promising, I think, is that the upstream foundations
14:04
and the manufacturers are supposed to work together through, for example, voluntary security attestation programs to support this process of adoption of open source components into products. So, essentially we're seeing here that there is a difference between what is commercial activity
14:22
and what is not considered commercial activity and how the software get from kind of open source upstream into manufacturers use in a commercial fashion. And this results in the biggest novelty in EU law when it comes to the digital industry, which is we now have two roles, separate roles in the law for manufacturers
14:46
and for what the EU calls open source software stewards. Manufacturers are commercial businesses. Any commercial entity that brings a product into the market, markets it, monetises it, sells it, owns the trademark, etc.
15:06
So, manufacturers have the full range of obligations of somebody who works in a market in a commercial fashion. In opposite to that you have open source software stewards which are supposed to be influenced
15:21
by a light touch regulatory regime, that's what the law says, light touch regulatory regime. It's not 100% clear what this means yet because they didn't clarify that but it's definitely a lighter touch than for manufacturers. Who is a steward? Any legal person other than the manufacturer, so not the same.
15:42
With the purpose to systematically provide support on a sustained basis for the development of specific products with digital elements, qualifying us, free and open source software that are later intended for commercial activities. So, a couple of interesting tidbits in here. This is from the text of the law. First of all, the text of the law says free and open source software.
16:03
It doesn't say open technologies, it doesn't circumscribe it, it uses the term free and open source software in the law. That's new and that's good. The second is it recognizes a certain role in the open source ecosystem which is organizations that support specific projects in being viable,
16:27
in being long-term sustainable. Basically it circumscribes the role of the neutral foundations that you also heard Don talk about earlier. So, this is new. This is new in EU law that it recognizes that the open source ecosystem
16:43
has actors that play an important economic role but are not manufacturers. And that's new. So, two roles here. But this differentiation has significant consequences for how we run open source projects.
17:05
My favorite slide of the whole talk. Allow me to spend a little bit of time on this one. Open source projects basically have a certain life cycle. They start as a great idea.
17:20
Some of you may have a side project that you have a great idea and you spend some time on hacking, releasing it. Initially you're of course the single vendor. You're the only contributor to it. And then essentially it bifurcates quite early in the process. You can either basically start to attract a group of contributors to that project
17:44
who are working with you on it in a non-commercial fashion all open. So, you and your buddies are working together and you make regular releases. It's a small component that maybe starts to see downstream views. Really great. You don't have an intention to commercialize it.
18:01
So, you're really like just an open source community. And if it then continues to grow further, at some point you get to the point where you say, well, we're receiving donations here. They're all coming to my personal bank account. I feel uncomfortable with that. So, how about we form a small non-profit organization that can have its own bank account?
18:22
And yeah, maybe many projects stay like that. They're a small registered association, hold a trademark, receive donations, and have 20 to 30 to 100 contributors. Some projects go bigger. Or the people that develop on the project say,
18:41
I would like to focus on open source contributor work and not on fundraising and managing donations. So, I would like to place this project under a foundation where they take care of all these aspects and I focus with my bodies on technical development. And that's all on the left side of the tree here.
19:01
This is all the non-commercial, open source, openly governed spectrum. And these projects can be very long-term, viable. They become very critical components sometimes. So, those can be important projects. On the right side, you would see what if the initial contributor, the initial developer says,
19:21
I want to make this a commercial idea with open source, maybe. So, you form it into a startup. You still publish it on GitHub, but using a contributor license agreement, you make sure that your company holds all the rights. We've heard all of this before in Don's talk. So, you start a commercial entity. You maybe grow with this commercial entity
19:42
to become a small, medium-sized company. Or you're super, super successful and your company becomes a unicorn. Why is this important for open source governance? Because projects change their nature over time. And that's the intention. You want to introduce the project to attract contributors
20:01
to become a community or a company to grow. And that means in the law, you play different roles depending on where you are in this tree. If you are at the bottom, individual developer working on something, the law explicitly excludes you. It says individuals are not covered by this, unless they become companies.
20:22
If you turn to the right here and you say, I'm going for a commercial path with this, then you're on the road to being a manufacturer. And this transition from being an individual developer to becoming a manufacturer is a very important one because you go from zero obligations to full obligations under the law, which means you should not take this lightly.
20:43
You should make this transition very explicit. You should publicly declare, we have started a company until yesterday, everything we did was non-commercial. Starting tomorrow, everything we do is now the work of a company. We're now a manufacturer. And then you can grow.
21:00
And similarly, if you stay on the left side and you say, my community grows, but I wanted to stay an open source community, but we will formalize governance. We will set up an organization for that, et cetera. You're turning from being an individual to becoming a steward. And stewards have obligations. Not as many as manufacturers, but no obligations.
21:23
So again, here this transition is very important. And another aspect is that because the law says a steward is somebody other than a manufacturer. You cannot be both at the same time. That means you cannot say, well, I want to be the steward for this project, but I also want to be a commercial entity.
21:43
The European Union here has a picture in mind of how the open source ecosystem integrates into the digital industry. And that picture clearly asks for separation of the non-commercial, non-profit activities, and of the commercial manufacturer activities.
22:00
This is one of the issues here that we see with some of the single vendor companies. There were some questions about this before. Because they find themselves in this middle ground, being half an open source community and half a company, and that's not a super viable project going forward, set up going forward. So just to make sure that you heard this,
22:23
individuals, hobbyists, occasional contributors, as long as their participation is non-commercial, are accepted from the Cyber-Brazilian Act. Contributing to projects that you are not responsible for, that are hosted somewhere else, is also accepted from the Cyber-Brazilian Act. However, when an individual developer becomes a manufacturer,
22:43
then you are a manufacturer. When the community grows, you may become a steward. So that was the tree that you've seen. And there's an interesting caveat here, and that is we've seen a lot of debate about businesses participating by consuming open source software,
23:05
maybe occasionally reporting a bug report back, but other than that, not engaging with the products, with the development process, sorry. And this is going to be difficult, because in a minute I will tell you about the required support periods
23:21
for any commercial product that goes into the market. And that means, as a manufacturer, remember that you are under the responsibility to apply due diligence when you integrate a piece of software. You're not just responsible for saying, is this good enough to integrate and fulfill my needs?
23:40
You're also responsible for making sure that you are able to maintain your product and cybersecurity updates to the product throughout the lifecycle of the product. And that's a long period of time. And you know what you don't have? You don't have any way to say to an open source project, you have to fix this bug for me.
24:00
There's no way that you can tell a maintainer you have to do this or I will stop using your project. Well, you can do that, but essentially what this establishes is a practical requirement for manufacturers to engage and ensure the viability of upstream projects that they consume. Now, this is already the working model of many large projects.
24:24
But now you have a legal requirement that says that these projects must be maintained as long as you ship them. And interestingly here, it feels to me like the European Union is doing the homework for the industry and the open source community
24:42
by saying, hey, if you're all relying on this, you should also properly maintain it collaboratively, right? That's what we're saying we do, but we don't always do that. Interestingly, this understanding that you're responsible for maintaining in the long term the projects that you depend on is we consider that a very mature understanding
25:04
of how you engage with the open source community as a manufacturer. Like you go from passive consumer to occasional participant to somebody who steers the project that they depend on in a strategic way. And many companies in Europe are not at this stage.
25:21
So there's a push here, a regulatory push from the top to say please grow up. And now just because before we close, we have a bit of time for questions. What is the support period that I'm talking about? You must supply vulnerability fixes for your products.
25:42
You must ship them separately from functional updates. You cannot degrade the functionality of the product through like end of life. And the support period is no less than five years. That doesn't sound so scary. But if the product can reasonably expect it to be used for longer than five years,
26:02
then your support period extends. So if you, let's say, happen to make products with wheels that are on the road for 15 years, then you will have to provide security updates for that for 15 years. Now that's this long term relationship with the upstream communities that I mentioned. All right.
26:21
There are some more things, disclosure notifications, and I will skip that so that you don't think this is a small problem. There is, of course, this comes armed with potential penalties. So please don't ignore this. You have three years as a manufacturer to implement this. And I think the best way forward would be to just do that.
26:42
I will stop here because I think there's hopefully time for a couple of questions. Please. Thank you, Merkul Poon, for the talk. So we're going to have two questions from the online forum.
27:01
One is how realistic is separating functional forms, functional form security updates? Okay, yes. You saw that on the slide. The law clearly says security updates should be provided for free because they cover, they fix functionality
27:21
that the customer has already paid for. That's the philosophy behind this. Like if there's a security flaw in the product, then you can't charge the customer for fixing it. How realistic is it that they should be separate? Well, the industry does it already in many cases. So in many cases you have,
27:41
my device needs to update because of a security update, and it's much smaller than the actual functional update. Sometimes you have end of life for software in the sense that no functionality gets added to it anymore, but the five years haven't passed. So realistic or not, I think first the industry can do it. It has already shown that it can do it.
28:01
And second, it's a requirement under the law. So I think practically we can expect that this will become the norm. One question from the audience. Hi, Merkul. Hidden here on the left. Hey, how are you? So CRA is out.
28:21
It's changed. Even putting a mainstream term now open source steward, it was enough, the changes? Good question. So I think I understand your question as are we happy with the Cyber Resilience Act? Nobody's ever happy with the law. But when the first draft came out, we were really alarmed.
28:43
Maybe for your background they didn't say that, but a whole like coalition has formed. Open source foundations, big projects, Python Software Foundation, Apache, Linux Foundation. We all got together and basically worked out recommendations to the EU,
29:00
what should be changed, et cetera. And we submitted them with one voice, which I think was really appreciated. And we did not frankly expect to have that much impact. The law was practically redrafted in the late stage, in the 11th hour, to reflect the needs of the open source community.
29:20
So on one hand I may say, well, there's still a lot of uncertainty in there. There are expectations that will be tough to fulfil. So be it. But it's the best draft that we've seen in the process. So am I happy? Say 90 percent. Is it a promising opportunity for the open source community? Yes, I think it is.
29:42
Okay. Two more questions, I think. One from the online forum and then I come back to you. Does quotes intended for commercial activities, quotes, exclude products provided to end consumers? That's a very good question because that's one of the uncertainties. So I think to reframe this, basically what happens if an open source community
30:05
releases a tool that is intended only to be used by consumers with no commercial manufacturer supply chain in between? You can think of LibreOffice, for example, where the community directly releases end user software. My understanding is that the document foundation
30:22
is an open source software steward. There's no manufacturer in this chain. But that also means, and this is kind of in line with the expectations of the open source community and users, that the software comes with less warranty. Maybe not no warranty anymore, but you can expect what you can expect
30:41
from a steward, not from a manufacturer in such a case. I think consumers, you know, well educated consumers that chose to use LibreOffice are probably aware of that. But yes, it's different. You don't have a manufacturer in this supply chain. Okay, one quick question, quick answer.
31:01
Hi, can you go back to your favorite slide? So is there anybody on the left in the blue or the cyan who's actually a manufacturer? Well, first of all, the law says other than a manufacturer. I understand, but is there anybody on the left that you think would be labelable as a manufacturer?
31:24
This is the blurry line, the gray area where you have open source projects that are partially run commercially. But are still, I mean, we're all aware of projects like that. Very friendly community, good friends of mine, are the next cloud community.
31:41
They have a single company and then a community around this. I think how this will shake out is that the activities will be more clearly separated, that there may be two entities where you say this is the community that operates on the blue side and then there's a company here that offers commercial support and all these things that these companies do to support the ecosystem
32:05
and it will be clearly on the right side. So I think yes, currently companies exist that kind of sit here. But because of this very explicit statement that says a steward is somebody other than a manufacturer, it's either or. There's no gray area in terms of what the nature of your organization is.
32:23
It's either or. And that means the best path forward I would expect, but that's a bit uncertain, is to separate the activities into clearly stewardship activities and clearly commercial activities. Alright, thank you. Time is over.
32:41
Thank you very much.