LF Decentralized Trust TAC Meeting - 2026/08/20

Hello everyone, welcome to Linux Foundation decentralized trust technical advisory council meeting on August 20, 2026. Before we get started, couple of reminders for all of us. The first one is antitrust policy. We do uh we do have participants from across several organizations and we request all participants to abide by um laws that govern across um different places I mean different organiz I mean different um geographies places organizations as well. The um next one that we have is because of the diversity we have on these meetings, we request all our participants to be respectful of each other and if you have any questions or any topics that you would like to bring up, please feel free to raise your hand and uh we we can discuss in collaboration. The next one um we have is standard announcements for the week. Um for we all know like there is developer newsletter that goes out to large community and if you haven't already used it this is a great medium for you to request for comments or talk about your projects or request um inviting participants to contribute to your projects and and more such things. All we have to do is leave a comment on the wiki page in the week that we want to send this announcement and it will picked up. And the second announcement we have is um we'll have um the new TAC for 26 27 term. Uh the election for that will be held later this year. So we are I would say about less than two months away from the elections. So if you have some someone that you're thinking about to nominate or if you want to selfnominate this is the right time. Um please do reach out to your community members as well and talk about tag and um we request you all to participate. Okay. Um so we do have a overview report on smooth um where the feedback word to be shared with the smooth project team. I'm not sure if we have somebody from the project team on this meeting. Okay. Um, Marcus, do you know um if we heard if we heard back from Smooth Team? >> Well, I didn't hear anything back from them. I tried to reach out to them again via Discord. Um, yeah. So, I didn't hear anything back. So maybe this is the time to maybe ask someone from NFTT stuff to reach out to them to try a different channel and see what's going on. There's David raising his hand on that topic. >> Yeah, thanks for flagging that Marcus that you reached out but weren't hearing back. I can try reaching out to him too and let him know that TAC members are having some additional questions and are trying to get in touch with them. I I'll email him. >> Yeah. And that would be great. Um, >> thanks David. And one more project report that is on the same front is Minocoa. I know uh previously we had Kevin joining us and requesting extension till um 6th of August. We have not heard from them since. >> Yeah. Danielle and I spoke to somebody from involvement yesterday, not Kevin, but uh um I mean I can't guarantee that this will uh uh move things forward, but we did flag that the uh uh report was overdue and uh um hopefully that helps move it forward. Thanks, Danny. Thanks, Danny. Okay. Um, so I I just listed India report because I saw there was an open PR from Matthew. [clears throat] Um, I believe like this were for the comments. Um, I mean if that PR can either be closed or like if we think that needs to be merged, we may need to rebase that pull request. So, I added that as a reminder um to be brought up in this meeting. >> Yeah, I um went and tried to uh fix that and I Matthew, if you could take a look and either port your comments over or something of that nature and then I'll I'll merge it for you. >> Sorry. Uh can you just remind me which PR this was? This is for the Indie annual report review. This was to um add your uh >> Apologies. I'm with you. Yeah, I'm paging him. Yes, thank you. Uh yes. So, I will do that and then and then we're gonna merge. with you. >> Thank you. >> Thank you. Oh, so we we did start to receive media reports and I um I believe like I heard from David that um the reminders for the project reports have are not consistently sent. I took a review of that. So we we are sending as of now the only way we are sending reminders is by raising a pull request on one of the primary repositories for each of the projects. And um right so if if project teams require additional ways uh to get reminders, we could set up maybe mailing list. Uh we could bring that back or we could look at um sending reminders like maybe every week sending a reminder on discord channel for all the upcoming project codes. I'm open for suggestions. Um but we do have three media reports pending on review from TAC. If you haven't already had a chance to look at it, I request you do review it. Um before I [clears throat] continue, is there anything that any of the tech Okay say Henry raising? Henry. Yeah, I I I have a question to um something Marcus brought up um as a comment on on the Hyro um report. Maybe you can go to it because um one thing which is part of the um report is saying okay we we are a graduated project and um the the question is how as a graduated project we can move forward for example whatever bronxer silver gold status and and what Maros brought in and and our question was like how to do so what what need to be done and Marcus brought in if if we have something in mind next to open SSF scorecards if I understood Marco's command correctly and and that is something I I would like to to discuss in the tag because um I I would say yeah for graduation those open SSF scorecards are quite important, but if you go over that, I would ask myself if there are not not other um metrics that that may be even more relevant than than that when it comes to diversity to to the community, how old the program is and so on. So, um that that's just something I would like to discuss what what the tech is is thinking here. Um how something like that should look. Could I ask what you would like it to look like? >> Me? >> Yeah. Do you have a proposal? I mean, >> no. No, I do not. I do not. It was more like a question to the tech even in the um in the um um report, right? Um and and Marcus was somebody already answering like do you mean anything next to to open SSF scorecards? I I would say yes. Um I would say we have something like AFX insights. Hiro is now starting to create their own um metrics for for diversity and so on. So we have an analytics repo where we count those numbers and and even now have a website where you can see diagrams and tables out of that and and my personal point of view is that for sure OpenSSF scorecards should stay and should be important but they are already at the um at the graduated level and and for moving to the next stage I I would like to to bring the focus more on those top topics. >> Jessica, >> hey Erin, let me add to uh what Henrik is uh saying uh because this is something that the community has actually commented uh to us in um TSC meetings. Um basically they um they are looking the community is looking for some how to say this something to look forward to um to work towards and yes we have open SSF scores and we have the best practices batch but they're looking for something that can be added on top of the graduated status and um we put some example there of what they mention like for example okay um uh bronze graduated status silver graduated status and I know this is very complicated and it's not something that many communities will uh will be on board for but uh we put it there as an example of what the community is uh thinking about they they just want like to have something to look forward to um as part of the graduated status >> Jessica is this one of the um reports that Sophie um has possibly created a a an example of that you can share or is there a section in the report that describes it that someone could put on the screen to to dive? >> Yes, it is uh it is part of the can can you click on on the pyro? >> Thank you so much. >> I think that will help a little bit. If you scroll, if you scroll down to the comments, you're going to see uh Marcus' comments. Go down. Go down. Okay. Uh that particular comment, if you look at line 117, that's uh that's what we added for the um TAC uh recommend TAC guidance recommendations. Uh it's it's uh it's just what the community has been telling Hendrick and I about what they are what they're thinking. >> Yeah, that's pretty generic. Um and and is that more about organizational diversity which I know is one of our big um hot topics internally about whether they you know we may have acquired graduated status within the first year but our organizational diversity numbers are quite low. Um is that what you're getting at with the bronze, silver no and gold status? not not only regarding diversity, it's like overall. >> Okay, M I see your hand is up. >> Yeah, thanks. Um, yeah, it's an interesting discussion topic. I think um I think it definitely benefits the TAC to have or the LFDT to have slightly more granularity to its current kind of life cycle stages. Um, I know we've talked in the past about uh categories around maybe being more stabilized where the the project is maybe well used, but there's not a huge amount of new um function to add. Maybe some of the spec projects this will apply to. Um uh and so I do also think there's a benefit to having having a number of having a number of different discussions about what what different options you have in in maybe graduated status. Some some might be different to graduated and some might be subcategories within I think um quite how you turn them and what what consumers of the projects would interpret those as that would be an interesting part of the conversation. Um, do people interpret bronze as being substandard in some way? Um, and I think that's something to to kind of treat with caution. Um, so but I'm I'm definitely uh happy to have these discussions about what what additional granularity you can add for for projects to kind of aim towards. >> Thanks Musc. >> Yeah. So I understood this point here. I mean in basically two ways. So way number one is to motivate the community to have something to work forward. I mean I understand this as gamification. You set a new quest, collect those points and then you get a a nice treasure. Cool. Bronze status next silver gold. Awesome. But I mean what what would you do guys once uh you got the gold status? do we then come back in I don't know one and a half years introduce diamond status whatever right um but I understand the motivation of it and I kind of like that um the other part is I mean such an indicator would give uh better a better signal to external users uh if that particular project is in is in a good state or in a very good state or in brilliant state whatever and this also makes sense for me. However, if I think about LFDT as an organization, I mean, how would we as LFDT um benefit from that? I mean, yeah, we encourage people to try harder to get on a higher level. We would also give users some metrics to better judge if they go for maybe LFT project A or B. Is this something we want? I'm I'm asking myself, but I I was just um I mean bringing the open SSF scorecard here on the table because I believe this is something like an externalized batch or something which validates uh a per or checks a project status against some standardized metrics uh and then basically allows you to put a batch on on your project. And maybe there are other um batch systems uh which the community could look into and uh get some external validation rather than being the tech the ones who define now new granular states or project states. And then we have to deal again with okay uh do we do we need to downgrade do we need to upgrade this particular project? Um, I see difficulties there, but I also see value. So, I think this discussion is actually pretty interesting. >> Thanks, Marcus. >> Uh, Henry. >> Yeah. Um actually I like ma Maros what you brought in and and your thoughts and I'm I'm kind of thinking the same right. So I I see benefits in it and and I see drawbacks in it. Um I think the the question is how something like like that will be settled right it should not be settled as as a marketing or say one is better as the other. It should be, you know, like maybe a kind of of quality mark and maybe even a kind of quality mark in specific directions, right? So saying like, oh, we have here really something that has a a high diversity where we can really say this is um vendor neutral or or whatever, right? I'm I'm I'm thinking in into that directions. Maybe it's not even like a higher rank so that you say like oh we have incubation graduation and then diamond whatever maybe that is totally wrong but but maybe thinking more about um gold batches I don't I don't know you know like just just saying something I don't know what the right term is um to to give the projects um the chance to be quite strong in one direction and and having that to be to be honored by the LFDT and and presented to the outside. >> Thanks. Um I I would request I would like I I have a few comments but I will also request Rama to pitch in. I know previously we attempted at having some kind of badges against each project and then we eventually realized that the life cycles that we have it's um indicates or suggests um the the uh stage at which the project is in and yes instead of relying it as badges but we wanted to m it as attributes that we look for in each project to determine if if it's in a meeting in the stage or so, right? Um it's it's a good problem to have that we have projects aspiring to be more than um the current um status or the project success criteria that we have uh for measurement and um just thinking about it the way we want to maybe um I mean this could be a request to project team um the way you would possibly consider expanding and and um beyond is to try and um be that de facto project for any problem that people want to bring in or solve in that space. So um I would say like that would be the big check box from a project team's perspective and and of course like having all the success criteria met within the community. So that that clearly signals that um the project is a thriving one and of course it's always good problem to have when we have projects aspiring for more. >> Matthew, >> yeah, thanks. Yeah, I guess I was I was um kind of think listening to some of those previous comments and thinking out I think it's kind of important to to look at this as a here are additional positive signs about a graduated project um rather than you know so so that people know a graduated project has met you know a good level of criteria and and that you can have a good degree of trust in the in the governance levels it's met and and and and so on and anything in this space should be kind of additive around amount of uptake amount of um uh kind of multi-org contributions and so on rather than like a the kind of the bronze silver gold approach that was kind of suggested as as an idea. Um so yeah I I kind of think these should be additive positives rather than a graduated project ranges from not so good to really good if you see what I mean. Thank you Marcus. Sorry, thank you Matthew. I also see Rama sharing the link from for previous discussions on this topic. Rama, >> yeah, I think you accurately summarized uh what our previous thinking was around badging. the fact that uh we have uh the open SF scorecard and uh I mentioned the clone monitor but anyway we have the LFX insights now um so between those we have enough metrics to judge uh the majority level of project and and it's um I guess it's uh uh technical strength so we felt there was no need for badging I think this was discussed both within the uh badging task force which is mainly me and Tracy but I think occasionally I think David also joined uh David and uh but this was also discussed in the in TAC meetings and I think everybody agreed that we did not need to u u u add more burden for to both the TAC and for uh and to the maintainers to uh determine what badges should be uh awarded to a given project and uh then figure out if uh if the badge if they if the project meets still continues to meet the criteria for a given badge. So what we have was deemed to be adequate. Thank you. It would be nice if the hyro team comes back and um recommends few things. For example, um we could always look forward to having us having multiple workshop throughout the year or having new contributor on board it through the year or we can have sessions on purely hands-on sessions on like this is this is how you would build a project or this is how you would use in these cases or here are the showcase projects built on top of and things like that, right? Um and within the community maybe the project DSC can set certain um additional [clears throat] aspirational um goals such as hey last year we did maybe five or six activities. Let us challenge oursel and set to complete maybe 10 activities this year. Uh but but beyond that if project team is looking for something more challenging and aspir as aspirational um if it would be nice if you can bucket that or packet it and and present it. Um I do see questions on two other project reports as well. I know I I remember seeing Rafael on this meeting. Hey Rafael, um would you like to talk about your asks from Captain Report? Uh hello folks. Yes. Um so we we had a pretty good quarter in my opinion. uh the uh we still need to incorporate the feedback from the tag which we're going to do soon. We had uh two asks. One of them is to help us with the project marketing. So we are preparing a couple blog posts and would appreciate the foundation's help on disseminating those. The idea is to increase the maintainers diversity because we have maintainers concentrated in the same organizations. We have three or different organizations but only one maintainer from one of them and two maintainers for from two different organizations. So three organizations total. And secondly to ask if the foundation can provide some tokens u as there are some maintainers who are um independent without the company sponsoring their work to auxiliate on on some of the project maintenance tasks. Any comments from TA on this? On the second one, um I think that's more of a question to to LFT tag. Sorry, not LFTD tag. My bad. LFT staff. Um so I'm I'm not sure if Danielle or David if you have any topic or anything to say about it. I would just say Rafael, if you want to ping me on Discord, we can have a conversation about what's possible. >> All right. Uh, fair enough. We also applied to a couple um programs from different organizations that support open source projects, but we are mindful that sometimes takes a while. Uh, but in any case, if it's accepted, we won't need direct support from the foundation. uh but it would be good to to have some support in case those efforts are not realized. Thanks David. >> Hi. Yeah, thanks thanks for joining. Thanks for um coming to talk about the your kind of um your asks. I guess I'm interested in the fact that you you've got an LFDT mentorship program running. Um, I I guess I'm interested in how that's how that's kind of been going and whether there's what you see as the potential for mentees through the the mentorship program becoming contributors longer term. >> Sorry, I I didn't get that's a question for me, right? >> Yeah. Yeah. Sorry. Sorry, Raphael. Yeah. Um, uh, yeah, I I wondered in terms of finding new maintainers. Um, have you have you found that the LFDT mentorship project I think I think you're saying in the in here that you've you've got an LFDT mentorship project going. Um, have you found that the mentee you're working with has has kind of engaged a lot with the project and is that a possible route to gaining um new contributors? >> Yes. Yeah. Thank you for the question. That that's a good question because it ties on directly on this investment that the foundation makes on new contributors besides the besides the financial support also of course a lot of time support from the maintainers on those mentees. So the I I'd say that yes it is possible for contributor for for from for mentees to become contributors and to become maintainers but that's on the spawn of many years typically I myself was a a mentee for this program several years ago then I I was already a contributor at the time um or doing very minor contributions after the program explain expanded the scope and eventually I became maintainer. We also have a maintainer Carlo from Portugal which had you know similar um similar route was a menty contributor then maintainer but these efforts are typically um they take a long time right so it takes a lot of time investment from everyone around those people not everyone become contributors not everyone become maintainers of course and I'd say it's close to impossible from a mentee to become a maintainer you know over the course of a year >> yeah I I can understand that in a short space of time for the duration of the mentorship program that that's not possible um I guess I'm wondering if you think that in this particular case with the mentee or or through the mentorship program in general there there are ways to engage that mentee beyond just the year of the program. Do you think that tends to happen or do you think the mentorship programs tend to be quite short-lived and then mentees move on to other things? >> That that's that's that's a good question. Um from my from my experience and our experience in cacti uh mentees contribute well. Of course there are different degrees of participation. We had mentees which were not very um proactive, not very connected to the to the project and on the other hand menties were extremely connected to the project and did a great job >> and they kept contributing for several months afterwards >> and you know eventually the contribution uh rate starts diminishing and probably they move to other things. We like to think that we provided the foundations for them to contribute to open source and to other Linux foundation projects. We have limited evidence because we don't do formal questioners to our to our ex menties. But I know for a fact that one of our first mentees, Sara, she became a professor in a Canadian university and she kept doing crosschain research using cacti. So more directly or more indirectly the mentes keep contributing to to the ecosystem and to the broader society in general via technological development. >> That that's really that's really interesting to hear and I think that's really positive uh you know it's a really good positive example of that. Um I know in Paladin we have our first mentorship program this year and I'm very interested in in seeing how that pans out for us. Um um Ram I think you've got your hand up. I'll I'll let you chip in. >> Uh yeah I think Rafael covered uh most of the thing I want to talk about. We have had mixed experiences with mentees over the past few years. Um uh great examples are Rafael and and Carlos who uh were contributors uh became official mentees and then official maintainers. uh so they are prime examples of the kind of mentees we want to uh see. So this year I think um we have a somebody who's a um third year student like a junior I think in university. So I'm not sure if like he'll go on to become a committed maintainer. Um but yeah uh his uh experience with him so far has been good. uh what we the other avenue we have and so uh Rafael and I are also part of a uh standards group under the ITF where we are working out uh specifications for u uh interoperability specifically asset transfer at this point and uh through that uh through through that organization we uh we are hoping to get some um attract more attention to the cacti project uh because which is the uh flagship uh implementation of of the standard so far. Um and uh yeah that that's another way we we trying to attract more uh maintainers but yeah mentorships are definitely one way we have uh we brought in extra uh additional maintainers uh in the past. Okay. Uh moving back, I know AO project also has submitted report and they have a couple of questions as well mostly in terms of increasing participation and requesting how they can involve more maintainers. I mean how how they can get more contributors so eventually they get more maintainers and um we'll we'll bring that topic back again for the project I and I I know like being cognizant of time I want to give opportunity to m Matthew I know like previously also you brought up this topic I know this is not on the agenda but I'm I'm okay if you want to bring up the topic of Ethereum encore maintainers all happening at the same time that thanks Arin yeah sorry I should have proposed it for the agenda before the meeting um but it's it's kind of a small item but it might have longer running discussion which could be for for the next meeting the um the the kind of question I wanted to raise was the fact that quite routinely the TAC calls clash with the Ethereum all core devs call. So right now that's happening the the all core devs call is happening. Um and obviously it's it's kind of an Ethereum only uh or an Ethereum ccentric call the all core devs call but probably for quite a large number of people on the TC there's there's probably some interest in what is the main gathering together of um Ethereum developers across all the the Ethereum clients researchers and so on. Um, and I know scheduling is is a was a really really difficult like um thing to to solve. Um, but I did just want to raise the fact that um it there two quite important calls for a lot of people, the TAC and the the old college school. And I wondered if there was any appetite for shifting the TAC call um maybe just by an hour e either way um in order to mean that um members of the TAC can attend most of the core call. The core calls are scheduled for 90 minutes in fact but I think I think attending [snorts] the first hour of that would be sufficient whereas currently you can only drop in for the last 30 minutes of a 90-minute call. So, that was that was one to raise. Um interested in any people's kind of initial thoughts, but I'm also happy if it's if it's something people mull over and we discuss in more detail next week. >> I'm I'm fine [clears throat] if we move this to 8 8 a.m. Pacific Standard Time, whatever that is, UTC. I don't know what it cuz I'm on this I'm on the West Coast. Um I don't know what that does to other people's time zones. Um but I would be fine with that. Ju >> just for my benefit. Dan, is that an hour later for you or an hour earlier? [laughter] >> An hour later. >> An hour later. Okay. Yeah. I mean, that's certainly suitable for UK time. I think it we're we're normally a 3 p.m. UK uh start time and 4 p.m. UK start time would would almost always be fine, but then I don't know how that affects people further further east than Europe or the UK. >> Rama, this will maybe impact you the most. Uh yeah, earlier doesn't work because I have conflicts. So I'm fine moving it later by tomorrow. >> Can staff accommodate that? >> This is up to the TAC to decide when these meetings are. So if you want to move the meetings an hour later, that's an easy thing for us to change. Um, you know, just this is one of the rare calls where we do have quorum. So, if you wanted to do that call, make a motion to move in an hourly blah blah blah blah, feel free and I will accommodate the wishes of the TAC. >> I feel like it maybe it's good to give people a little more time than [clears throat] springing a vote on them now. So perhaps if I put a something into the Discord channel and suggest that I propose a vote on that next week >> or you could uh do it as an issue right in the governance. >> True. >> And then have the TAC members review and vote on it. >> Yeah, I'm happy to do that. Right. That makes sense. Um I I will do that. um and um put a put a post in the uh discord channel so um we can either get corum [snorts] on that vote offline or we can maybe have one last discussion and maybe approve it next week. Thanks everyone for it sounds like people are re relatively happy to try and accommodate that. So if it works out then I do appreciate that. I think others will also benefit from the corev course being something that they're able to join if they if they want to. That sounds like a good plan. Um yeah, let's raise an issue and let's also bring it up on Discord and remind people to talk issue. We'll have to check with maybe yeah we'll we'll we'll we'll look into the voting on GitHub issues. Thank thanks for bringing that topic Matthew. Um moving to the next topic. Let's move to the discussion items for the day. U Ra also saw you. >> Yeah. I'm going to let Hart take my slot. So I mean basically this is it. If you click the new issue button here, uh then you have the ability to do a lab proposal. It goes in here. It it asks for a lot of the information that we need. And the goal would be to collect a lot of this upfront so that we don't have so much back and forth on staff so that we are able to get labs uh up and running much more easily. So that's that's it. I just ask that everyone take a look and I seed the rest of my time to heart because he has something much more important to talk about. >> Um, awesome. Can everybody hear me? >> Yes. >> Great. So, I have some uh sort of less than fun stuff to talk about, but you know uh stuff we have to do. So, how many people are familiar with the CRA on the TAC? I'll happily say I'm not particularly familiar. >> Okay. So, this is a a long presentation. Um but uh but basically, you know, next month we have to start becoming compliant with the CRA for projects in Europe. And I'm going to post sort of a simple onepage thing in chat that has some other links that that you can basically uh see, right? Um but basically since we are an open-source uh well sub foundation and and we have open-source projects uh that are used commercially. Um there are some requirements we have under the new EU regulations uh with respect to the the CRA. Now I would encourage everyone to read through this. Um you know Marcus is is everything okay? >> I think that's great. Um so if you're really curious we have a free training course that I've just put in chat uh where you can you can understand this. Um so uh you know definitely encourage folks to look at this. Um I will say in a nutshell uh if you already have a uh good security vulnerability disclosure process and everything is already configured like that that's great news. You have very little work to do under the the CRA. Um however if you do not have these uh you have a problem. Now, luckily, I think pretty much all of our projects and all of our projects, graduated projects do have this. Um, so there isn't necessarily a ton of work. Uh but um the big sort of difference here is that if we look at item number six on these top 10 things to consider um we will need to report uh vulnerabilities um to Ana and uh you know I I would say that is kind of the the main change for projects that already have um a solid security vulnerability disclosure process. Um so I'm not going to be able to go through all of this in 15 minutes. Um so I'd encourage you know everyone on the TAC to to take a look. I'm happy to answer questions offline or next weekend. Uh, and if you have really complicated questions for us, we can take them to our legal folks who have spent, as you might expect, a uh a tremendous amount of time on this. Um, so before I go any further, are there any questions? Matt. >> Hey, thanks. Uh yeah, thanks for the overview. Um I now know a bit more about CRA. [laughter] Um I I guess I'm interested particularly in in that that that one that you've highlighted and and the word the wording around be prepared to report vulnerabilities. Is this like a direction to have everyone report in that using that mechanism or that in certain cases you will and in most other cases you just use your existing mechanism? >> Uh so this is more of like a downstream thing. So people are going to report report vulnerabilities to you and then you're going to have to report them to the EU single reporting platform. >> Okay. So it's kind of part of your disclosure process potentially to redisclose through that process. >> Exactly. Yeah. >> Okay. >> So this is just Europe basically saying that uh you know um hey you know also report to us right? >> Yeah. Again, if you're following the OpenSSF best practices already, then you know there's not as much to do. >> Yeah. Okay. Thanks. Yeah, I think I probably need to read this in a bit more detail. That that's really useful. Thanks. >> I would encourage everyone uh in the TAC to to read this. Um, if you are if you work for a company or have a business presence in Europe, uh, there are additional requirements you face that go beyond the open source project. Uh, you may be what's called a manufacturer uh, under the CRA and you should also examine those requirements. Um you don't need to deal with those as a part of your uh your LF. [clears throat] Um so Matt from Cosmos has a question. Um which projects are in scope? Uh so for open-source projects and open source foundations uh it's typically projects which have commercial use. Um, so as far as I can tell, that's all of our graduated projects, probably all of our incubated projects. Um, as far as the the business in Europe, this is uh this is more of the the manufacturer definition and I would look at some of this uh longer documentation or uh take the training course. Here's a more full here's a well this is a steward's playbook. This is a little bit uh larger. Um but um yeah, I'm not going to go over most of the the stuff that you have to do as a company. Um but if you use an open-source project uh in your software or really if you have any software, you're you're also uh bound by the CRA. So, at least if you have business in Europe, >> makes sense. Thank you. >> Yeah, definitely check this out and and follow this. This is a big thing in Europe. And yeah, we're we're kind of only focused on the um on the open source angle of this here. Um but but there are this this is a very broad ranging uh broad-ranging role. So um also in summary um I would say what do if you if you want to know what do I need to do now? Uh make sure your security reporting your security vulnerability reporting process is uh current is well documented um and uh and it's it's easy to find online. Does this make sense for everyone? Can people hear me? Arun. >> Yes. Um, so, uh, can you can you briefly talk to us like what does it mean for open source projects if organizations producing software are treated as manufacturers? >> Sorry, say that again. >> Um, like what does it mean for open-source projects? Like I I remember you mentioning about like organizations that produce software are treated as manufacturers. So h how does that >> so that's sorry that's not quite correct. So organizations that sell software are manufacturers. >> I see. Okay. >> So the the open-source foundation in development will need to be stewards in some cases. Um, but manufacturers are those that commercially sell software. >> Makes sense. >> So, if you're not selling software, you're a you're not a manufacturer. And yes, the TLDDR is get your security vulnerability disclosure stuff in place uh if you haven't already. I know most the projects of most folks here already have this. Um but uh but check on that and we'll be checking as well and and sending mails. Um that's the Yes, that that's that's sort of the um the big Matt. >> Hey. Yeah, thanks. I just I guess on that point, do you think there's a need for the TC to to be incorporating any additional checks in its annual reviews of projects in this space? I know we already check for openness of scorecards and things, but we kind of also have different levels of requirement for incubating versus graduated and so on. Is is there a likelihood here that we need to be performing additional checks, more scrutiny of the disclosure practices and so on? Yeah, that's a great question. Um, I think probably, however, I think this is also going to get rolled into the OpenSSF requirements. >> Okay. >> Um, so I'm not So, we will have to check this one way or the other. Uh the question is whether or not we will actually have to change our uh our policies because it's entirely possible the open SSF will just require this. >> Okay. So it might be that requiring the current SS open SSF levels meets the requirement because the the open SSF levels incorporate needing to have these things done. >> Cool. >> That's right. And I don't know exactly what the the current status of that is, but um >> yeah, thanks. That's useful. Cheers. >> But yeah, and I would encourage everyone here to go like go read through some of these materials. Uh you can take the course. Um this is a a more complicated topic. Um, and I would suggest, you know, we come back next week and and discuss it more as well. >> Kind of we kind of sprung this on you. So, >> but yeah, I would be curious uh what you know I know many folks's companies do business in Europe. So, I would be curious to know uh you know as as you all go back and and communicate with folks um what their thoughts on the the CRA are as well. Does anybody else have questions in the the two minutes we have? I'll say please feel free to reach out on this um if you do have questions and and otherwise we can talk next week. any anything else? Arun, do you want to take back over? >> Uh, thank thanks for that. Um, yes, we'll bring it up again and we'll also maybe ask all other community members to participate and and [clears throat] see if they have any questions. We'll bring those to you in upcoming sessions. With that um we wrap up today's session. I mean today's call. Thank you everyone for joining. >> Thank you Arun. Thank you TAC. >> Thank you. Bye.