Welcome, welcome. So I'll try to drive the discussion. First, before we start, who of you
are involved in maintaining open source software? Raise your hand. Oh, that's wonderful.
We really have a majority in the room. So hopefully we'll find a way for you to avoid
committing suicide by dealing this call. Let me introduce open list first and foremost,
Piotr Carwash. Piotr is somebody you've been talking to talking about in every single
presentation. You've given or you've received the box software supply chain security is the
lead maintainer for look for a project with a battery that produce wonderful bugs. That's
we love to love. Actually, he's not the one responsible for the bugs. Piotr? So I mean, I take
this one service for the bugs. Well, for fixing them that is welcome there. Yes, so there's
also a maintenance of look for a wonderful. This guys actually came to look for a in a assist
and really to support and take over the project to fix the bugs. Then we have Michael.
Michael, you want to introduce yourself. Is it? Yeah. Hello everybody. I work at a German government
for the PSI. And there I'm one part of the market surveillance, which is in a few months
responsible for so waiting a lot of the stuff and a lot of the products with digital
elements. Just make sure you don't scare us. When you say surveillance, you mean surveilling
the markets, not surveilling us, right? If you're nice enough. No. You're not watching what
we're talking about. All right. Damn, colleagues in the room, they'll do that for me. Okay,
good, good, good. And next up, we have Liz. Liz maintains. She's from the Pearl and Raku Foundation
and maintains Raku, which is formerly known as Pearl Six. Yeah, I would say the other way around
nowadays, so we prefer not to do that named things. But I guess I'm here because I'm a maintainer
of a lot of open source modules and programming language as well. So how does this CRA effect
us in that moment? Great. So we want to discuss how the CRA is going to impact up and
so-so for maintainers. You want to start Liz, what you take? Well, I guess if you are a maintainer
of a module and you don't want to be bothered by all of this, then don't be bothered. That's a
really the simple solution for you. If that means that some entity will actually fork your
module and do changes to it, they are actually obliged to provide you with those patches. So
you might actually just profit from it that way. But if you want to actually be more involved
in the whole process and actually want to get some support for it, then you might actually
want to get involved with the CRA and everything around it, specifically with software stewards
and getting adaptations to actually pay you for the work that you do. So, but you're saying that
if you don't want to do anything, there's nothing to do? Exactly. Okay, talk his over. No,
just kidding. Michael, what do you think? As mentioned, the main part is a manufacturer
is responsible for his product and for everything he puts in there, including all the free and
open source stuff. So, he needs to think about what he can do with those components and you don't
have to do anything if you're just coding stuff and you like doing that and you don't want to
manage anything. They have to take care of it either. They do it on their own. If they can.
If they don't, then maybe they have to find someone who can and then pay them
doing the stuff or maybe it's a good idea to talk to the people and gauge with the people doing the
great stuff and try to support them in any way. They can. So, that their products, again,
because they're responsible for their first applications. So, basically you're saying
the authors are going away with get out of jail cards and it's all on the users.
No, it's on the main, it's on the ones integrating stuff into the products.
So, commercial users then. The commercial users of the software that are integrating
or brings those package in the product. Good, good, good. What's your take, Piotch?
Please, as has said a lot. So, yeah, if we want, we can adapt. If we don't want, we don't need to.
Personally, I see it more as an opportunity to get our actors involved in funding. So, it's
certainly cheaper for a manufacturer to delegate work upstream than to do it itself several times.
So, I see this as an opportunity to get more manufacturing involved in helping workers' projects.
And you don't even need to have luck for shell to get their attention.
Well, you're kind of a top dog in the pyramid of vulnerable package because you're very well known
to that helps. But at your scale, do you see actually a rush of software or of company that
could digital products on the European market that are rushing to you to say, let us help you and
so on? Do you see something happening or is just you hope it's going to be something?
That's something that I hope. So, as you say, since we have a big vulnerability, we don't know if it's
because of that or because of CRA that we had some funding like a big SDF project to improve
the security posture, the documentation and everything for LaForgia. But that was, we don't know if
that was CRA or LaForgia. Okay, you're also in a big foundation. So, what for other smaller products?
Maybe a smaller project. Even though Blackpool is also part of the profondition, the Black
Foundation, which is foundation, it's probably smaller in scale than what Apache does.
Well, that's interesting question. Okay. So, at the moment, we are considering setting up a
rack of foundation. Oh, okay. Well, hold that little thing in the software Stuart situation.
Okay. So, yeah, it's really an open question in our case. I guess for Pearl, it's a similar situation
because there is a foundation, but the foundation is not really involved with any coding or anything
like that. So, and I'm not sure how it is with other foundations, but this is an open,
this is a difficult question to answer at this point, I think. Michael, what you're thinking
about about foundation versus non-fondition-based projects? Well, foundations or they might
be capable to do more stuff and in case of an open source Stuart. So, the Stuart is intended to
manage open source components which are intended to be integrated into products. So, they might
be capable to fulfill the Stuart's obligations like reporting vulnerabilities working together
with the market surveillance, then small maintainers and we did a questionnaire last year where we
asked maintainers what their main worry is. And once in one comment, which came out was like,
I like to code, I don't want to manage. So, they just want to do stuff and they might not want
to interact in the way like Stuart's can. And one thing we see or we also see is right now
not everything is great and we got to the CIA. So, we talked to Daniel from Pearl,
what he is seeing that manufacturers in that case, not from Europe, approached him, sent him an
extra sheet and gave him a two-week timeline and for the CIA, we need all those informations
please provide it to us. And what can go wrong with that? Definitely what we don't want to see.
So, we have to find ways that those things don't happen but the ones who can provide it and they
want to provide it that they come get something out of it and that they can be part of the process.
But again, they need to have something out of it. Nobody wants to do it for free.
And we don't want to be to have the pressure on open source that they're providing the open source
now everybody wants that all the services around it are also free. That's not what needs to be there.
I think that manufacturers should see open source more as a resource rather than something
that they can plunder at will. And the resource that needs to be cultivated and that's a change
that we need to strive for, I think. Yeah. So, I have a question for the audience because
several of you are seeing with your phone or your computer, you should be listening to what we're
saying. One of you is actually a mentor of a project working integrated in a larger
foundation or is a solo mentor. So, solo mentor raise your hand. Okay, it's actually a good
part and projects incorporated in foundations maybe in properties, not the right term, but go ahead.
Okay. So, probably a bit of representation of both. My understanding is that
there was an article made by a guy called Josh Brescher, is a sizzle at Omkore. This point was
open source is an army of one where basically the large majority of projects are single mentors.
Last year there was a guy mentioning a Python package called Chrome Ether and he says,
I'm stopping maintaining this project which is used everywhere.
Series killing me, I don't want to be part of it, bye-bye. So, what do you see? What can you tell
about that? What do we do for the project of ones that are scared and want to run away?
Well, in our case, we have something called Racco Community Modules.
Basically, what? It basically means that the original author has decided to not be bothered by it anymore
and people still use it and people want to maintain it. So, we make it a community model,
basically means that we have a set of people that have rights to the community modules repo
and they can do the maintenance and then all of the pull requests and all the stuff around it.
So, it becomes really becomes a community effort. Okay, but how would you
How could we avoid that people get scared and stop supporting and maintaining their projects?
Because of the series. Is it rational? I mean, people have to make a decision. I don't think you can
actually prevent them from being scared because it is the EU doing these things and
you know, we have surveillance here as well. So people might
get scared. But that's not a surveillance. You need to be scared about it. I think it's actually an opportunity
for you to continue doing the things that you'd like to do, which is coding.
Okay, I'd like to go more on that terrain. So, how can we do more?
And what can we do if we want to help with our project? Given an army of one, we're
everything related to the series. You said it's an opportunity. I'd like you guys to to expand on that
First, I want to say something. Please don't be scared. Market surveillance is not coming
after free and open source of them. So, we have products on the European market and that's
what the CRAs for, which doesn't comply to a lot of the requirements from the CRA and those are
the things we don't want it or we don't want here. And we need to so well,
won't be the free and open source of stuff.
I wanted to develop a little bit more the chronic situation. So, the maintainer got scared.
He wanted to delete his GitHub repo and just go away. So, I know a little bit more because the
help came from the participation from Apache Airflow. So, in the end, what happened is he gave
the project to two downstream containers that are continuing the project. So, don't be scared.
Don't drop everything and as the mostly mostly don't close delete GitHub repos, reach out to
downstream users. If your project is used, they will be happy to help you. Okay. So, in this case, if
I recall correctly, as you said, the quality was a dependency for Apache Airflow.
In this, the dependency of Apache Airflow, Yarek Pothuk, talk with the maintainer, talk to you
into, he wanted to talk to him into not being scared that was not possible. So, of course,
everybody decides for himself. In the end, he talked to him into giving the project to another
foundation, not the same, but another foundation and Yarek and another Airflow
maintainer took the ranks. Yeah, it became part of the jazz band kind of group of project,
right, something like that. So, if you want to give up because of the CRA, basically the word is
reached to your downstream users and eventually they'll take care of this for you because they need
your code, right? So, we don't have to be scared, we can do nothing. What's the upside with
all this? Is there any upside? Well, I think one of the upside is that even if you don't do
anything about this, anybody doing patches for you on the stuff that they fork from you,
they have to deliver the patches up to you. Even if the license doesn't say so,
which I think, if you really think about this, it could be mean that you, for free, get people
actually maintainer your module. I mean, that's one way of thinking about it, although that's a very
minimal way and if you really want to get more involved with this, again, making sure that
you are providing stuff for it and not just saying, I'm going to have to do a lot of work,
but I'm going to get some kind of remuneration for it. It's a good thing and a positive thing
and builds on the resource aspect of open source. What do you think the upside could be, Michael?
Yeah, one thing mentioned and Toby had a whole presentation without slides on it, but he made it very
good. The opportunity for the open source adaptation and there are a lot of discussions on that.
We as PSI and the Free Software Foundation Europe published and surveyed today, there is also
and surveyed from the Eclipse Foundation and there are a lot of discussions from the Eclipse Foundation
and whatever is doing that and there will be a talk on that tomorrow in the other policy, EU policy
if we get that right, that could be something where manufacturers get the adaptation, pay for that
and then developers and if we get it right, even single developers might profit from and then
they can provide more time for their stuff they're doing,
this projects might get better because they can put more attention on it and then even the manufacturers
might or will have something out of it because they get better open source components to put
in their products. So you see attestations about security in an open source project,
eventually as a new currency, can a new token where we sell as open source project
that stations to users commercial users that won them? I see that as a chance because
manufacturers are responsible for everything and if they have something,
they can show that they've done their due diligence and they pay for the commitments
the open source maintainers put into their projects, then if we get it right, I see the
big chance to get some money flow towards open source. What about this, do you see Plot?
Yeah, I do so also something that we said that probably there will be some professionalized
maintainers, I think that's a reality that's a very strong possibility for such a thing to happen.
Personally, I'm living from open source since 2023, so that's so ice, well, when I
when I reach three years of 100% professional independent of the source maintainers,
let you know, but I think that's something that we can count on. Is there a risk that they are
commercial, middle man, that would establish themselves as, you know, attestation paddlers,
and that we'll just annihilate any opportunity for you to ever sell any of these services,
because they will aggregate and be an easier worker to deal with. There's already a few companies
like that. There is a possibility, but I know also a couple of nonprofits that
support to do that and well, since the lowest price drives, so I come in shell
actor needs to have a higher price. Please, you want to say something there?
Yeah, I think we need to try to stay away from the paper adaptation idea, because that becomes a
commodity that becomes economically viable for some company to actually start providing.
I'd rather see a situation where a software steward would actually offer
attestations on demand at a certain subscription price for sponsoring for the steward.
Could we, from a regulation or government point of view, help this process to,
maybe, say, attestations should come from the origin of the stream when available first,
and only from other downstream repackagers, if not available for the upstream,
to get the middle man.
That's an interesting point of view.
So, the question was, is someone made a business out of deadly attestations that they would
become manufacturer themselves? That's a question. Is that the case, you think?
You have to look at it in detail, but that could very well be the case.
And the thing is, good. Right now, first, it's not clear what the adaptation itself is,
what's, you say, if it's commercial, it's going to become a support service,
like any other support service. But you're saying, also, maybe, that if I'm a
solvent and irrevervenous was project, and you're building something, you ask me for an attestation,
I sell you this attestation, all of a sudden, I become a manufacturer.
How much of this is acceptable. If you are just covering your costs, including your time,
that is not necessarily commercialization. There will be a limit, and we need that limit,
you're fine. If you're still not rocket, I mean, clear, so there's going to be some interesting
things to do. Go ahead, please. I'm just envisioning that some commercial entity decides
to fork everything and decides, okay, this is our fork, and we go providing attestations for it.
No, because they would be forking, they will be working off the fork and devise claiming,
this is our resource, right? So, they would be claiming that this is our fork,
we provide attestations for it.
I do, it's on our list for it. Or, it's commercial entity, can you give them any questions?
Okay, I think there's going to be, I'm sure there's going to be interesting case to discuss,
talking about that. There's an obligation to CRA for manufacturers to somehow eventually
report upstream security issues that they found. What will you do with this? If you receive
security patch from company X, Y, Z, for lock for J, security issues.
They need to send a patch. I don't know, I know exactly what the obligation will have to send a
patch or just report the fact that discovered an issue. But how do you see this process? Do you see?
So, if we receive a patch, it's like every average security issue, we just handle them.
And it's better because we have to have a patch that we can compare against.
Please, you have an option, a piano on that? Any patch is a patch?
Okay, can I just sit on it and ignore it entirely? Or do I have any obligation on this, CRA?
No, you are cementer, I'm not going to just take it or leave it.
Okay, so you're not seeing the minute for that.
Now, I have to report and to provide a patch if we made a patch. So, he has to do both.
Okay, we've talked about the fact that I can do nothing. I can ignore patches. So, basically, business
is usual for me as a man-tener. We have a potential upside with attestations. There's some
Graria, maybe with middleman's. What are other things if I want to be more proactive as a man-tener
that I can do? What do you think, Michael?
Well, I see a lot of open sources already doing. So, they're taking a lot of them are taking
the principles of security, by design, security, by default, into account and do it like that
because it's open source, the point with S-bombs. So, if the tooling is there, that's one thing which
can be covered and they can use tools like open S-bombs provides a lot of tools if they want to
use it to make their products more secure, so there's a lot of stuff out there. Great, but they can
decide what they want to do and how they want to do. Thank you. Liz, what do you think? What are you doing?
I lost my train of Sautia, sorry. I think that we, we should really try to see open source as a resource.
That's really the most important thing here and the other thing is, if I kind of back to the
module maintainers, there's a very nice new standard in development, I can understand that about
how a maintainer of a module can describe what they want to do with the module, what kind of
support they want to have and give the contributing dot-yamel. Oh, that's plethora. And Sautia.
Yes, Sautia. Okay, great. And basically, as a module maintainer, look at that standard and make
sure that you provide the right data and that sends us also garbage in garbage out if you don't
provide it and nobody knows what about what to do with your module and if you do provide it,
they have some more information to handle it. Okay, things to search for.
Sautia, it's contributing dot-yamel. Good. Yeah, yeah, yeah, it's a
acmatici, tg4, contributing yam, recommend found a nice, nice name, yet Dugnak was one of the
that's terrible. Tc54, yes, tell out to our key for make now. It's a task group, tg something
under tc54. Tg, tg4. Tg4, yeah. Okay, from my perspective, the projects have to have to
two choices under this area. And then do nothing and then maybe receive, receive help from
companies or they can choose to be proactive, introduce a lot of
standards for a fuller project that that's what we chose. So we chose to go forward
to help companies first and then hope that they will help us back. So we are almost a salsa source
level for compliant. Well, she means that we have two reviewers for each PR, which is
actually a bit difficult because we have two active commuters, but whenever I make a PR, I think
you've all come whenever he does a PR, he thinks me, but yeah. And I think you've experimented
also to producing vex documents. Can you tell us a bit about your experience, is there?
Yes. So we chose as bombs in 2023. Well, as a moment was quite, quite easy because the
tooling was there. I'll introduce the videos almost immediately as fuller projects just the
list of vulnerabilities that we have. And now I'm experimenting with vexes with Monowar with
open refactory. We have a tooling that generates vexes for a patch of solar that has
400, first-party dependencies. Once that works, we will of course use it in a forge
that are far less dependencies. No. Okay, so other questions should you, I'll shoot a
maintenance or a filament and I'll become parts of the foundation because of the series.
And should I become a steward? What's the up, what's the pose, what's the calm? Is there any
restrictions or additional work for me if I become a so-called steward?
And you, Michael, maybe you have a word on that?
A steward has certain obligations under the CIA. So again, the reporting obligations
working together with market surveillance and we need to have in place vulnerability policy.
Okay, but there's the trick they don't get any fines if they don't follow those
obligations. That's something which fines are only there for manufacturers.
I think it's the decision of the maintainer if he wants to become a steward.
Again, I was surveyed last year, the ones who answered it. I think two thirds of the ones who
answered said they don't want to become a steward and they don't want to have any other entity
than themselves to be a steward for them. So the projects who answered were in favor of just
being a project in maintaining. Okay, and okay, you can, you can talk to that, please,
otherwise I think we're reaching the time limit, so I want you to make sure that you just
give a less word as a maintainer to the other maintainers. Few words. Yeah, also, so if you are
thinking about joining the patches of the foundation that could be difficult because you need to
first ramp up on your community to have at least three commuters, but then when projects are
all there and there is only one active maintainer, the fact that the steward helps you with
the foundation of those people. Okay, but so final words to maintainers when it comes to
the theory. Keep doing what you're doing. Okay, Michael, and you have time while doing it.
Great, pure, and don't panic. Okay, great. Thank you.