 Okay, so I guess, we're on? All right, so welcome everybody to the corporate use of embedded Linux bot. I should give you maybe a little bit of background. Well first, let me introduce myself. I'm Tim Bird, I'm a Principal Software Engineer for Sony. And we were having a conversation actually between us and Bosch on a conference call a couple of weeks ago and talking about, oh it'd be nice to get together and talk with other companies and maybe they have the same issues and we can discuss ways we can collaborate maybe go into the future. So that's how the idea for this bot was born. And I see here, so this is the abstract and again I just like to toss the abstract on so people can know if they come and read the slides after the event what it's supposed to be about. So this is gonna be a very casual bot. I did not do the same level of preparation I would do for a normal talk. This is mostly intended just, I have some slides here but we don't need to follow these. It's intended to be kind of a discussion for people who maybe have the same problems or if you're not working for a big corporation maybe it'll give you an insight into some of the challenges that we face. And I would like this to be as interactive as possible to talk about things that we see in our companies. And even, so some of the issues that are listed here are things that Bosch and Sony have talked about that they have in common but there's also issues here that we don't have in common. So Sony is a consumer electronics company and we have some issues that have to do with that specific market segment. We also have a movie division and a music division and that presents its own problems. But so I'm just gonna go over some issues and then I don't wanna take too long on this cause I wanna leave some more time for discussion. So lack of upstream drivers. Is there anybody in the industry who's not affected by lack of upstream drivers? Maybe there are boards that you just buy the board and you, if you're doing a maker project you sell it anyway. Diversity between product lines, compliance services, license management and software bill of materials which is kind of the new thing that we're looking at. Supply chain headaches, automated testing and training. So those are some of the categories. Yeah. Oh, can we get a mic? Oh, okay. I work for a small company and these are this doesn't look very unusual. Well, there you go. See, so maybe I'm wrong. Maybe every small company has the exact same problem. So let me go into a little bit of detail on some of these and okay, so lack of upstream drivers. So a lot of times we have a business unit that will get a product or they'll get a chip, right? They'll source a chip from somewhere and it comes with the Linux kernel and the product team thinks, oh, it's got the drivers already built in. Well, the drivers aren't upstream. So they're good for like one release and then they don't, the product teams, bless their hearts don't realize that they've got an issue with the next version of the product. They wanna up rev the kernel or they wanna do a firmware update and the driver's not upstream so they have this technical debt problem. So Mark is here from Qualcomm. I don't wanna pick on Qualcomm because this is not unique to them. But many years ago, 10 years ago, I was in the mobile division at Sony and we had a kernel that we released on one of our mobile phones that had 25,000 patches that were out of tree. Okay, that's a lot of technical debt and you try to move from that version of the kernel to the next version and it's like you just, there's just so much and you can't really, I'll talk about this a little bit later. You can't really, we tried at Sony to do what I call proxy upstreaming which is we put together a team to try to upstream some of the drivers on behalf of Qualcomm or on behalf of Google and you can't, it's so hard. It's really not practical and I know that people do it for individual drivers but when you have a whole stack, especially for a really complex SOC architecture and a whole bunch of it is out of upstream, I mean it just takes years and years and you don't have the expertise, you don't have, so doing stuff by proxy doesn't work that well. So this has been improving actually. So not Sony, Google has been putting pressure on SOC vendors to get more and more stuff upstream and Linaro has been doing a good job of getting, there's a lot of the Qualcomm code that we had issues with back then are actually now upstream but it's an ongoing issue. There's something called generic kernel image that Google is pushing in the industry. Most people see it as a good thing. There are some issues with it though which is you're reliant, I don't have time to kind of describe all the details of it but it's a push to use a binary image that you get from Google in your product. And the problem with that is we have had cases where in Japan where we failed some regulatory compliance testing and we did not have the capability to modify the kernel that would have gone against our agreement with the Google. And so it's like well how do you fix bugs if you're constrained to a kernel version? You know the great thing about open source is you can build everything from source. You have a problem, you go fix it. And GKI kind of backs off of that benefit. So that's just one of the issues. Now okay so I also need to say this by way of preference. This is gonna sound a little bit like a corporate pity party where we're all just complaining. It's like but the object of this is to kind of open up and let people kind of have a perspective and share stories. So I don't want all of this just to be like Sony's issues. So that we can actually think about ways we can possibly collaborate. And share things with each other that will help. So in my opinion companies are kind of too loose about accepting out of tree drivers. And this should be a procurement issue. So when a business unit goes to an external supplier and gets a chip part of the procurement process should be is there an upstream driver? Of course it comes with a driver but often that nuance is not in the contract that we want an upstream driver that's maintained. And it is very, very difficult. You'd like to say as part of the open source program office I'd like to say well let's make that a gating function for procurement and you can't do that because the divisions are just, yeah go ahead. Oh where's the mic? Yeah right here. Yeah we can just pass it around. I was just thinking when you can't announce a chip for instance though right? You can't start putting patches upstream until you actually have something that you're upstreaming for. So by that nature and the pipeline of getting stuff upstream it's gonna be very unlikely by the time you're gonna release a product that those drivers are upstream. Yes and no. I mean there are some things you can do ahead of time but you're right that there is and I have a whole talk I've given on what I call version gap which is why mobile phones that are shipping today are running kernels that are three years old and part of it is that exact problem is that it is a lot of work. It's very difficult to be upstreaming features for chips that have not been announced. I mean that's just a reality right? So there's a comment back there. Well yeah do that one and then Stephan you can. So one thing that we did, I'm from an associate vendor. Eight years back we took a step back and we realized just like how Tim was presenting we had a huge technical backlog on our older chips. So when we started with a new and associate architecture we changed the rules entirely. Rule number one when we are talking with the hardware architecture team we keep Linux in mind. What works, what doesn't work. There are exceptions that our hardware guys always come up with oh let's do this special thing of tying up display subsystem with ARM MPU. It looks beautiful on paper but CP fragment won't work. So stuff like that you have to work with the hardware architecture team and the second thing is when you're purchasing from IP vendors you speak upfront in the SOW contract with a monetary value attached to it. That they will support their IPs in upstream at time period and a maintenance contract. Then things start moving much better. Yeah I wanted to go in the same direction so I think it's for example I know there is this problem that actually both sides are working with something that has not been announced. So we have chips that are promised for the future that we're working on for some device. But having for example like in agreement that this whatever we get will get into upstream. And both sides agreeing on that would already help a lot because the problem is that as long it's just a vendor or kernel and it's never getting upstream. Not from our side, not from the vendor side. Then you're stuck. Because it's not about let's say the first three months or the next six months. It's about our devices need to be in the market for 15 years. And so it's not about these, of course it would be great. It would be in the upstream kernel from day one. But what we are worried about is much more in the next 15 years. There's another comment here. So we make controllers that are only built in like 20, 30,000 units a year. So our chip volumes, our product volumes are pretty small when dealing with these large vendors. And so it's hard to incentivize them to go do all this work if we're not buying that many chips from them. Yes, I'm well aware. So I work at Sony and we ship in the millions and we don't, well, we used to ship in the millions. Anyway, but even we don't have enough clout to like kind of push certain lovers on Google or the other, the SOC vendors. So yeah, I feel your pain. I haven't got a solution for that, but hopefully the, so what we really want to do is convince Samsung to do this, put, add this to their procurement and then we can kind of ride their hotels. So, you know, the SOC stuff will be upstream by the time we're using it. Another comment? Just to comment on your comment, you had said you'd like a guarantee of sorts that things are gonna get upstream, but you tell me how long it takes to get a driver upstream. So when Qualcomm introduced G-Link, for instance, is one of the new technologies in a chip, we could then, after we released the product, socialize it with a community and then talk about how we could get an upstream driver, right? This is a multi-year process to get this into the upstream and I couldn't give you a guarantee of how long it might take. If we have mobile SOC products, we also have chips that are not necessarily guaranteed for a long life. So if you have a two-year process to get a driver in the upstream and the chip only has, say, four-year support, the value proposition of some of that is not as good as a long life part. Yeah, I understand what you're talking about because we have to a certain extent the same problem, but the part of this problem is, if you don't have a team that is actually 100% for example, involved in the Linux kernel community. Because they could do a lot of preparation on patches beforehand. They could do basic development that is not hardware-specific, so it's not dangerous for enclosing any kind of IP that you don't want to be seen at that point in time. And they can also tell you exactly, normally, beforehand. This might be really dangerous or difficult, so maybe we need to go in different approach or anything like this. And, but of course, if you finally, when the hardware is out there, start to try to find someone who can do this, it takes years. If you do it the other way around, much faster. We have had that with several hardware things where we didn't have it in the upstream kernel. We hired an external company that had all that what I just discussed. It was within weeks upstream. Really depends on the feature, right? That you're trying to get up. I mean, there are drivers. Drivers are notoriously, well, it's easier to get a driver up than like a scheduler change, right? If you're talking about, you've got a new architecture for how you're doing sleep states or something, or asymmetric processors on the same chip. Okay, it could be 10, 15 years, right? I mean, the real-time patches just barely are getting there. It's been 17 years. Oh yeah, you can't make guarantees, but I think you can prepare things. That's what I was about. What I was gonna say is that Q-Link is something that you've invested in. You're gonna invest in for a long time. That's not a four-year thing. Drivers may be a four-year thing. So that example is not a very good one, I think. Right, so the framework lives on. The individual drivers may change, but the frameworks are what's hard. Yeah, frameworks are really hard to get upstream. Yeah, and also the, if you're hard where people are doing their job right, they should be making your software people's job easier by making things compatible. We have too many drivers. That's the other problem is we have too many drivers because people just reinvent hardware that you can buy, you can buy that it's built to do. At the risk of moving on, I'm gonna move on. Okay, so one more. Did you add the last word? Okay. One more little comment on it. It's biking out so much. And by the way, you say, oh, it's so big, so many problems. What do you think what we have? So if it's actually, then it's just offloading to the people that like a little bit lower down in the chain. So I totally get what you're saying, but actually normally it only, otherwise we have to face and solve all these things by ourselves. And it's becoming really hard, except in particular when you have different chips to take care of at the same time, because normally the vendor kernels are never just purely minimal invasive, exactly what you need. No, they bring a lot of tons of stuff with them that we don't need. And then we have to figure it out how to deal with all that. And so a lot of people inside Bosch get gray hair very fast. So I think you're actually talking about my next slide. Okay. Diversity between product lines. Okay, so I don't know what happens in a small company, but in a big company, I have lots of business units and actually lots of divisions within business units. And they often go out and get different kernels, vendor supplied kernels, and sometimes vendor supplied user spaces. A lot of times there's user components to like the drivers or something like that. And then they toss it over the wall to the headquarters Linux group, which is expected to maintain it. And I tried to get permission to show a chart of our internal, the set of stuff that our team is currently maintaining. And I didn't, I may have gotten it if I had asked earlier, but anyway, it was too late. I didn't get it in time to permission in time to show it, but it's just, it's a nightmare. We've got 14 different kernel versions. We've got user spaces that are using a whole bunch of different build systems. We've got Android, Yachto project, Debian based systems. We've got a couple of roll your own weird things in there. And maybe this is just, Sony not being very smart, but this is why we're here talking about this. Trying to have a group manage it. It's like we're designated the Linux experts. And so we end up being like the buck stops here on some of this stuff. Let's see. Oh, the other thing that happens is we have business units have this autonomy to use different backend services. And so their product upgrades are going through different cloud services. And there are also product, not just for update, but also for product related services. So like we have television sets that have channel guides on them that are network based and streaming and timekeeping and all this stuff. And Sony has had a couple of cases where we have discontinued an upstream service and our customers have not been happy. And we thought there was one product in particular. This is a long, long time ago. So hopefully I'm not airing dirty laundry, but long, long time ago we had a product that had some network elements to it. And we shut it down and it was, literally it was just the timekeeping service. But what happened was the entire product stopped functioning. And so we thought it was an innocuous. It's like, oh, they can continue to run the product, but it didn't turn out that way. So that type of thing happens. But the issue here is that when you have a huge variety of these user space stacks, you have different firmware, you have different security mechanisms in place for those. And a lot of those are per product line. So for instance, the television sets are locked down pretty hard because we're dealing with streaming content. And something like a camera doesn't have the same type of security on it. We don't expect that people will turn the, like our Alpha 7 line into a botnet, but they could do it with our TV sets if we're not careful. And so there's just kind of differences there that you have to account for. Again, I don't have any solutions. This is just me ranting. Let's see. Oh, okay. And this is a point that Stefan and Phillip brought up yesterday, was it yesterday or the, yeah, or Wednesday or, anyway, that it used to be for an embedded product, you develop the product, you sell it, and then you move your team onto the next product. So everybody's happy. But the new development model is that you develop a product, but you have to plan for long-term maintenance. Everybody expects, especially in consumer electronics products, there's an expectation that if new features, that there may be new features available. There may be additional things, like the TV sets now have application stores on them. Especially in the area of security, people, the expectation of the market is that security bugs are gonna get firmware updates. And so you can't just sell it and forget it and move your entire team onto the next thing. You have to plan ahead. And I thought the good point that they made is that you've got to move your resource allocations earlier in the development cycle to plan for that. And you actually have to plan for the maintenance phase of the product, and that could be very long. I think Bosch is saying that it's got 10 to 15 years. I've got a Sony TV that's, I think, eight years old. Luckily, I don't know the last time I updated it was, but every time I turn on my PS4, it does a console update. I don't know. Yeah, and actually there's one addition to it. Normally, you even have to build different systems. So even during the development phase, so before start of production, if you screwed it up at that time, it's very hard to get ahead of it later on. So that is one of the problems that we are seeing because the mentality of many of the embedded developers that we are seeing is still this old paradigm. And so if you don't do it right during the development phase, you will run into a lot of problems later on and the developers that originally built the system are no longer there. So you have to, already in the first phase, understand and prepare the long-term maintenance issues. Right, yeah. And you have to manage end-of-life. And there's compliance issues, right? You need to actually have the source code available for longer than the life of the product or, well, yes, anyway. There's some nuances there. So compliance services. Maybe this is just unique to Sony, but I think anybody who has multiple business units is going to deal with this. Hosting the source between divisions of business units. You have to have agreements between business units that the source is going to be delivered to your, so Sony actually has, I think, three major repositories. We have one for the mobile phone because they're kind of their own thing. But we also have kind of a main one for the electronics division. And we have agreements with the product teams that they have to submit the materials ahead of time and they have to be vetted. One of the things that I would love to see us kind of develop as an industry is kind of a standard for rebuild script. One of the things that comes up in compliance, if you've ever dealt with the SFC, and I'm not going to go on record about any relationships or issues we've had, but a complaint that comes up is that sometimes the source that's on your compliance website, there, people have a hard time building it. And I think it would be good to come up with kind of a standard for, well, how do you build this? Make sure that customers can build it so that they're happier with your compliance. And there are some issues here because a lot of the build systems are holistic, right? They will build the entire thing, including the proprietary components. And if you pull some of those out, there might not even be dependencies, but there are issues with being able to build just kind of part of the product, right? We're not gonna put the proprietary source code on our compliance website, but there are build issues that I don't think the industry has addressed at all, really. I mean, if you look at the Android open source build, it builds this full stack, but there's other things in there that can become an issue for someone trying to build this. You can't just put the Android components on your compliance website and everybody's gonna be happy. I'll just put it that way. Another issue is monitoring legal situations. Okay, and maybe this is, I don't think this is Sony specific because a bunch of people got hit by this stuff, but you gotta watch stuff going on in the industry, like Patrick McCarty case, and we are paying close attention to SFC versus Vizio. And there's, in your multinational company, you have a lot of legal jurisdictions that you have to deal with. German law in particular is quite different than US law when it comes to product warranty. And so you have to produce compliance materials that are acceptable in multiple jurisdictions. The Patrick McCarty case hinged on a couple of really weird kind of nuances of German law. So if you're not familiar with Patrick McCarty, he was a longstanding compliance enforcer. So from the standpoint of the community, a lot of people thought he was doing a good thing, trying to hold people's feet to the fire. And he may have been, there were certainly cases where he was trying to get compliance out of companies that were kind of being egregiously bad. But there are also well-known cases where he was trying to twist the knife with legal technicalities on companies that had released source code. And he had a way of structuring his legal attacks to basically, he was a copyright troll. So he had some copyrights in the kernel and he made at least six million euros with, by binding companies to agreements. And it was, I had to do with nuances of German law. So the news on this one, this is actually a little bit of a status update, is the net filter team did not like this at all. And it was kind of damaging their reputation. There were people talking about pulling the code out of the kernel to avoid this issue. Anyway, they actually came to a legal settlement with Patrick Cajardi in January to fix that. And so he can no longer bring suit. The reason I bring this up is, I assume for certain types of products, your customers are gonna either care more or less about getting the source code and your fulfillment of the technicalities of the law. And so one thing that I would just throw out there is it might be worthwhile for us to kind of share our experiences. You can't, and let me just tell you upfront, if you go to your legal team and tell them you wanna share your legal experiences with another company, they're gonna say no. They're just gonna say no. So there may be creative ways that we can direct people's attention. I will just say this. There are certain, okay, so German law also has this weird thing where the decisions are not publicly available. And so that if you're used to US law where everything's in public, that's a little bit different. And so sometimes knowing a case to go look at is a useful thing. There was a case that was decided about a year ago that went heavily in the favor of the vendors. And so that type of information might be useful to share that information in a kind of a generic whitewashed way, I don't know. The other thing, right, so Sony's a TV manufacturer. We're watching this case with SFC very closely. So if you're not familiar, the Software Freedom Conservancy has brought a case against Vizio, a TV manufacturer, saying that they have not fulfilled the GPL license. And I don't know enough about the details of what source was provided. There was source provided, by the way, so there's a kind of a misunderstanding in the community that Vizio never gave any source code. They did give some source code. But for various reasons, the SFC was not happy with it. They brought suit. Interesting issue isn't Vizio's compliance or non-compliance. The interesting issue is this issue that a third-party beneficiary to the license, not a copyright holder, can make a claim against a company. The gentleman here, we're talking about tractors. I doubt that your farmers are gonna bring GPL compliance lawsuits against a company, but for a company like Sony, it's a very, very serious thing to change the legal dynamics between us and our customers in terms of who can sue us. And so that's something we're watching very closely. So nothing's been decided yet, but the most recent news was that this was, Vizio tried to take it to federal court and it got remanded back to state court and some of the legal discussion there was pretty interesting. Okay, so again, that's, maybe no one else is affected by that, but there might be some things that we could share with each other to help us. And then encouraging contributions. So product developers are always on a treadmill, right? They're just, and a lot of times they don't have time to integrate with and contribute upstream. So let me just comment on, I think I commented on this already a little bit. So we often try to have a proxy team that pushes changes upstream, but it's a difficult thing. We've tried a couple of times at Sony and we've never been able to make it work that well. And so the idea has been suggested, it's like, okay, well you have your product team over here and they're going guns blazing, trying to get the product out the door. And then you have this other team that is really savvy at upstreaming stuff and the open source community and they'll take the stuff from the product team and upstream it. The problem is they're not the subject matter experts. So it's really hard for them to answer the deep technical questions that the community is gonna ask or, and they don't have the authority to go changing the architecture of stuff when the product is all the way out here. So there's some issues with this. I don't have an answer for this. It'd be nice to say, oh well, take some of your product engineers and make them up streamers. And it's like, but that's not what happens a lot. So, okay. Licenses and S-bombs. I wanna make sure we have enough time for, we only have what about 10 minutes left. So we're rolling S-bomb requirements out to our supply chain, but this is gonna take years, right? Because our suppliers are not doing this already and then they have suppliers and they have suppliers. Sometimes we're like three levels deep on the supply chain. So this is something I think that needs to be baked into your procurement so that you can put pressure on your suppliers to be creating software-gill materials. So, clueless suppliers. It sometimes happens that a supplier will fail to mention that they have included open source as part of their solution to you and you're probably thinking to yourselves, how could you not notice that? Well, let me tell you about white labeling. So some divisions will sometimes go out, find a product that is really neat and wanna push that into market under your brand and so they won't take too close a look. They won't even rebuild the software from source. And it's happened that you find out after you've marketed a product that it's got open source in it. This has not happened recently. I wanna make sure that people understand we worked really hard to try and avoid this but it does happen. The issue here, I think, is that you really should be doing build validation. Even if you're white-boxing a product, in your company, you really need to have people who are paying attention to this and saying, look, if any product goes out the door, whether it's white-boxed or not, needs to have like a compliant certification. They need to say, have you done your diligence on what is in this product? Can you rebuild what's in this product? And then you have the opposite problem, internal, glueless people. This is, when you have a large company, the number of things that can go wrong is pretty much infinite. And I'm not saying anything has happened here but this is the type of thing we worry about in the program office. B2B is out there selling AV suites for stadium boxes and we found out that they were just putting a bunch of Linux stuff together and it's like, well, okay. So it's really unlikely that a stadium owner is gonna call them on GPL compliance but they're pushing open source out into the market and they're not paying attention to the compliance issues at all. So if you take stock Debian, install it on a machine and ship that machine to a stadium box, do you have a responsibility to put Debian somewhere on your website, stock Debian? Can you get away with the binaries or do you have to actually now put the Debian build system on your compliance website? That's like, okay, that's a nightmare. And another thing that has come up is R&D agreements with academia. So Sony has a number of agreements where we contract with academics to produce software for us and sometimes the academics will produce stuff that's under an open source license but it's not one we can use in a product, right? So we've got this R&D and sometimes your R&D teams will do that also, this is an education issue, a training issue that you need to make sure that as you're doing R&D, you're not basing that R&D on open source components that you can't then put into a product later because of your own license policies. So I think a whole bunch of people in the commercial space have issues with using GPLv3 components on their products and so you need to watch and make sure you don't have dependencies, those dependencies in your software. Okay, and then there's all kinds of testing. So we're down to about, I have like more slides but I wanna stop and let that percolate for a little bit and see if anybody has any comments. I know this last part has been a little bit more firehosey than I hoped to do but anybody have comments on, what are the issues that you're seeing in your corporation that are giving you heartburn? Okay, so a couple people there, can you take that? Hi, so I work for a little R&D thing. We're trying to make cool stuff for people. We're kind of in startup mode. Not that I was particularly a fan of this but let's just say that we bought into a very popular educational turned commercial single board computing platform that's very, very popular in the market and we're realizing that, due to their age and their maturity, they're sort of supporting a lot of 32-bit stuff, that's sort of their general architecture and the software that they ship and only recently have they really sort of push towards 64-bit stuff and we're sort of in this position where it's like, we wanted to leverage this sort of big sort of buffet style thing where it's like, hey, there's this stuff, it's cheap, it's available, it's whatever but then we realize it's like, well, we actually have this really sort of narrow use case and so we're not gonna get that sort of special kind of attention that we need and so it's like sort of weighing, trying to weigh the balance between like, do we go with this thing that's available but that we would have to work on a lot or sort of get sort of a more customized solution from somebody that can interact with us a little bit more directly but it's gonna be more expensive. Good luck. That's what I was expecting. Yeah, I mean, I would have to know a lot more to give you any kind of reasonable advice there but that's an issue for everyone, right? No matter the size, right? Is how much to try and invest yourself and because you're taking on technical debt, it depends on, there's a number of factors that affect that decision. One of them is, is this a product line that you're gonna be doing multiple versions of over time and do you wanna build up the expertise yourself? You probably don't. Well, it depends on what it is, right? If it's a say it's a video related product, maybe you want the expertise in-house to be managing video drivers and developing new things. It depends on where your IP is relative to the open source IP. And so I can't give you a single answer that would work for every, go ahead. But maybe someone else can, maybe Mark can. No, I was just gonna highlight a couple other related issues to that is you should consider how long the SKU that you care about is gonna be available to you and can you get it in volume that you want in a timeframe that you want. So it's more than just like I can cobble together something, if you're gonna make it a product, you need that distribution as well. Yeah, those are good points. Couple other people. So I had a conversation with somebody about the semiconductor industry and a lot of semiconductor companies are less likely to open source right now because they can't make parts. So they're going for the customers who are more interested in proprietary or don't care about licensing. So I don't know how to address that in the semiconductor industry is like, okay. They have less motivation to open source it because they can't make in a product as it is. Well, and it does, I mean, money talks, right? So if the people who are asking for the boards are saying are making it a priority, if you can actually say, well, we prefer board X because it's got open source drivers, then loss of business is a strong motivator. But we rarely find ourselves in that situation, right? Usually the product teams are looking at features, not kind of these longer term strategic things. But I think we have time for two people in the back and half be our last because we're wrapping up here. Hi, so I have more of a comment really than a question. So GPLV3 has been a pain point for me for many years, many years now. So in 2019 in Leon, I asked this question and I was told, hey, it's very easy, just find replacements for all the things that are giving you issues. So that's exactly what we did. So we just found replacements for everything. So now I can sleep at night, but I don't believe that that is really a true solution to the issue. So I think eventually maybe alternatives will be found and people will just gravitate towards those alternatives. So yeah, just GPLV3, man, and that's... So just a comment. So the Apertis project which Bosch is working on actually addresses directly GPLV3 substitutes and replacements and things. And so, I mean, if you're interested in that, you should check out that project. Can you repeat that again? I'm sorry, what was the project? It's called the... Yeah, just get with him afterwards. Last comment, Sean, because I know we're out of time. Sure, one of the areas that I'm personally experiencing right now in terms of adoption of Linux and has a pretty broad range of impact is safety certification. And so as you have more and more complex systems that start to interact, ours is a self-driving vehicle, an autonomous vehicle, you have security concerns that now make it very, very difficult sometimes to make a case internally about using Linux. And the hybrid approach that we've started using so to give some people a ray of light is to create safety islands that are not Linux that are monitoring the Linux portions. But so anyway, I just wanted to call that out as an area that's also a challenge. Okay, I will put these slides online. You can look at the last 10 or so that have more pity me issues on them. But it would be great if we could find ways to collaborate and share information and automated testing and training that will help, I won't say eliminate, but lessen the pain of this as we go into the future. So that's kind of the goal. So anyway, thanks. What's your name? Shanshan? Nice to meet you. You've got some great questions with other sessions at the end.