 Thanks so much for being here. Thanks for the introduction, Jim. And I wanted to talk to you today about the bigger picture of collaboration. And to do so, I'm going to start by talking about skateboarding. So when I was preparing for this keynote, I was telling a friend how I'd been listening and watching talks for good examples and inspiration. And he said, oh, oh, there's this TED talk by Rodney Mullen, you have to watch. And Rodney Mullen's considered the godfather of street skating. He invented many of the quintessential tricks, like the flat ground ollie, the heel flip and the dark slide and so on. So I'm listening to this talk and he's describing his experience with early success and the evolution of the sport and how he had to adapt his style. And then he starts talking about how skateboarding tricks develop by creating tricks on top of foundational tricks and combining several movements. And then he starts talking about the skateboarding community. And he's really, really passionate about the beauty in that no one guy is the best. And he says that real respect is given by how much someone takes what others have done, contributes to it themselves and makes it their own and then contributes it back in a way that edifies the community itself. So at this point, I'm sitting there thinking, hmm, this sounds really familiar. And sure enough, the next slide is titled open source and hackers. And he draws a comparison saying how the basic ethos of the open source community is to take something, make it better, give it back so we can all rise further. Now I should have said earlier that my friend doesn't actually know what I do for a living. He just thought it was a great talk and it was inspirational and it was. And listening to Rodney Mullen talk about community and what I would call collaboration got me thinking about a few things. The first thing it got me thinking about is I come to a lot of these conferences as I'm sure you do. And we always talk about how powerful collaboration is and how it's such a superior way of creating things, software in particular. And Jim Zemlin has to come up with increasingly creative ways of telling us or showing examples of how and what can be accomplished through the collaborative model. I mean, if you didn't know any better, you'd think the people in this room, nope, are we gonna turn this off? Okay, great. Sorry about that. So you'd think the people in this room had invented the whole concept of collaboration. But you can actually find examples of collaboration all around us, like in the way skateboarding evolved from freestyle to street skating by adapting to a new environment. The other thing that this got me thinking about was the appeal of collaboration. I mean, when Rodney Mullen started talking about community and building off of what others had done, I was really alert. I was paying attention. I felt kind of excited. Why? I think it's because there's something inherently compelling about the values that underpin collaboration. To draw from what Mullen said and some things that ring true for me and the things I've observed in this community, I think it's about being motivated by the respect from your peers, the satisfaction of creating something others can use and being part of a community that you helped build and you can see other people contributing that and taking it to the next level. I think for many of us, there's something really attractive about that. It draws us in, it inspires us, and it motivates us. I mean, I know personally, if I think about the accomplishments that I've had both professionally and personally, they have a lot to do with one or all of these values. So this got me to thinking about my own profession, about lawyers. Can lawyers collaborate? We don't really have a collaborative atmosphere. Our work's not usually thought of creative and we generally work in isolation or in an adversarial space or both. At its worst, the legal profession is one that emphasizes pride and never admitting that you're wrong or you don't know something and emphasizes beating or outwitting or outnegotiating your peers. And we certainly don't reuse each other's work or at least admit we do. If you're an in-house lawyer, I think you're generally kept in a windowless room. Doing a good job means that you, no one notices you while you seamlessly ensure that the company stays within the bounds of the law while meeting its business objectives. So none of this really sounds like a good setup for a collaborative model. But what can lawyers learn from this? Why can't we benefit from the collaborative model? How can I convince my community that sharing and contributing is sometimes better than silos and silence? So I'll come back to that question but I wanna tell you another story. A few years ago, I was at Collabs Summit and I was asking colleagues, what have you been up to? What have you been working to do? Catching up, as you do, at these kinds of things. And I noticed that the answer was largely the same or several people said the same thing and they said I've been working on open source training. And this was interesting because so had I. And so we were chatting about this some more and finally I said, what do you bet that my slides and your slides and his slides are all largely the same? I mean, we're covering the same foundational stuff. So what a waste of time, right? Putting slide decks together, take a long time even when there aren't very many slides in them. So why are we sharing this stuff? But even if I had decided to share the slides that I did, how would I go about doing that in a way that was useful? That people could know they could rely on them or even find them. And it was the same kind of thing when I asked people about how they manage open source software in their companies. The answers were largely the same but no one was really sharing that information. It was exchange and conversations personally behind closed doors. And I noticed about a year or two ago at events like this, a couple people started to speak publicly describing their processes or lessons learned but this was rare. And it was only a few years before that some companies actually thought how they managed open source software was a competitive advantage. So it starts to sound like what I was describing with lawyers, silos and silence and secrets behind closed doors. Maybe my question from earlier should be brought in to ask what can companies and their internal processes learn from the collaborative model beyond sharing code and collaboration and collaborating on software? Cause clearly we're pretty good at that. So that's an important question to ask because we have all these companies trading in software. No one makes a product all by themselves but companies aren't necessarily good at understanding how to trade in something that's open. What companies are really good at and the lawyers employed by them protecting IP, confidential negotiations, internal processes. But that doesn't really serve the reality of software moving through the supply chain because at each step the business concerns are actually the same. We wanna protect and respect the IP rights of others. We wanna comply with the licenses for the software we're using. We wanna be aware of potential security vulnerabilities or any weaknesses. Basically we wanna make informed decisions about accurate info about what's in our products or the software from our vendors. But in order to that we have to ask what's there. Or we have to know what's there and in order to know what's there we have to ask. And even when we ask and we receive that information we have no idea how it was compiled or what processes supported putting that information together. And the result is that a massive amount of time is spent gathering that information in the first instance and then more time is spent negotiating warranties and indemnities to back it up. So back to the lawyers. But how can we take the advantage of collaboration and imply it to making software moving through the supply chain will have less friction and build trust? What if we had a collaborative group to solve this to help define what the processes look like? So enter open chain. As Jim said, open chain is a new Linux Foundation Collaborative Project with a vision of a software supply chain where free and open source software is delivered with trusted and consistent compliance information. Now open chain was a brainchild of my friend Dave Mar who's open source attorney at Qualcomm. And I'll never forget when Dave first told me his idea cause the conversation started like this. He said, Jelaine, I want to put us out of business. And by us he meant open source lawyers. Now I know there's a few of you who would love to see that day. I think the idea here was if we could establish these guidelines and do it in a collaborative way instead of hidden internal processes, then maybe we could get to a point where at least the lawyers don't have to ask so many questions. And I know that would make all of us a lot happier. So to achieve that vision, we've created a specification that describes the requirements of effective FOS management. And those requirements in the associated collateral are developed collaboratively and openly by members of the software supply chain, the open source community, and academia. And we've also made sure that those requirements are scalable, whether you're a company or an organization with two employees or 20 or 20,000. It's really important that everybody can meet those. And they are just tailored to say a bigger company. The idea here is if we can all agree this is what good FOS management looks like, then we can be able to say, I do that. And then we can trust the information that we've passed along to each other about much more. Because by peeling back the curtain, opening the closed doors, we have transparency. And as you all know, with transparency comes trust and with trust comes freedom to do other things, right? So this is a great time to introduce you to open chain. We just became a collaborative project for the governing board earlier this year. We were working for about a year before that as an informal work group. And so I just wanna start by giving an overview of sort of three key areas we're working on. So the first is the specification. This is the description of what effective FOS looks like. And there's requirements and then rationale of describing sort of why it's important. And it's organized into six goals. I'll tell you a little bit more about that in a minute. We've just released the first version of the specification this week. So hopefully you'll check it out. And one of the requirements is FOS training. So we have a curriculum team that's put together training materials to meet that requirement, sort of a stock set. So here was the answer to the question I asked earlier in the story about talking to people at Cloud Summit. Then, so that initial set of training slides, by the way, is also now available. And tomorrow here in Berlin, we're gonna start working on a teacher's guide to go along with them. So maybe some of you will join us tomorrow. And then the third group or part of the open chain that we have or team is the conformance team. So this is looking at setting up a way to self-certify that one's met the requirements of the specification. And initially this is gonna take a sort of self-test or web-based questionnaire that you can fill out or have your vendors fill out to say, yep, I do all these things. So I wanna talk a little bit more about the specification since that's sort of the nuts and bolts. It's organized into six goals. So I'm gonna walk through them briefly and remember to have this in my hand. So the first one is know your FOSS responsibilities. So this means you have a FOSS policy that's written and communicated. And you also have FOSS training for all the relevant software staff. So this goes back to that curriculum team I mentioned earlier. Goal two is that you have assigned responsibility for FOSS compliance. So this means you've assigned it internally. There's someone responsible and it's resourced for achieving FOSS compliance. And that also means you have an external contract that outside people can get in touch with in case there's any inquiries about compliance or the open source software you're using. Goal three is review and approve FOSS content. So this means that you have a process for identifying and tracking the FOSS used in your software and that process is robust enough to capture whatever the typical use cases are, how you're using the software in your organization. Goal four is that you deliver FOSS content documentation artifacts. So this is compliance, right? This is making sure that you've met those requirements and you're doing it right and so forth and so on, pretty important. In order to do that, you have to have all the information that comes before. So I think one of the keys to goal three and four is having what I would call a complete set of data about your software. And this is where another project that under the Linux foundation comes in that Jim mentioned earlier, the software package data exchange, or you might have heard of it as SPDX which is basically a common way to communicate information about software moving through the supply chain such as the license, the copyright notice, where it came from, the package number version and so forth, package name and the version number and so forth. Goal five is understanding FOSS community engagement. So this means you have a policy addressing external contributions you make to external projects and a process to support that. It might be a one-liner, it might be part of your bigger FOSS policy but I really think it's important that we included this here because as we all know, the typical entry point to using open-source software is consumption. And it's usually later, hopefully, that companies realize, oh, I should really engage with the community that's to my benefit to do that. So I like that we've recognized this even in the first version of the spec. And goal six is the conformance piece I mentioned before. How do you certify adherence to the open chain requirements? And as I said, this is gonna start out as a self-certification questionnaire that we're working on now. So easy, right? Why don't we do this sooner? I mean, if you put it all together and you can say, this is what we think good FOSS management looks like, then we can rely on the information we see and when we do that, we can build trust. And with trust, like I said before, it becomes freedom. And I think this is especially great for small and mid-sized companies. A couple of years ago at LinuxCon Chicago, Eileen Emmons did a talk on about the open-source professional, sort of a rise in the need for people who can bridge the legal engineering and business worlds, which is critical for managing open-source software and a lot of questions that we come across. And so now I feel like the people in that position have been tasked with that and their companies, who I'm seeing an increasing number of, they have the place to start. They have something to refer to that's been developed by the people who've been doing this maybe longer and more experienced. And instead of toiling away in that windowless room, they can enter a community, collaborate, and help make it better right away. So by way of example, let me tell you a little bit why this is important to the company that I work for, ARM. I think it's fair to say that ARM sits at the beginning of the supply chain. ARM has a unique business model. We are an IP licensing company, and we created an ecosystem of partners which is critical to our success. So we already know something about trust and collaboration. We have to do things right for our partners. But I think we also have an opportunity, given our position in that ecosystem, to be in an example, to start things out on the right foot. Because ARM cares deeply about our ecosystem and making our partners successful. And by being involved in Open Chain, we can demonstrate that value that we place on that partnership by helping build something others can use. And we're not the only company that thinks this is important. These are the Platinum members who comprise the governing board of Open Chain. A few familiar faces on that slide, I think. And also a pretty varied representation. But this slide doesn't even show all the community members from other companies, law firms, and community organizations who are contributing to Open Chain and working towards its success. So Open Chains run like other collaborative projects. Anyone can join, anyone can participate, and all the work's done in the open. And some of the things we'll be working on and need help with includes working on the specification. We've got the first version out, but of course we're always gonna make improvements and there'll be other versions. Also the curriculum slides I mentioned, we have the first version out, we'll be working on those. And the training module, excuse me, the teacher's guide to go with those, the conformance questions, website issues, and so forth and so on. So my question to all of you is this, if someone from your company isn't already following or contributing to Open Chain, who's it gonna be? When you go back to your office after spending time in this lovely city, who are you gonna go have a chat with to get involved with Open Chain? To make doing software business easier for all of us so we can focus on the more fun, challenging, and differentiating aspects of all of our jobs. I was going to start this talk by telling you how up until my prep for this talk and watching the Rodney Mullen video, all I knew about skateboarding was what I learned at LinusCon San Diego when I got this awesome custom Linux skateboard and got to take a lesson at lunchtime. And at that point, all I knew about skateboarding was it was really hard. I didn't really have those foundational tricks to put everything together. But as it turns out, I know a lot about skateboarding because I know about community collaboration and lots of you know about collaboration in building great software. So let's make Open Chain successful by using that knowledge here. Thanks.