Balancing the Supply Chain Act #FOSSBack

This panel discussion focuses on balancing legal, organizational, and community perspectives in managing the open source software supply chain amid regulatory acts such as the European Supply Chain Act and Cyber Resilience Act. The speaker, Melanie Wollnik, moderates as panelists—including legal experts and open source maintainers from various organizations—explore the challenges imposed by these regulations. They discuss the unique nature of open source supply chains, characterized by a network of independent contributors, and the implications of compliance and community expectations. Key takeaways include the need for better communication, understanding of roles, and innovative models for funding and support to ensure sustainable growth in open source projects.

[music] >> Hi, welcome to our panel on balancing the supply chain act. We Yeah, we we promised you some answers to important questions. So, although we can't Yeah, solve all that problems in in the next 40 minutes. >> [laughter] >> We will bring some very interesting perspectives together. So, in the next 30 minutes we discuss here in the panel and the last 10 minutes I would like

to get your questions and thoughts and everything about that. So, my name is Melanie Wollnik. Um, actually I'm I'm in a leadership role at DB. And I'm also in a facilitation role at the Open Railway Association. So, now you know who I am. And I think you are eager to get to know the panelists. And so, I will start. Please introduce yourself and maybe just give us

a short introduction what your perspective on the supply chain is. Sure. I'm Tim Schmetzer. I'm an a lawyer and associate at Osborne and Clarke specializing in regulatory, mainly AI regulatory and cyber resilience and software law. So, obviously my take on this topic would be what legal requirements do we have when managing an open source supply chain and also what can be programmatical but at the same time

diligent approaches to to manage such such challenges. Yeah, my name is Cornelius Cornelius Schumacher. I'm working at DB Systel as open source steward. So, taking care of open source at Deutsche Bahn. I resonate with a pragmatic approach. Those of you who were in my talk before together with Max my colleague there, we told you a little bit about how Deutsche Bahn is approaching the supply chain the

software supply chain the open source software supply chain. And my main perspective there is that we are consuming a lot of open source software but we are not primarily selling a product based on software. So, implications are maybe a little bit different than than from other perspectives. Thank you. Yeah, warm welcome from my side. I'm Sven Jeschke, software engineer with the Robert Bosch GmbH or Robert Bosch.

Yes, the Bosch with the drilling tools or the washing machines or also a lot of car parts. So, in that regard we a bit similar to what DB is doing with also offering a lot of services which are not around software, especially hardware but also doing a lot of software on top of that. But that's what I can bring in here. I'm Sarah Hoffmann. I'm an open

source developer. I maintain a couple of projects for the OpenStreetMap project. So, I'm here as a part of the community and as one of these many maintainers where you have one or two people looking after the open source software used by companies which kind of was accidental to us. So, the supply chain for us is not so much a legal or risk requirement but first of all

something we suddenly are asked to do. Um, so how we can balance this is the question I'm going to answer. Yeah, sure. Thank you. Thanks for your introduction. So, now we have heard a little bit about the different perspectives we would like to Yeah, to to talk about today. We have the organization perspective on two sides, the community perspective, the regulation perspective. So, the question I have

for you maybe the same way. So, where do you expect clashes, tensions between the different views or the different needs we would like to talk about? So, from legal perspective when looking at how to manage a open source supply chain, I think we should bear two things in mind. Now, the European and German supply chain acts both come more from an ESG perspective which is usually not

the main challenges we face when talking about open source supply chains but the topic's much older. So, this is mainly existing regulations such as copyright as we know. And the other part would be making it a bit more complex new regulations such as the AI Act and Cyber Resilience Act as well. And the other topic we should we should bear in mind when talking about open source

supply chains would be that we are usually that we usually have a bit of a different structure to the supply chains than we do in in actual product specific supply chains. When I take for example a gear or I don't know a circuit, I usually have several different actors on a on a chain and the part comes from one part to the next step or link in

the in the chain. At open source we have a little bit of a different structure. I would call it probably a supply sun since if I if I take like three or four different open source components I do not get my licenses usually from the next link in the chain but always from the original licenser of the of the open source products. So, we have different licensing

