 Speaking of circles, Dan Kochi is here to talk about our Automotive Grade Linux initiative. I already mentioned AGL a little bit earlier, but I want to, before Dan gets up, tell you, sometimes people ask me, like, what's the secret to Linux Foundation's projects? Where do you really focus on how you can create value for these projects? And it really is in the people. Dan came to me when we started, AGL had been functioning along, I've been working quite closely with, in particular, Toyota, and Dan is a person who's been in open source a long time, who worked at Monovista, which was acquired by Cavium, which was directly responsible as the general manager for producing the first actual Linux production vehicle, the Cadillac Q. Dan understands open source, he understands the entire automotive supply chain, he has delivered a production system being responsible for all aspects of that, and is now doing that at a meta level with our Automotive Grade Linux initiative, which is going well. So it's really, Dan is the secret to the Linux Foundation, and people like Dan, and so I'd like to welcome on stage to give a brief update on our Automotive Grade Linux initiative. Come on up. Alright. Well, thanks, Jim, that was very kind. I'll try to live up to it. So, show of hands quickly. Who here is really happy and ecstatic about their IVI system and their vehicle? Okay. Must be Tesla owners. I mean, let's be realistic, right? I mean, so why does AGL exist? It's for what I underlined over here. It's about rapid innovation. The industry has fallen significantly behind the smartphone. So it takes 36 to 39 months to produce an infotainment system using the old supply chain model. And I said that last year on this stage. In that time, three of these have come out. And by the time you drive the car off the lot, the software is already three to four years old. And then on top of that, getting updates for the car are a real pain in the butt, as we all know. You either have to go to the dealer and what do you get, maybe you get a map update, but you may not get new applications and new actual functionality. So, AGL is all about rapid innovation and changing that whole supply chain model and having OEMs take more ownership of the software. Because the OEMs are in the software business. The consumer wants the smartphone experience in the car. It's a no-brainer. And this is what AGL is all about at a high level. So, the goal of AGL is to build a platform that is common. All the common bits, the kernel, the middleware, the application framework, the security framework. All of that should be common. But we're not trying to put the industry out of business. We're not trying to put tier ones out of business. The idea is that why not build a platform that is common and everybody uses so that there is really an application ecosystem out there that has been ported to AGL and then you can mix and match different software applications on top of an AGL platform for a given production vehicle. And so that's the kind of thing we're trying to achieve. Achieve the 70 to 80% of the starting point of a production project, but you're never going to be able to download AGL directly to your car. It still has to go through a production phase with the OEM and their suppliers and so on, which is the customization phase. That will always happen in an AGL project. Very important, AGL is code first. There are other organizations out there that have specifications. The industry tends to be heavy on specifications. And in our mind, this leads to fragmentation because you can have too many compliant solutions and that's not good. It doesn't work, hasn't worked. We're a code first. So when you start an AGL project, you go to our website and you download the code. We have over 90 members. That's a 60% growth. Not as good as Hyperledger, but we're doing pretty good. I think it's a smaller pool of companies that are interested in automotive, to be honest. We went from five automotive manufacturers to 10, which is double in the past year. And even more important is that we now have close to 700 developers active on the AGL mailing list. We want to welcome Suzuki and Mercedes-Benz, Daimler, parent company. They recently joined AGL. We announced Suzuki in December and we announced Mercedes at CES recently. So these are the 10 manufacturers that are part of AGL. You can see that we have, in terms of volume, a pretty significant amount of cars that hopefully all of them one day will be running AGL. 91 companies, I mentioned. We have tier ones. We have OEMs. We have all of the significant semiconductor providers in the industry. And what's also interesting is we have a lot of companies that are participating to be part of the cloud solution. So it's not just providers of software in the vehicle. It's providers of software in the cloud to do connected car services to add all of those revenue generating services that the OEMs want in the future. And so that's very interesting as well. What do we do? Well, we just released version three of what we call the unified code base. That's the name of our platform. And it has significant features. I don't have time to go through them here. But what's important here is to point out that we're now in a cadence of a release every six months. And so far we've hit that. So we do a release in January at CES. And then we do a release mid-year June, July. And the industry is starting to depend on those. And they're making production plans based on those releases, which is exactly what we want. We've had a lot of media attention recently. This is probably the article that resulted in the most phone calls from the press. Toyota announced that their new connected car strategy. And they specifically mentioned that it's all based on automotive grid Linux. And so that's just tremendous news for us. And we hope that that whole ecosystem behind it will start using AGL in the future. We just had our all-member meeting last week. 220 people, 56 companies across 14 countries attended. This is just an amazing growth. I mean, this is only our fifth all-member meeting in the past two years. And we've more than tripled in attendance and number of companies and so on. So very exciting. So connect with us on social media. You can reach us on Twitter. That's where we put most of our news. And then lastly, I have a talk this afternoon at 4.50pm. So I'm actually going to go into much greater detail if you're interested. Please show up at 4.50. And I'll talk to you about AGL. So thank you very much. Perfect. Thanks, Dan. So our next speaker, Jelaine Lovejoy, is going to give us an update on some of our legal initiatives. You can see how the pieces fit together here, which is for automotive grid Linux to actually work across the supply chain that represents the auto industry. Car makers don't really make anything. They're just this massive manufacturing process of different suppliers across a very complex supply chain. In order to do that effectively with software, the intellectual property needs to flow smoothly. And Jelaine has been working on open chain and a lot of our projects that deal with removing friction from the intellectual property process of sharing that are really effective. In addition, I got a chance to ski a little bit yesterday with Jelaine and my eight-year-old daughter, Nisha. And Nisha turned to me at the end of the day, you don't know this, and said as we were dropping down into Granite Chief, she said, Dad, Jelaine is almost as good a skier as mommy, which is high praise. So, well done. So please welcome Jelaine, who's going to update us on some of our legal programs. So, as you all are probably aware, we talk a lot about open source license compliance and the IP that Jim mentioned at these conferences. And I think we've come a long way, but we still have a lot of challenges. We still have a rainbow of code that makes up products with increasingly complex interactions amongst it that we have to keep track of. We still have open source projects that aren't always fantastic about identifying what license applies. 50 million projects on GitHub, how many of them do you think have really awesome license info in them? We still have trouble getting info from our suppliers and then what does that look like when we get it and how do we even know how it was created? And so I'm going to give you a quick update on three projects that I think help address some of these needs. So let's talk about what some of those needs are. So here's our penguins in the supply chain. So we don't really have a common, we have people asking for this info, and sometimes I'm sure you've all experienced this in your departments at your companies, and you get info from your suppliers, it may not even be complete, people ask for it on the outbound side in different formats, and what we need is a common language for communicating this, so that we don't have to recreate this work all the time. So SPDX is exactly that, the standard format for communicating the license and copyright information associated with a software package. And it does actually, that's a really simple one liner, but it actually does a lot more than that. So I want to kind of give you a little more thorough explanation. So there's the SPDX specification, which I think Dan just made sound like a bad word in the last talk, but I do think specification is kind of a heavy, serious sounding word, but if you think of it as like instructions for collecting, storing and communicating data, such as the license information, the copyright information, the provenance information at both the file and project level, as well as the relationships between the code. And so SPDX defines all of that. And the goal has always been across the entire project to have everything be human readable and machine readable, because we want to be able to automate that as much as possible. And we know we can't automate everything, but some people don't have tooling, so you need to have both factors. There's a focus on facts, not interpretations. Interpretations are to be made by the lawyers like myself and their companies. And the SPDX output has two different formats, standard formats, that is tag value and RDF. And then there's also tooling to convert and verify the formats and the documents and convert into different formats. So if you're really attached to spreadsheets, you can convert into that format as well. At this point with the version 2.1 releases last fall, we're pretty mature. We've really nailed down a lot of the early kind of requests and use cases. And so the focus going forward is going to be on building better documentation, best practices, collateral for you to help see how you can use it yourself. And then also real world examples, as well as updating and expanding the associated tooling. Another part of the SPDX sort of family or product of the work group that's near and dear to my heart on the legal team is the SPDX license list. This is basically a list of about 300 and then about 20 license exceptions that are commonly found in open source. And the idea here was originally just to create an easy way for SPDX documents to refer to licenses in a concise and reliable way. But in reality, there's a lot of other places to want to refer to licenses in a concise and reliable way. There's also a long, as part of the SPDX license list, a matching guidelines to determine when a match, when you have a match. And we are in the process right now of converting and updating that into templates, XML style templates to better implement the matching guidelines. The matching guidelines are actually very human readable but not so easy for tooling to implement. So we want to improve that so we get more consistent results. There's also a license expression syntax so you can express when maybe more than one license applies to your code or a license choice or you have an or later option or you have a license with an exception that you have a way to express all those complicated licensing scenarios we come across. And there's tools to programmatically access the license list. Of course the HTML pages which is an image of right here is the human readable form but there's back end coding and tooling to sort of use that info in other ways. And this is all very actively managed by the SPX legal team and you can always request new licenses are added and so forth and so on. So what does SPDX look like in action? I kind of think of there being actually four categories. I added the fourth sort of recently. So there's the big full adoption, right? SPDX documents, you're generating them, you're shipping them with your products, you're consuming them, pulling them in from other suppliers. So we have some people are really head of the curve and already doing that. We have a lot of people just using the SPX license list and the short identifiers in a variety of ways. We see that being used in GitHub now. The OSI adopted them very early on and other places like that as well as internally. I know I just use them, you know, speaking in the bar and so forth. And we're also seeing, this is something that really excites me. I talked about this about a year and a half ago at LinuxCon in Dublin about people using, developers using the SPDX short identifiers in the source code at the file level, which not only is helpful if you're trying to understand what the license applies, especially if files get moved around and don't always go with the package, but also makes it a lot easier to automate extracting that info. And so we've added actually an appendix in the most recent version of the spec to show what that looks like. And then the fourth category that I think we're starting to see is sort of using the specification fields in SPDX in internal systems or when setting up systems internally. And I went through a recent process like this at ARM. And I think there's probably more, again, that's one of the things you don't hear about, but I think it's a really good starting point if you're trying to set that up. And you may have other things that you're tracking in your internal system. But when it comes to open source licensing and that kind of info, you know, why reinvent the wheel, you could just look at the spec and read that and use that as a guideline. I wanted to also note that our monthly general calls, we've been having guest speakers to talk about how they're using SPDX. And so I want to invite any of you who are using it to come on. It doesn't have to be a super fancy, well-polished presentation. It's just great to share that info. And there's meeting minutes on our wiki about people have shared it in the past. So you can check that out, which leads me to how can you get involved. We have several talks both today about SPDX in different venues that you should go check out, including a new tool that's going to be announced this morning. And then we have an SPDX working group here this week on Thursday afternoon. And of course, you can join the, we have a legal team, a tech team and the outreach team that work on different aspects of the project and as well as a general mailing list. So you can join in here, all of that. So great, we have this language. But then, you know, you need tooling, right? You can't do this all manually. So we really need open source tooling because this should not be a differentiation kind of thing. To gather the license data, report it and be able to do comparisons. So here's where Phosology comes in. Phosology is an open source project itself. It runs license and export control scans. There's a web UI and a database that it's, and it can be set up as a server. So you can share results across your company and compare and generate reports. And it has a really interesting history. It's going to celebrate its 10th anniversary this year, which I think is really impressive. It started as an internal tool by HP, who then saw this is something everybody should use and released it under GPL. And over the years, it's just more and more, become more and more robust and more and more features. Notably, most recent, with the 3.1 release, Phosology participated in SBDX Bake Off, which for the SBX 2.1 version release, which is basically when all different people who have tools that generate SBX documents get together and sort of compare results to everybody just getting the same thing. And then also added SBDX tag value format. So now the report can be generated in both of the standard formats for SBX. A workflow on Phosology would look a little bit like this. You might, if you haven't set up on a server, you'd upload your open source package you want to scan. You'd select the different scanning agents. You have some choices of how you can figure that. You'd then run your scan, browse your file contents, maybe do some clearing in terms of what the license that you found or the info you found. Maybe you don't have license info at the file level. So you want to say, oh, I think this license applies. And again, this tracks on SBDX fields and the SBX specification. And then you can generate a report in a variety of formats, not just SBDX as well as you could get an export control report or file notices and so forth and so on. So pretty handy. So how can you get involved with SBDX, sorry, with Phosology? You can learn more about how all of this fits together at Kate's talk tomorrow afternoon. And there's another project called SW360 which I think is interesting and could really fit into this whole picture. SW360 is a tracking and kind of open source and product management tool. So you can sort of track your request and approval for components in your products and it builds on top of Phosology so you can integrate in those reports and scanning. So I definitely encourage you to check that out. Okay, great. So we've got language communication and we've got tooling, but we still don't know how people are using that, right? I mean, no matter how good a tool is and no matter how good you define these fields, it's, you know, if you don't know how to use the tool properly, then your results aren't going to be great, right? So what we really also need is some kind of transparency, some kind of knowledge about what processes are being used to manage open source within an organization. And so that's where Open Chain comes in. So Open Chain is a newer collaborative project. Its vision is a software supply chain where Phos is delivered with trusted and consistent compliance information. And so to do that, we've defined what effective Phos management looks like. And this is, of course, defined in a collaborative process with people across the supply chain and members of academia and members of the open source community. And the output of Open Chain because it's not code, of course, is sort of three categories. So there's the specification itself, I'm using that word again, which defines what effective Phos management looks like. It's very easy to follow. I'll show you a little slide of the table of contents in a moment. There's six goals with a rationale and then requirements for each to meet each goal. And we've really worked hard on trying to create that in a way that it's scalable, whether you're a company of 20 people or 20,000, it should be able to work across any size company. One of those requirements is training. So we have a curriculum team that's put together a stock set of slides for training to meet the requirements that are identified in the specification. Training is the right huge key part of managing Phos in your organization. And we released the first version of the specification and the first version of the curriculum slides in October. So just a few months ago, we've already started working on version 1.1 of the specification and we've already done another release of the curriculum and working on version 3, which will probably come out pretty soon. So happy to have help on that. And then, oops, the third part is conformance. We have another part of the working group looking at how to sort of affirm that you've met the specification. So this is going to come out pretty soon in the form of a web-based questionnaire that you can fill out to verify and self-certify that I've met all the requirements, as described in the Open Chain specification or you might ask your vendors to conform with that and show proof that they've done that so then you can feel more trustworthy about what their processes are behind the information they're giving you that they generated through the open source tools going back to the two other projects. So that's another really key part and it all works together. So just to give you a sense of, whoops, going backwards and so forth, this is a little bit what the specification looks like. You can kind of see the six goals. This is just the table of contents, but you should go check it out. And then just a quick table of contents from the curriculum I thought you might be interested in seeing. So pretty basic stuff. You're probably already doing training like this in most of your organization. So why reinvent the wheel and keep rewriting that slide deck? And then really great recent development and we already have a Korean translation of the curriculum and a few other people have volunteered to translate it into other languages. So we're already having to tackle the issue of how do we do that officially and make sure they're all consistent. So that's really fantastic in terms of getting uptake for this in a global way. So how can you get involved? Again, a few more talks about involving open chain over the next couple or actually today. An interesting talk this afternoon about applying open chain to open source projects, which wasn't something I know I thought about right away. So I'm curious to hear Jonas talk about that. And then we have a working group on Wednesday afternoon, which anyone is welcome to join. We'll be looking at some of the changes for the 1.1 release of the specification and so on. And of course, you can join. We have two mailing lists, a general mailing list and a curriculum mailing list and bi-monthly calls. So you can find all of that information at openchainproject.org. So I said earlier that open source license compliance and management still kind of a challenge. But I think, of course, what's the solution to using that pain? Naturally, it has to be open source software and collaborative efforts like we've seen with these three projects. So we have the common language with SPDX, open source tooling with phosology and defining best practices with open chain. And I hope to see more of you involved in one or all three. Thanks.