 action. All right, great. Thanks everybody for joining another episode of the OpenJS Foundation's cross-project council meeting today is the 7th of July. And yeah, let's get the party started. Do we have any announcements to share? Anything to talk about? Just a couple. Obviously today is our late day for meetings. But next Tuesday, I wanted to make sure everybody had in their calendar. In addition to our standards meeting at 2 p.m. Eastern and our CBC meeting at noon Eastern, we're going to have a last collab summit planning meeting at one Eastern. And that the goal there is just to go through and do a retrospective of the collab summit. Thank you all so much for the work and the support for that event. And we want to just go through that. So if you have feedback on the collab summit in particular, I would love for you to come to that meeting following the CBC meeting. And as a reminder, there's been a small survey going around about that. So any feedback you have is warmly welcomed either on the summit or on the OpenJS world. So that's sort of the big deal. We've also got the Node Security Working Group doing their AMA tomorrow. So if you have any questions or if you want to help support and promote that AMA, please let us know. That's going to be tomorrow at 9 a.m. PST, I believe. Right, Rachel? You got it. Awesome. Great. Just a quick announcement. So past few weeks, past month or so, the website redesign team was trying to move their bi-weekly meetings to weekly meetings. We have officially done that. We have gone from 12 p.m. to 2 p.m. now every week on Thursdays. So that is a new thing. It's been two weeks since we have started. Attendance has been a little low just because it's a new time change. So people may still get used to it. And also we had OpenJS World and things like that. So we did not have some meetings in the middle, but this is good and a new big step for us just to get things rolling and in the right direction. Great. Thanks, Debbie. Cool. Anything else? Anything from the board? Anybody? I don't have anything, any updates from the board. Although there is one topic, we're talking a little bit later about in terms of like the updating the CLA to the Apache style licenses. And the next meeting is I believe not next week, but the week after. Let me just double check. So if there is something coming up, yeah, it's the week of the 24th. Just let me know that you want me to bring up. Great. Great. Week of the 24th. Okay, cool. I'm trying to get the board seat stuff done, but I don't know if that needs board approval. I can't remember, but anyway, we'll get into that in a few, I suppose. Yeah, and we don't have to necessarily wait for that if it does. So yeah, cool. All right. Anything else from anybody? If not, we will jump into the agenda. Based on Toby's request to put the CLA conversation at the end, or at least second half, I moved it to the end. So the first thing in the Google Doc is the added membership program. This is a poll request that Sarah opened and we've got some commentary on here or comments. Sarah, do you want to get us up to speed and let us know where we're at? Yeah, so the two big outstanding pieces of feedback are the name. I think it's a good thing to brainstorm. There's a loaded term where it comes to membership that it might be a legal membership. People have suggested the term supporters, which sounds great for me. I don't know if anyone that is better at marketing can come up with something a little more catchy. But I think that's the big outstanding thing. Additionally, there's also some feedback on closing, on making sure that the newsletter continues to be made available for free to all project contributors. To me, that made sense. So that's the other outstanding issue. Also, this is my first time going through one of these. So some advisement on how to get these things through the phases would be awesome. So that's a request. Great. Yeah, sure. We're happy to help through there. And our welcomes, too. I wasn't here last week. So you're a new member, right, Sarah? So welcome. Awesome. Thank you. Is that true? Yeah, I think so. Thank you. Yeah. Happy to be here. And then who else was recently added? Was it Divi? You're the new member as well, right? Yeah, I got added last week. Cheers. Thank you. Sarah, if I could, one question I had on the individual membership. I noticed the membership fee became a part of the proposal. And I was wondering if maybe this is in the right place to talk about it, but there may be some tooling considerations there in terms of actually collecting the fee that we might want to maybe work through some of the infrastructure discussions. Because in the past, that has been a question. So maybe we shouldn't take up the time now, but I'd be interested in discussing that with you. Yeah, that sounds great. Your concern is not about how much it is. Just can we collect the fee at all? Right. That's exactly it. So it kind of doesn't matter the amount. It's more the logistics on the back end of making sure it all works. And since my job is to make sure all the logistics work on the back end, we should probably figure out just kind of how things would work. That makes sense. Would it make sense to make some time with you to talk constraints and kind of what needs to be considered? Okay. Absolutely. Anybody else interested in being a part of that? I'm interested. I could. I would be definitely interested. They all send out an email. I assume it would just be something like a come to a website page and put it in a credit card, right? In theory, yes. Well, I mean, in practice, that's what it would be. But the supporting wiring to make that work is kind of the question. Yeah, I understand that's not that may be more complicated. We don't do any of that anywhere in the Linux Foundation already. Or there are some projects which do have individual participant programs. I don't know. I'd have to ask around and see if they're actually charging. We do have the ability to do credit card-based transactions and things like that. We certainly use it for other things. But I think it would maybe just be worth going through and figuring out how it will all be wired together. Yeah. Great. And so in terms of next steps for this, because this is stage zero, is this something we can land and then maybe capture open questions and move to stage one and kind of go along the process? That makes sense. It's a good way to learn how to do that in the doc. What is it like to work with on that? That's a good question. I would hope that it's documented, but I think probably somebody could kind of help us work through that in the PR or something. I mean, have you read through the proposal process? Because I think that's the doc. Great. I'm not sure there's too much more. It's kind of like at each stage, like the moving from one stage to the other, it's really just a rename. Unless there's some questions that have been answered or changed, it's kind of renamed the stage level that's in the doc and move it from one directory to another. Okay, sounds good. Yeah. And you may be able to look at previous proposals that may be in process. In fact, I just clicked to the collaboration network proposal, Michael, and I got a 404 on the README. That's probably because of the rename or something like that. Yeah. But anyway, what I was going to say, Sarah, is that if you look at some of the previous ones, there might be some prior artwork in terms of like capturing questions and just sort of moving through the process. Yeah. I'll just plant the seed too, that we may want to revisit that. There's a lot of document renaming and moving. And like at least on the collaboration network, when people were like, oh, I don't even have to look at it until a later phase. And it's like, that's frustrating, I think, to go through a number of phases and be pushing all these things. And then people are like, oh, I haven't even looked at it yet. So I'm almost thinking like it was great when we had contentious things. But like for like, we don't necessarily need four phases, like we could probably have one phase where the CPC agrees on it. And then the next phase where the board has said, yes, if it needs to review, and that's it for most cases. Yeah. Yeah. Otherwise, like, you know, by our current rules, it has to wait like two weeks in between, and we usually stretch that out. Anyway. Yeah, I wonder if we should make an issue just to review open proposals and their status and the proposal process itself, and maybe have an ad hoc meeting to kind of. I think I can open an issue to just review the proposal process. Yeah, that'd be great. And yeah, if you do run into something, just you can ping me. I'm pushing that one through. So I can point you to the few things that you might need to change. I think on this one, sorry, go ahead. No, no, I was just saying thanks. Okay. On this one, I think that like the one around whether the newsletter is worth maybe a little bit more discussion here. And like, I think the concern was not only to project members, but just publicly at all. And so I wonder what like the foundation marketing people think on that front, like, is that something they see as a vehicle to get out to a broader audience? Or would it be okay if it's a you had to pay and become a supporter to actually get it? I mean, I would like to weigh in as the author of that weekly newsletter. And you know, I think really overall, the readership is not too great. You know, it's about 100, I think subscribers. And I think people find value in that, but not obviously so much that we've hit some kind of, you know, exponential growth in terms of people subscribing to it. So I think the proposal to, you know, leave it, leave the subscription settings for the people who have already subscribed. But then to make it a perk of of support or ship is a really good one. And, you know, I'm a proponent of it. I think it is a value add for people who do care and are committed. So it makes it made sense to me. But that's my two cents. And that like I, you know, if that sways me in terms of like, if you're a proponent, I think that's a great idea that I'm happy as well. I was just concerned that maybe we were going to like exclude some people we wanted to get the message out to. So sounds like that's not the case. Yeah, we have more broader based communications. We have a an email list of what 28,000 from folks who have registered for our activities. And Rachel does a great job in a very sparing way of making sure that the broader community is updated on broader foundation things. But again, the Jory newsletter is pretty special. So I wonder if it needs to be something that's actually a perk or just something we just do. Yeah, because like, I do think it's really useful, but I can't see someone going out there saying, I want to join the foundation. So I get the newsletter as a member, right? But like, it's just something nice that we do. You know what I mean? I guess that's my perspective. Yeah, I hate to limit the audience that can receive our news, you know. So Dylan, I could have interpreted that two ways. One, which is, yeah, we can give it just to the supporters, but it's kind of a nice thing as opposed to promoting it as a perk. And the flip side could be, no, we should actually just do it and make it available to everybody. I could argue for either case, but I just don't think that like, I guess my perspective is most people that want to become an individual members do it because they want to help the foundation or the projects that are involved. And like, the perks are nice. But like, if I was looking at it as a developer and I was like, oh, I get a newsletter, I might not care or I might actually see that as a negative, like, great, I have to read something every week. You know what I mean? Like, until you receive the net newsletter from Jordan, you're like, oh, that was really nice and sweet and useful. It doesn't like sell on its own. So why, why list it as a big perk kind of thing? You know, I think it's just like, I don't know if that makes sense. But like, why would someone care to join as a supporter or a member? Well, to like, be part of it to help us out to give us some cool stuff. But they're not doing it because they get these 10 things and they care about all 10 of those things. So I guess just try to keep it simple. It's my perspective. I think this is maybe an opportunity to talk to some folks that might become users, like potential members, right? Or maybe some folks that are members or supporters of other OSS foundations to see, to ask them why. I don't know if there's ever been, I don't know, there may be existing research here of talking to people about why they would want to become members or supporters of the OpenJS Foundation. I think it would be interesting to learn the motivators. I think the reason we've been talking about the newsletter this way is having exclusive access. Dory puts a lot of work into it and as and it's a great newsletter and adding a letter level of exclusivity with a really low price point is can be used as a way to motivate folks to sign up both to the newsletter itself, which right now is signed up. You sign up if you find the link. So both some exposure for the newsletter itself and for the for the supporter program or membership program, that being said, it might be possible that that's not a motivator for folks and it's kind of hard to tell without speaking to some people that might be our ideal candidates for something like this. Have we ever looked into, into, you know, doing some research around this or talking to folks about what would motivate them to sign up for something like this? We definitely talked a lot about what might motivate people to join in the past. I don't, I can't remember if we ever went out and did an actual survey or anything like that. But I don't, I don't personally remember and I wasn't in all the discussions, but I don't personally remember us having done that and documented it anywhere necessarily. But there were, there were like, you know, what kind of things would get us to grow to a large, a large number. And you know, you've got some of them like the digital badge and stuff like that, but I also think that if we send out a survey that's going to end up skewing toward people who will take the time to fill out a survey, which I imagine will also be people who will be reading newsletters. So, you know, yeah, good point. Yeah. I mean, I think we could just list it if it's, if it's going to be exclusive, you could just say, you know, the things you get are blah, blah, blah, we, you know, it doesn't have to be billed as why you would join. It doesn't have to be like things you only get as a member either, like the newsletter. I mean, I personally think there's we're an open foundation, you know, on open ideals. So we don't want it to sort of come across as like there's tears of openness and closeness. And so I would prefer that everyone that's interested in Jory's message be able to get it. But I also understand you want to have some stuff that, you know, is tangible. So I could argue it either way, just I don't know I would make a huge deal out of like the newsletter being a perk on its own. And like, and then if you try to make it bigger, like, you know, you get more exclusive access to the teams, then it's like, well, wait, we're open projects. So are we really trying to like create a barrier to like our openness as a foundation, right? So just kind of, I guess it just I don't know how to reconcile that, but that's just sort of what goes through my head. Yeah, well, let's maybe capture these things in the proposal and we can discuss them further in a new PR that's moving to the next stage, I guess, as the open questions. And, you know, perhaps we need to have a session on some of these things to wrap it up. Yeah. Cool. One aspect of this proposal that I think we could cover in this one is, is deciding on renaming it from a membership to a supporter program. I'm in favor of that. Anybody have concerns? No, that sounds good. I like your questions, Toby, too, that maybe they should be made clear in the proposal as well. What are the goals and what are we trying to attract? I know we've talked about that some, but making sure it's clear, I think, through the proposal might be good. But in the sake of time and agenda, we'll call that a wrap and move on to the next items. The next one on the list here is the continued CPC current board members. I think Jory was saying that there was some discussion about this last week. Is anybody want to catch me up or the group up? I think it was an argument that this was a good idea and that we should just do this and, like, this was a no-brainer and we should just do it. Okay. But then I believe Myles brought up the point that we may have to keep it open for two weeks per our governance process. Myles is not here, though, to confirm. Okay. And was that just like this issue or just the, because I don't think there's an update. This is just an issue. I don't know if there's a pull request that's associated with it. I think the argument was that this is conceivable to be a governance change. Therefore, we should follow the procedures for that. So I think if we agree on, it's still sounding like a good idea, then we can call it done. Okay. And I don't mind leaving it open for two weeks. It's only a couple more days. So whatever, people are comfortable with this with me. But I think it makes sense to leave, you know, to move this in place. I don't know if there's an issue on this, but I will have some PR open hopefully tomorrow for the board stuff. And then we can kind of move forward on this. I apologize for my delay. Go ahead. Yeah. If I may just add something here, it would be great for issues like this, which are sort of straightforward. Everyone agrees. It's kind of obvious. It's the right thing to do. It's non-contentious that we could actually not have to have like a complex time-consuming process around them. I don't really know how to do that. But the fact that we're discussing process for something that's so obvious is kind of a problem, I feel. I would agree with that. And I would see that. Do have fast tracking. This is already a thing that we do. The particular thing here is that this can be conceived to be a governance change. And therefore, that cannot be fast tracked. Right, exactly. Yeah, but it's not even a change. I mean, it is in theory, but we can just like say, we agree, let's move on and try to just get the other stuff in place. I think, Miles, the only point was that if we were to land something, the requirements would be that it would be open for two weeks so people could notice and comment. Yeah, and I don't know that we need to actually discuss or do anything just given people enough time to say, wait a second. We can even leave this open until we get the new seats in place, you know, people elected and everything. I don't care if it doesn't matter. Anyway. I don't talk more than we needed to. All right, cool. We'll just, we kind of agree. Feel free to object in the issue. I will try to leave the issue open until we get everything in place and that's all good. Moving on. Incubation process clarification. This is issue 567. Oh, it looks like I opened this 21 days ago. Did I write all this? I don't even remember this. Does somebody else want to get some context going here? 21 days feels like so long. Yeah, sure. I can give some context. This is a follow up on the fact that moving amp and electron through the approval process had some last minute hiccups and some lack of clarity around what the process was here of approving an incubated project and moving it to a full, to fully on board it to the foundation, given that there were already a vote for the charter and there was also the question was, was there another vote that was necessary and can we sort of like organize this, make it clear so there were no like last minute surprises. I think that was the goal of that issue. Yeah, I think it was basically let's revisit what we've got and improve or change, tweak whatever. Yeah, and I essentially agree with Emilee's last comment, which I think is what I was saying in the description that the charter approval is explicit, but just having this final step of adding it to the list is a good kind of closure, I think. I don't want to make more process and all that other stuff, but it just seems to make sense to me. I think the next step is like a proposal or PR that changes governance to match something new, right? Yeah, and then we can discuss the actual details of implementation there if we want. All right, so I'm just going to say this needs PR too. I can probably draft something on if somebody else wants to. I would gladly take your offer to help. Thank you. And yeah, your proposal sounds good. Great. I think it sounds like a good way to proceed. Excellent. Thank you, Toby. I appreciate that. Next up is the moving security proposal to stage two, waiting on feedback. What's the status here? That one, basically we just need to get feedback from the projects that they're going to be comfortable with the new requirements it imposes. That's my take that we need to do that before we land it at the next stage. Great. So I think on that one, I posted a comment, although it's there is, so I don't know, Jory, do you want to send that out? Do you want me to send it out directly? What's the best way to get that feedback? We certainly have some lists to, we can send to all of the maintainers. I think it would be great to know where exactly you want to get that feedback beyond discussion in an email thread. I think in that issue would be ideal, right? Like it says here's what the requirements are going to be if people have concerns. Chami in there would be good. That sounds great. Great. So does that sound like you're going to send out an email? Okay. Excellent. All right. Initial draft of the community board seats. Is that closed, I think? That's merged. I went ahead and landed that because it looked like it had enough approvals, minimum time had passed and all that. Yep. Excellent. Thank you, Michael. Next up is the move the collaboration network to stage two. It looks like we're maybe waiting on some feedback from Miles based on some conversation. Michael, you and Miles were having an issue here on the field. Yeah. Well, in the issue, he posted some comments. I took me a little while, but I finally updated. So just waiting for him to come back on that to see if it addresses his concerns, questions, whatever. Great. Next up is the work in progress pull requests. Michael, for governance changes on the collaboration network. Yes. That's just waiting on the other one. Like basically we need to get the proposal through the process and then separately that those governance changes can be made once that's in place. Great. And then the next issue, you've already closed since we have PRs for the other Yeah, it seems like we had too many issues talking about the same thing. Great. Great. Great. Second director seat is the next issue. You know, this is something that I am going to work on. In terms of clarifying what these two seats will be moving forward. We've had some discussions and I have notes on all of that and have something started. So I should have a PR open this week. Definitely before next week's meeting, but hopefully as soon as possible since it is like governance changes and it'll take a little bit of time. Next is pull request 414 for ad foundation wide copyright guidance. This is my weekly thing that I say I will get to. Yeah. I feel you though. Don't roll. I'm on holidays right now, mind the ocean, so I am not going to be working on this now. But when I'm back, I will. All right. Great. Great. Excellent. Responsible security disclosures that has the PR to move to stage two currently waiting on input from projects. And then Toby, the last one on the list here is the CLA update in CLA to the Apache style. I CLA and CCLA. Yeah, thank you so much for bearing with me and moving that to the back. I appreciate it. No worries. No worries. What's the story here? So I think Brian brought them brought it up. So I think Brian should introduce it. And there's just something that I care about. And I mean, I'm the unnamed annoying person who brought this up. So it's just to be clear. This is there's nothing annoying about this. You know, Toby was glad that you brought this forward because it's it's uncovered a number of other folks who kind of feel the same way. A little bit of history here. So when we're talking about CLA's, JSF required CLA's for all of its projects. Node foundation prior to the merger did not. And our way of addressing that when we did the merger and constructed all the legal documents was to say a CLA will be approved by the board, which is there for projects to use or not as they see fit. So as when we set up the original CLA, it didn't basically inherited the text of the JSF CLA, which is effectively the text of the DCO with a few changes to it. And one of the the things that was brought up when amp was coming in, which also uncovered some discussions with other companies that other organizations were interested in this as well, is the idea that if you're going to use a custom CLA, you're effectively going to be exposing yourself to a fair amount of review by companies who want to participate and is creating a barrier. And the one of the ways to to get around this is to use much more common CLA text. The way it was described to me by an attorney was the principle of least astonishment. The idea being if you're going to use something like this, that it should be something that people recognize. One of the things that we have seen certainly on the Linux Foundation side has been that a lot of projects are adopting Apache style CLA's. Apache Software Foundation has an individual CLA and a corporate CLA. These are different from the Apache license. But these are fairly broadly used, fairly well understood. And most importantly, the legal counsel who should be reviewing anything that would get signed, they're all going to be familiar with this at this point. So the proposal was, let's take the existing CLA before too many projects get fully onboarded with it, replace it with one that is much more common and is going to be easier to pass through reviews when contributors want their company to sign it on their behalf. And let's just do that now. And it's one of these things where we don't really get a second shot at this. If we wait another year to make these changes, then there are going to be projects which are on the CLA tool, which their contributors are going to have to go back and get re-signed. So now is a really good time to bring this up, and it's a really good time to address this. Does that make sense? Yeah. And I think just to add to that, I think you'd mentioned that there may need to be some change anyway, right, for existing projects. Yeah. So any project which signed or what's using the existing JSF CLA is going to have to re-sign their CLA anyhow. Other contributors re-sign. The reason for that is that the organization that they signed the CLA with no longer exists. So this is a perfect time to be having this conversation because we're going to have to figure this out anyhow. My understanding from the issue, Brian, is also that the board is on board with this, sorry, sorry. And was asking the CPC for sort of like additional approval and or comments about this. And I would like to make a specific comment that's an extra ask on top of this. I don't know exactly what the, well, first of all, I 100% agree was all of what you said there. And I think making that move now makes more sense. And it also has an additional benefit, which is from my perspective, when we're handling open source projects like this, the goal is always to balance the IP of the project and make sure that we have a project that is clean to use, safe to use for people that want to use it. And safe for people that contribute to it to make sure that the contributions are going to be used in the proper way, etc. And balance this was having something that is contributor friendly and frictionless when people actually want to contribute to their project. So you want to have this balance between these two things. And the existing CLA from the foundation has the same kind of level of friction as the Apache CLA. But my understanding is from a legal perspective offers a lot less protection, notably doesn't really cover issues around patents that well. And so, from that perspective, it seems very valuable to move towards. I mean, not only is the principle of least astonishment, you know, better fulfilled was like an Apache CLA. I think it also protects the projects better without increasing the cost to actual contributors. So I think that's a pretty big benefit for the projects. So then that's the first thing I wanted to say. The second thing I wanted to bring up was the fact that there's something really interesting about the Apache CLA, which is that the individual CLA allows people to contribute IP that is theirs, or that they have received authorization to contribute on behalf of, for example, their employer if the IP is actually their employers. And that leads a number of companies to essentially rely only on the individual contributor CLA for their own open source software. And so my ask would be that if we move towards there, allow projects to choose to choose whether they want just the ICLA of both the ICLA and the corporate CLA. Yeah, so that that was brought up in the recent legal meeting. We deferred that to further discussion. The first question is getting the CCLA and ICLA updated, but it is definitely so just, you know, to be totally open and transparent. It's something which is under discussion. And there are varying, varying viewpoints on this, but yeah, no, absolutely. I understand absolutely. My point, sorry to, I didn't mean to speak over you. I thought you were. Oh, no, that's fine. Yeah, no, my point was to suggest that, you know, if the, if the board was asking the CPC for their opinions on that topic, for, you know, for our opinion on the topic that the C, that's one of the things that the CPC should bring up as an opinion because it makes the process way easier in lots of cases and for certain projects. And I'm speaking here on behalf of AMP. For AMP, it is clearly a benefit not to, not to have to accept corporate CLAs because of the nature of the contributors to AMP. So my comment here is, if the board is asking for comment from the CPC, I would like the CPC to bring that up. And this has been a topic of conversation that has, they came up in the legal call. And then also, you know, Robin has mentioned this a few times in the board meetings, just in general, how our goal is to not throw barriers in front of contributors, right? So our goal is to eliminate barriers so that we, it's easier for contributors to be able to participate in the projects. So this is, these are all things which are being, you know, they're under consideration, they're under discussion. I will say CCLAs were really hard to manage compared to individual CLAs. In particular, individual CLAs, we were able to just create a bot and people could connect to their GitHub account and make that work versus corporate ones typically are signed. And then how do you connect the organization to the people who are approved by that organization? And that's almost always a manual process and a lot more work. But I do definitely agree with aligning with whatever language is going to cause the least amount of friction, just that I don't know that CCLAs work well for us. Yeah, I mean, that's the language is definitely step one. As far as CLA management goes, CCLAs and ICLAs, I mean, ultimately, it's not a decision that I can make. It's not a decision that really that probably any of us can make individually. It's something that, you know, it's all a level of comfort on the part of the legal council that represent the contributors and the projects and the foundation and everything else. But it is helpful to have these data points because then we can pass them back in and say, this is, you know, this is what people are thinking. Yeah, with Doja, we made everyone, even if they were covered under a CCLA, still sign the individual one. It was basically just they would know that their company was covering them by already having a CCL in place, but we still insisted that they individually sign it to make it easier for us. Yeah, and tooling has improved a bit recently. I mean, one of the things about so if you're taking, for example, if you do require a CCLA, the tool that we're using right now does allow for a company to say anybody in GitHub who's associated themselves with the org is automatically approved. They're on the automatic approved list. A company can also say, whoa, you know, we're going to be more traditional about this and say we want to approve individual people individually. And that's also an option. But, you know, the idea of having to go and get yourself manually added to a list, that's an option that the company can choose, but doesn't necessarily have to. So from a tooling perspective, I think we can, I wouldn't make the decision based solely upon tooling because that there are options out there. And yeah, I think, you know, this is, this is certainly getting kind of coming full circle back around to this issue. This issue is step one. And step one is basically working on the language. Step two is then, you know, what does the actual guidance to the projects look like? I will say that if a CCLA is enabled on the project, there's nothing in there that would say you can't sign an ICLA. It's more a question of, you know, this isn't really an open JS question at that point. This is a, is your employer comfortable with you signing an ICLA question, which is between between you and your employer, not between you and the project. So I think there are some other things here that we can also, you know, consider as we go forward. But, you know, for now, let just kind of focusing on the project in hand. I think at this, sorry, if I just may, I mean, I think I agree with like everything that Brian just mentioned. I think though that if the request is what is the CPC thing about this, and that multiple members and multiple projects of, you know, actually are saying, well, CCLA have been tough for us to handle, and we don't like it from like an operational perspective. I think this is the message that the CPC should send back. That's all I'm saying. I don't think there's a lot of controversy even among our legal counsel. It's just great in time. So I just absolutely. Yeah. This is like for this specific issue. The request, you know, I think, you know, I put on my hat as the community representative and said, from, you know, the principle of least surprise, we should at least go out to the projects. And before we change something, there should be a, do you have any concerns with us switching to the Apache licenses? So I think we could probably handle the two things by sending out an email to all the projects that says like, do you have any concerns with us switching to the Apache from the current one? And two, you know, as a second step, we're discussing whether we allow, you know, ICLA alone. What's your perspective on that, right? And that would give us the answer to the first one. So we could go ahead and change the change to the Apache, you know, if we get more approval, and to have the data for the discussion that's happening on the other side. So it was great. One important aspect of the previous, of asking the projects is, is there a cost here? Is there something that the Apache license that we do currently get from a project point of view or from a contributor point of view with the current text that we would not get with the Apache based text? All right, well, let's move the conversation to the issue. And then we can jump into private session. Is that fair? Yep. Time check. Great. All right, cool. Well, actually one quick thing we missed in the announcements, Fastify version three is out. So that's cool. Announcement, yay. Otherwise, let's call it a wrap and jump into private session. Sound good? Sounds good. Great. Thank you. I don't think we have too many people who are non-members, but if you are not a member, if you could drop off, that'd be great. And then we'll discuss some private business. We're still live on YouTube. Yeah. All right. Brian, can you do that for me? And then who, let's see, who's on the call who's not a member? Somebody's blank here. Maybe they dropped. I don't know.