suns that I need to to bear in mind and also different licensers and I I I do have to bear in mind different actors and more of them which makes it probably a tad com- more complicated to have an overview of your supply chain than it would be in an actual product in a physical product. Mhm, okay. So, what's your For for me this >> [cough and

clears throat] >> the the spread of projects and the number and the sheer number of projects of course is a real challenge. Um, but I think I I would summarize it as as expectations. Expectations differ quite a bit. And the company has expectations how software is made, how a supply chain is managed. Sometimes they are forced to do things a certain way because of regulation or it's

just company procedure or industry processes or whatever. So, expec- expectations what can we expect from a software vendor are transferred to what could we expect from the software community and that's that's often nothing which is even a term in in the processes. the other like like life cycle. First in our case we have a lot of products and projects which run for a long time. So, what

happens if we expect software to be maintained for 20 years? Who who can actually do that? Can the community do that? In many cases they actually can do that but how how are these expectations then expressed and negotiated? And how can we get more reliability on on what we expect from one side or the other side? And how can we get actually in in a conversation about

that? If that sometimes is is difficult. Also the scale again. I'm I'm sometimes sad when when I talk to open source projects that who ask for support for example for for conference or something and say okay, personally I find that very interesting and you're doing great work but if I talk to a 100,000 open source projects, I [laughter] can't sponsor 100,000 conferences. So, so and this then

sometimes leads to we are not sponsoring any conference. So, I would really like to find a better way how we can kind of match the expectations, also the culture, match how how we work together in a way that that we all benefit because in the end we are part of one ecosystem. I would just second what Cornelius just said because maybe from the other side also for

the people in the companies because I think there's also kind of a learning curve in the sense that they know how to treat suppliers. I'm not always saying that's in a good way but they know that. And if they now now try to adapt the same adopt the same principles to treating open source maintainers the same way, that will definitely clash and I think that's also a

learning curve that has to happen at some point. How to deal with that because at some point obviously there are requirements towards the software but also these requirements are more relevant for the people adopting that software. I think that's what what the Tim just outlined. So, the question now is how can we get into that part of communication? Not only from the cultural side on both sides

but also what is this actually helpful for the maintainers of the open source communities because just going there and writing an email you have to you have to fix that within tomorrow, I guess it's not helpful and not appreciated and might even lead into the other direction. So, if you think about the talks that for instance Danny Steinberg is giving with about all the emails that he

got after some of the Log4j incidents where he had to basically prove that he's not using Log4j. I think that's kind of tells your story like what has to be done also on for some of the corporates. at the same time the question is what is actually helpful for the maintainers. I think that's a discussion that we can also have here in the panel and it also

will I think quite some involvement in the upcoming years when there are also more requirements like you see AI on the corporate side to look into those kind of things. And maybe to say one thing ahead, I'm not sure that money will solve all the problems here. It's more of a question distributing the money and also using it in an impactful way instead of let's say a

lot of you just mentioned the problem okay, I have now have to find 100 companies. If you now look into all of your SBOMs, I would expect that a lot of companies find the same maybe 10 to 30 projects in their SBOM. And even though it might be very good for these kind of projects that all the companies try to look into that It's not really helpful

for the overall ecosystem because you have a lot of projects that might also need um consideration, but are a bit beyond the main focus here. So, that's also again a distribution problem that we might face here. Okay, Sarah. Yeah, so if you look this from the point of the open-source community, if you think about how the open-source community came to be, um so, originally it was a

group of enthusiast technical enthusiast who wanted to solve technical problems. And with open source, we basically created the perfect way of doing exactly that with eliminating all the overhead. So, uh we really do um the coding and we say we put the code out in the open because we don't want to care about licensing and uh restricting access. That's actually work. And even communication, we communicate by

just sharing code. That's enough. And the interesting thing about the supply chain here is it brings back what we tried to eliminate. that means uh the open-source community to actually do this has to find another model. On the positive side, I mean, it was kind of accidental that our software got used, but of course it's wonderful and we are all really happy that yeah, I mean, it's

a recognition. Um and it gives us the opportunity to actually say, "Hey, we can do this now for living. We can do this 100%." And I think this is the part where we can actually find a way to work together and find a model where maybe we can retain the model we had with this very efficient collaboration in creating software, while at the same time uh giving

people a way to actually do this 100% what they're really good at. What they're really good at is coding and not so much so commercializing, um making a profit from it. That's not the interest of the community and I think this is sometimes the misunderstanding uh happens. Okay, great. Thanks a lot. Um we heard a lot about, I don't know, tensions and uh different needs. Um so,

maybe we turn a little bit to what is your experience from um maybe some good practices from your organizations or from your work um where we can build bridges to uh towards this um yeah, I don't know, needs or tensions that arise. Who would like to start? I actually would have a question because Sarah, what what what you said, I think is is a very important point

that open-source communities are successful because they eliminated um all these overheads um and and that's something even would be useful for companies. I mean, companies would often like to have less overhead and they are trying to fight that, but in the corporation it's it's much harder than in open-source community. Uh so so, we we are thinking of that then um then in these terms and if we

are even talking about the term supply chain and supplier supplier, uh this is of course a certain framework of of thinking and I'm I'm wondering how how do you how do you feel about the term supplier? Is is that something which where you say, "Okay, go go away. I'm not a supplier. I'm I'm I'm community here." or is that something which which even could resonate and say,

"Okay, this is maybe a role um an open-source community could could also take." That's uh an interesting question as I'm also freelancer. So, basically as an open-source community member, I really shy away from the word supplier. Um but as somebody who wants to make a living out of this, of course then I also see the the way that there are customers and then basically I do supply

something and I I don't want to just be paid. I really want to give value back in this sense. Um what I'm thinking is maybe we are looking a little bit in the wrong way on this. Um we are thinking about, "Okay, open source is yeah, a supplier. Um you're the customer." Maybe there are other models to to look at this. Uh one thing for example, think

about research. Researchers are very similar to open-source developers. They just want to solve interesting problem and be pleased left alone about uh you know, making money out of it. Um and developed this wonderful system with uh university which are financed with public money, which basically give researchers uh some money to so they can pay their rent. And they give them infrastructure. The second part is really important.

So, they give them infrastructure and they give them um a way uh to apply for grants for example so to get the money, to have a little bit of competitions, and they give the companies the way to also invest their money into research and then to transfer it back to uh the companies needs which in this case would be the supply chain here to really put on

top all the legal legal um requirements you have to have to really use then the outcome. So, yeah, maybe we have to have another model here. While I like the idea, I have maybe a question to that because looking into the into the university system and speaking to especially younger researchers, I sense there's always like this hunt for a new grant, a new thing. It's I'm obviously

bad to say that, but it felt a bit like in one another conference someone kind of compared this to a drug dealer where you like always hunt for the next thing to keep going here and it's a bit different there. so, I'm wondering whether this is really helpful in a sustainable and long long run to always put the developers or maintainers in a position where they have

to hunt for the next grant or also have to hope for that grant. I know that it's more helpful than not getting any money, but how this relates there especially for infrastructure. And also flash and and then maybe another another take on this. I think we already have some kind of overhead also in the open-source community. I find it really interesting point that you said the open-source

community got rid of an overhead and I think that's totally true for within open-source ecosystems, but given the variety of open-source licenses that that that are out there and also different different FAQs of every different foundation maintaining such licenses is a whole different let's say overhead ecosystem. And I think maybe that's also the solution to to face new challenges of new regulations that that affect the supply

chain that the open-source community is already working together to manage to manage effectively using copyright. I mean, what the open-source community basically invented was using the copyright in a reverse way to protect the openness of software, which is an amazing thought. And to make this work, there has been implemented a seamless overhead that works like itself like a like a well-oiled gear. And I think that is

maybe also the approach on on how to to to use that um momentum that we already have in the community to face new challenges when it comes to cybersecurity or AI governance. I had the feeling that you just wanted to add something before or Um maybe shortly coming back to the uh university. So, I think you can't do without a little bit of competition. Um you can't

just We always have the problem, who do we give the money to? So, I think the grant stuff will always be there. It is at the moment the same thing, right? Uh as a freelancer open-source developer, I go from year to year. Um and with the university system, at some point you have professors. So, if you are good enough, uh then you come to a place where

yeah, you have basically an outcome for life and you can basically do what you want. So, basically the same thing for open source. You have a couple of maintainers you know who have been working well for years, have been looking after the community. So, at some point you can say, "Okay, these are our professors." And uh we do them we do this uh in a bit more

sustainable >> And just to clarify, in general I like the idea um of having these grants. I'm also a big fan of these um efforts to have something like the sovereign tech agency on European level. also I think would go a bit in that direction. I was just concerned that it that it's maybe not this fully sustainable solution to the whole whole problem. That's So, money helps,

but it's not >> not the And again, the distribution is I guess the major challenge here. Not a problem, but a challenge at least. Yeah. Okay, so Cornelius, what about your question? Are I one one more thought on that actually. I think the the the question of competition is is quite interesting because in the end open source is a pretty brutal environment uh in terms of competition

because you have the whole world competing with you and and the entry of the barrier of entry is so low. I mean, we we we see that. I mean, there are tons of open-source projects which are competing with each other uh and they are also competing with the attention of uh people who have money who or companies who who use it. Um I I I would even

say, I mean, in in the open-source world sometimes competition yeah, bigger or stricter or or harder than than in the corporate world where you have these structures and you have under normal long-term contract and you can rely on things. So, I'm kind of one wondering how how this will also develop um in in the context of the cyber resilience act. Um maybe you can also shed some

light on that. Um one dynamic which which I see there if if you put more pressure on both the community and the companies, I mean the system will somehow adapt to this pressure and will this lead to more openness that people share things like security attestations or something and and the whole ecosystem grows or will that lead to more silos where some suddenly people fight about yeah,

things they actually should work together. It's it's hard to predict for >> I think there's two interesting points about that. When talking about competition, I think naturally in the future, whether a project is is diligent and diligently working with with all the different regulation acts that we have out there, for example, Cyber Resilience Act. For example, the AI Act, for example, NIST, whatever, will be a competition

advantage when thinking about whether or not a product is used in in commercial products as well, which also increases an impact of an open source product, although it is not intentionally meant to be commercialized in the first place. And the other the other interesting point I find about that is the Cyber Resilience Act unfortunately does not lower the the level of complexity that we have in this

discussion because I don't know if you know this, but the European Union for whatever reason decided to create their own definition of open source to to make some some leeway and some some exceptions from from this very high level of cyber resilience obligations that are regulated in the CRA. And I believe that the European Union unfortunately understood the definition a bit wrong and understood free and open

source software to be as in free beer, not as in free speech. And so we have this this restriction that only such open source projects largely profit from the exceptions that are not mainly intended to be commercialized, which is if you look at I don't know if if you look at at an MIT project or even if you look at most GPL projects, it's it's just not

a realistic approach since most projects somehow must get funding and somehow must compete in an economic world and also gain gain some level of of impact also in commercialized products. So for most of the important projects, the exceptions won't be granted. I think the new new challenge. >> Exactly. Now you now you have this additional level of cybersecurity obligations that most projects need to fulfill and who's

going to manage that? I mean, who who if not the community works together and also uses the impact that we already have, the momentum that we have, the the level of collaboration that we already have to to get this Sorry? I mean I mean we're we're trying to and I'm pretty confident that the open source community is also lobbying for for that to be fixed. There are

unfortunately two or three different open source definitions out there. The European Union, you can thank directly to Brussels. Write a letter to to the commissioner. I don't know, yeah. I'm I'm not sure how much will happen there. We we of course deregulation approaches in the in the world like the Omnibus Act. I don't think it's top priority to fix the open source definitions, but it would be

ultimately the goal to to leave this to not over-regulate this well-working ecosystems and challenging them with with approaches that were mainly meant for for I don't know, the top-level commercial products. Okay. yeah, let's a little bit come back to the to the to the bringing together of the different tensions we have here or the different interests we have from the different perspectives. And I would be interested

in your I don't I don't know experiences maybe or ideas how to bring things together and maybe from your from the organization's perspective. I think we have I can maybe share two stories here that could be a fit to that. So one is I just mentioned the distribution problem. I think one question is like how to to figure out, okay, which community is let's say in the

need of the most support at the moment or has maybe is struggling the most somehow. So we currently also doing some research on the question on how to identify those projects out of all these It's kind of finding the needles in the haystack kind in the data. So we also will share a bit on that later, but if you have any interest in that, we're happy to

discuss that. I know there's a chaos community working on those kind of topics, but we also look into more of the data analytics side of these things. Um another thing and you pointed it out quite um quite importantly is I think the people that started open source projects, they didn't start it open source projects because they're so fond of doing compliance and tracking infrastructure because actually like

to work with the technology. So in the sense of keep the coders coding, I think the most precious resources these people in the communities have is time. So obviously money is a good way to buy the time or free that up free up the time, but in the end of the thing what helps a lot is ways to increase the time to actually put effort in what

they love doing, working on these projects or other things beyond that. Long story short, I think what could also have a huge impact is to provide more tooling and infrastructure that helps in solving some of these requirements that maybe come up more from a commercial player compared to what you have in an in the open source So as easy as it gets, like maybe you just install

a tool with one or two clicks in your in a pipeline or something and you do a lot of these things that are already helpful for the adapters. I think that could be a good good approach. So with the Eclipse App Up project, we had one example going in that direction, which is also luckily funded by some degree funded by the European money, but also with money

from our developers from Bosch and startups or one startup to shout out to double open I think that could be also a good approach to free up some of this essential resource, being the time that you actually spend on the project. Okay, thank you. So what's the view of the others? Maybe Sarah. So um from the open source side, one of the difficulties with these additional responsibilities

you get through the Supply Chain Act is so as a lone coder, I just code, right? That's the most efficient thing I can do. Now we've talked a lot about building up a community, increasing it. And so suddenly there's a lot of my time spent in just communication with people, onboarding, looking at PRs. Also, when companies say, "Oh, we want to contribute." Suddenly this is work for

me because uh I have to look at these PRs. Um so I think there's not enough awareness yet about these additional tasks, which also we somehow have to find time for and hopefully would be paid for. Um so I was lucky enough by the Sovereign Tech Agency to be selected as one of the maintenance fellows last year. And this was a really good project because it really

said, "Okay, yeah, you're paid exactly for this. If you answer an issue, that's that's the time there." Um and I think programs like this where you can really say, "Yeah, the overhead, that's finally where it gets paid." This will help. It will help a lot. Okay, something to add? Yeah, maybe also standardizing and and like creating best practices so that that not that individual people can create

a level of awareness that makes it less difficult for for some manage like people managing positions of projects to to take care of all of this because the more effort anyone who who is involved in open source coding gets into being diligent with regard to the different obligations that are in in the in the supply chain or supply some would reduce the the effort that that the

project maintainers have. And also I I see that the that the foundations managing ecosystems probably would would have or will probably get a a bigger role in this in this issue, which is also a bit what what was what was intended by the Cyber Resilience Act as well because the open source stewards, as they call them in the Cyber Resilience Act, they do have a bit more

leeway when it comes to how they act and how much they need to take care of. So I learned that we have left 10 minutes and we wanted to to to the audience. We have one first question. Well, let's see if it turns out into a question or if it's a comment. So I totally dig this uh um open source like put the overhead away and people

are happy with that. Um and I want to comment on this maybe we with the supply chain approach approach from the supply chain, they should take a little bit of that back. I want to add there an if if they want to for whatever reason, if they want to make a living out of it or whatever, I think it's perfectly fine for an open source project to

say, "I I don't care." And this is this is we need where we need to handle this situation also because it's for them it's it's perfectly fine and of course the supply chain has interest to like have their expectations met. yeah, this is I think also one of the problem which needs solution. Tooling might help there also. I agree with that. So would like to answer somebody

of the round. I don't mean I get the approach if you're not like situated in the European Union. So most of the more complicated acts don't apply to you, but I'm not I'm not entirely sure if this would be maybe it again on the competition issue because I don't I don't know I'm pretty sure that projects were well maintained and and have well documentation for companies to

work with so they don't have this huge overhead on their side dealing with with all the requirements that are out there. You could you can discuss that they are that they are a pain to to implement, but they are there. So I'm I'm not entirely sure if this is a like a competition disadvantage for such project that say I don't care. And if if it's not more

of effort that the whole community should take to to get an overall well-maintained environment and ecosystem. So everyone could profit from the best practices that are already out there. Anyone else? Yeah, thanks for the interesting discussion. My point is I think we as companies or I represent a company of course. We have to make ourselves aware that we get stuff for free and the communities out there

have not chosen that we pick their stuff and therefore it's our obligation to actually work with them and not theirs. And that's where my question is coming from. How do you make your company aware what open source is because we know that here, but the people in our procurement in maybe some even of our devs, they don't know how open source works sometimes. And how do you

make it them aware how the supply chain works in this? Yeah, that's a good question. I think organizational >> maybe you too. I think there are two parts to that. Making people aware of how open source works and kind of getting the positive effects and how this could help a company, how communities work and help and so on. I mean this is very hard because that means

explaining something which is alien to the company which is not in their DNA. So this takes I think a lot of time and patience. For for other things like in terms of what can we actually request from an open source maintainer, there we are much more in the area of what companies are used to do like I mean dealing with regulation, conforming to processes and so on.

And that can be quite easy actually to say we don't have a contract with this person so we don't have a way to ask anything. So let's just not do that. So I think that's that's more easy. That's more about what what I sometimes see that there are really misconceptions where I thought okay, they would have been clarified 10 years ago already for all the world and

they still come up. So and and and that's that's again an explaining part where you have to explain people what what open source is. But I think with with these new obligations we have with the CIA and so on, I think companies are from my point of view at least well prepared to deal with that in a way which is also compatible with with the open source

world. We just have to be serious about it and yeah, be trustful to each other and so Okay, Sven. So I feel like I was also dressed with the question. So >> [clears throat] >> I think one thing that is not maybe not the best practice, but helps us a lot is transparency in any any degree like actually make transparent to what whoever is in the organization

that you rely on these things because since it's so easy to consume all these open source especially if you talk about infrastructure and packages, I think having this transparency helps a lot and that's also kind of where we want to look into when we do the analysis analysis of the projects there to have more transparency that they are actually people and organizations behind that are not just

code popping up out of out of the internet. That's maybe one thing I think to the transparency what also pays in and is basically training and not just for developers, but for part of the organizations. I think that's huge task for each of these organizations on their own. I think that's also one of the reasons why we see so many OSPOs popping up at least in different

places in the organization. I think that's one of the two of these work out. I had a third point, but yeah, that's maybe connect afterwards. Okay, thank you too. So and we have just a few minutes left. I would like to yeah, round up the the the discussion a little bit maybe in the other direction. We said here so maybe one last sentence so what you take

with you from the discussion today. Um so yeah, I think we have a long way to go. yeah, bringing the two worlds together and understanding. I think especially communication. We are still not it was interesting to talk all to all the OSPOs here because there's a completely different level of yeah, of communication of way we we talk about it the problem and I think that's we need

to keep going. Yeah. More communication. Okay, thank you, sir. Sven. I think communication kind of summarizes also what I take away, communicate about coordination because I think what what I really liked when you even accepting an external pull request from another developer is time for you and takes effort effort and I think that's also what I'm a bit afraid of we might have end up in a

situation where a lot of projects get not overrun, but get a lot of PR's and maybe others not and that also the level of communication where we someone needs this communication also to coordinate a bit in the ecosystem. Communication. For me one very important aspect is we need high quality open source projects more than ever and we really have to make sure that this doesn't get lost.

And this is work on the sides of the community. This is work on the side of the companies, but we have to make sure that open source software provides building blocks our IT infrastructure can rely on. We have a lot of critical production systems which which run on open source everything. I mean society wouldn't work without open source anymore because it doesn't work with without software anymore.

So we need to take care care of this and not let it overrun from yeah, developments which undermine open source projects. And this will take maybe some pain on all sides here and there, but I think we have to get through through that to yeah, get to this constructive zone of collaboration where we can provide this IT infrastructure we need and be in control of it because

it's Tim. I think my take from from this discussion was that everyone needs to commit to to making this work and everyone needs to take their part. We already have brilliant open source projects out there that are completely safety certified in line with with ISO certifications and so on. So on so I think if everyone commits to making this work from the industry as well from as

from the open source community, we can we can go a long way. Okay, great. So I think time is over. Thank you for your time. We appreciate it very much. Thank you for your questions and have a nice evening afternoon and evening. >> [applause]