 Hi everyone, my name is Tomi Langell. I am a consultant that helps organizations create mutually beneficial relationships with open ecosystems. Today, I'd like to address one of the most basic and yes, most fundamental question about open source. Simply, what is open source? And I'd like to try and give a more nuanced answer to this question that we usually hear. So there are two reasons that this came up. The first is we've seen a rise in ethical licensing over the course of the last few years. It's being driven by open source practitioners who are concerned about how their software is used. And also we've seen a high number of high-profile open source projects move from open source licensing to more restrictive licenses. Some still open source, aka GPL, and some that really fall out of the scope of what is recognized by the open source initiative as open source licenses. This started a few years back with Redis, then we had MongoDB follow suit. More recently Elastic and even more recently Grafana, which moved to a GPL. So if you look up what open source is, you generally fairly quickly end up on the website of the open source initiative looking at the open source definition. But what does the open source definition actually describe? Well, it turns out that the open source definition doesn't really define open source. Actually, it defines what an open source license is. And as you can see, this is fairly different, right? This is not just a rhetorical issue. It's not the same thing. And if we were in person and I was able to ask some of you here in the room, what are the features, how you would define open source, you would probably say widely different things than it's the license of the software corresponds to the open source definitions 10 criteria. For example, you might talk about the ability of contributing to an open source project or maybe the community aspect of the project, the ability to work together, the ability to work in the open, the ability to learn in public, the fact that the software is just freely available for anyone to use, the ability to learn from others, to network, all of the community aspects. As you can see, the definition is really broad and the different people, different constituencies in the open source ecosystem will have a different perspective and think differently about what open source is and what it means to them. So just looking at this, we see fairly quickly that although the licensing aspects of open source are important, there's a whole other set of aspects that are important to people too. And it's interesting to sort of like try to combine those in order to dig a bit deeper. And if you really look at what all of these aspects are, they're really about the norms of open source on one side and the legal licensing aspects on the other. So what is this going to look like in a two by two full quadrant diagram? Well, let's simply put on the y-axis whether the license of a project has been certified by the open source initiative and on the x-axis, let's put whether the project follows or ignores typical open source norms like the ones that we discussed before. So we'll package in this horizontal axis sort of all of what makes a project feel open source, the ability to be able to contribute, the ability to be able to work together on a project, et cetera, and we'll put only the licensing aspects on the y-axis. So what does that give us? Well, essentially, any kind of project that has an open source certified license will be on the top two quadrants and open source projects that follow norms will be on the right two quadrants. So let's now dig in to the right two quadrants. To each of those quadrants more specifically, starting with the top left quadrant. This is the quadrant where you find projects that are open source in terms of their license, but don't really abide by your typical open source norms. An example of this would be, for example, the Android software, right? Android is an open source project in terms of its license, but from the perspective of all of the other aspects of open source that you would expect, for example, that the project is built in the open or that it accepts external contributions or at least considers them not to mention things like it having an open governance. Well, that project doesn't meet any of these. Really the only thing that makes it open source, strictly speaking, is the fact that it has an open source license. And so I really like the fact that some people have started talking about this and calling these projects nominally open source. I sort of think of them as open source and letter only, not in spirit. A lot of the open source projects, the high profile projects that we talked about initially were actually in this quadrant and have moved downwards towards the bottom left quadrant as they abandoned strictly OSI certified licenses in favor of licenses that made it easier for their business model or that's their claim. And so this is the second quadrant I'd like for us to explore, which is the quadrant of software whose licenses are not open source certified and who ignore open source norms. And this has been dubbed open source and open source is essentially a project that sort of claim to be open source from a licensing perspective, but aren't and also really don't respect any of the typical norms of open source that you find. Yeah, and this is really where you find a lot of the open source vendors who really see in open source essentially a marketing tool. We'll come back to this. So moving up to the top right-hand side corner, what do we find here? We find open source projects that are OSI certified, right? And that follow open source norms. This is really the place where you wanna be. And I kind of call those community-driven open source, but that's a bit restrictive. There are projects in that space who are not community-driven. For example, smaller open source projects really belong in that space in terms of following norms and having an open source license, but are not technically community-driven essentially because they're too small to be community-driven. But the spirit clearly is absolutely there. And going down from that third quadrant right into the bottom right quadrant, this is an increasingly interesting quadrant to me. Why? Well, because you find a lot of projects in that space that respect and follow open source norms, but who don't have a OSI certified license. And there might be a number of reasons for this. What's really interesting to me is that category is actually way broader, right? So I talk about this in terms of like the broader ecosystem of open source. And I also think that in contrast with software that is open source and letter-only, software in that space is really open source and spirit, right? Even if it doesn't necessarily have a OSI certified license, it really abides by these norms. And I think if you really go at the very, very bottom of that space, you wanna actually find their inner source, right? And what is inner source? Well, inner source is software that is built internally in a company or in an organization who is not open sourced in the strict sense or doesn't have a OSI certified license, cannot be used by others, right? But really is built using open source practices. And so, at this bottom right-hand quadrant, you have sort of like this huge spectrum that goes from software that is, for example, a CCO license, so public domain software that cannot be certified by the OSI for a number of reasons that we're not gonna get into today. But that is extremely close to open source in every other way. All through all of the creative commons, a lot of the creative commons, for example, the CC by non-commercial because of the non-commercial restrictions, cannot really fall under the open source label, but are really close. I mean, it's not code, I understand, but from a sort of norms and spirit really feels part of this build-on, remixing culture that open source really has fostered. And then you have all of the ethical source software, which I'm increasingly seeing as open source that is focused around maybe smaller communities that don't necessarily want or desire that their software goes beyond those communities and essentially want to be able to have some degree of control over how that software is used and going down all the way to inner source where software is really protected by stays inside of an organization or a company. So to summarize and walk back through the different categories that we've defined using that two-by-two full-coordinate structure. Starting off where I started before, which is in the top left-hand quadrant where open source is in letter only. So projects in that space have a license that is certified by the OSI, but they really don't follow the open source norms at all. It's really only about the license. So this is where you find projects like Android, but this is also where you find a lot of those high-profile projects that have moved to open source over the last few years like Elasticsearch and MongoDB were on this in this top left quadrant beforehand. IE they had an open source license, but they really weren't abiding by the norms that much. Another really common thing that you find in this space is open source projects where the terms don't apply the same way to the community as they do to the project vendor, the original creator of the project. So you see this very often with GPL plus CLA, where the CLA, which is the Contributive License Agreement actually gives the original creator of the software extra rights and essentially the right to re-license that software as they want. And this is how a lot of projects used to be monetized in the past where the owner of the GPL would actually sell non-GPL licenses to their clients. Moving down from that top left-hand corner, you move to the bottom left and this is the realm of open source, right? This is a software that really is there because there are marketing benefits for that software to sort of pretend that it looks a bit like or OSI certified open source. But again, here you will not find much in terms of open source norms. Moving to the top right-hand quadrant, this is really what everyone thinks of and perceives as being true open source software. An OSI license on the one hand and real community open source practices and norms, probably an open governance model or if not clearly very open contribution system. So the kind of open source software that we all sort of know and really like and moving down from that top right-hand quadrant, sorry, into that bottom right-hand quadrant is the broader ecosystem of digital commons, right? And this includes a lot of creative common stuff, ethical source and moving even further down to some degree in a source. So essentially, software that is built using open source norms but doesn't necessarily have the OSI certification on its license and so has some restrictions around usage which might be problematic for some use cases but are perfectly acceptable for others, right? And this is a really open source in spirit. All right, so still using the same quadrant, I'd like to offer a different perspective on this quadrant which is one that focuses not on the projects themselves but actually on the different constituencies that are part of the open source community. Let's start with the user focus. So what's really interesting here is the perspective of the user around open source is really just to make sure from a legal perspective that they comply with the license and so that the license is actually a genuinely open source license because that makes compliance a lot easier. So the focus of open source users is really essentially the top two quadrants so the ones where the software is certified and to some degree regardless of whether the software actually abides by open source community norms or not. However, savvy users of open source will check and be wary of software that doesn't abide by open source norms and there's two reasons for this. One is this can really be open source in the making. So typically if you've been betting on, for example, Elastic for your open source project a number of years ago, now you're probably in the position where you're not super sure what you have to do. Maybe you wanna rely on the fork that Amazon is maintaining. So it's a bit of a complex situation that you probably didn't want to be in. So that is one reason to tend to look at not only whether the license is actually open source but make sure that the community exists around the software and that the culture of the project really is an open source one. And of course, the other reason to do this is really from a sustainability long-term health perspective of the project, right? If a project has a sustainable multi-user governance model, et cetera, it is a lot easier. It's a much better position to participate to this project, fix the things that you care about but also make sure that the project is still going to be there. And if you're not sure what you're gonna do the project is still going to be there in two, three, four, five, six years. So really the user perspective focuses on the license absolutely and but also savvy users focus on norms. Now, if we look at open source contributors, well, their perspective is fairly different, right? Because they're much more interested about what the community looks like. I mean, lots of people don't mind using the beer license or the WTF license, sorry. And why? Because what matters to them is the contributing aspect, the community aspect, the respecting the norms aspect. And so really you will find these contributors caring more about norms than they will about licenses. Now I'd like to look at the last constituency that we're gonna look at today. And these are software vendors. And while software vendors are kind of all over the quadrants, you will find some in every one of those quadrants. And so what's really interesting is to understand how their perspective differs and kind of how they're thinking about open source in each of those different quadrants. So again, in the top left quadrant, vendors are building software that has an open source license, but the open source aspect is more of a marketing gimmick to some degree than really a reason to build a strong software together. And so when projects slide from having an OSI certified license to having a non OSI certified license, their perspective changes from open source is great for marketing to open is great for marketing. So that's kind of where the perspective is. That contrasts quite a bit with projects that see open source not so much as a marketing strategy, but as an engine to build really great software. Three to canonical example of this is of course, Red Hat, which really sees its upstream open source as a wonderful place to build great software and its role not so much as selling that software, but at making it really easy for their clients to be able to use that software well for their projects. And so in that space, really the perspective is, open source is a great way to build software. So that's in the top right hand. So this is OSI certified combined was abiding by open source norms or I mean, I should say, leveraging open source norms to build fantastic software. And so bottom right, well, a lot of players in that field actually are players that really care about open source, but find it really hard to monetize or just concerned about monetizing open source software in that space and just don't come from that culture. So for example, GitHub, when it started, I mean, it's still not open source today, but when it started really sort of felt like it was in that bottom right hand culture, which is open source is great. You want to open source as much as you want, but if you open source too much, or if you open source your whole product, it's going to be really hard to monetize it. And so instead, you should essentially be open sourcing sort of the infrastructure or the pieces that made building what you're building easy to do. So this is a really good example of open source. The perspective from vendors, right? So you see moving from a culture where open source is a marketing strategy to a culture where open source is really how you build great software. And then wondering about how to monetize open source in that space. All right, so to conclude this presentation, really what I wanted to show you today was that open source is a lot more than just its license. And this is something that that's a feeling that we all intimately have. And I really want to validate this feeling. Open source is about community, open source is about open source norms. It's about a shared sense of purpose. It's about all of these things. And it's extremely important not to reduce open source to just the license. And not only for these, to some of your personal reasons, but also for the business aspects of this. Because when you stop considering open source more globally and just consider the licensing aspects, you start missing signals that a project is actually on a trajectory or at least on a potential trajectory to becoming open source and creating a world of hurt for companies, developers, projects that have been building on top of it. So there are really good signals that you can pick on to avoid putting yourself in that situation or at least if you really have to rely on a project that is risky from a community health perspective, do so knowingly. And these signals are essentially around those typical norms that we talk about. Like is it easy to contribute to that project? Is the maintainers all from one company? Is there an open governance model? Is the project in a foundation or is it really controlled by a company? What about the trademarks? Is there like a lot of confusion between the name of a company that's behind the project and the project itself? All of these are red flags. If you see those thread carefully because you might very well put yourself in harm's way in the midterm, right? But to end on a more positive note, I think this exercise is also really valuable because it shows that one of the key aspect of open source are all of the community norms aspect. This is what creates this really high quality software that we all care about. And those same practices, the same spirit of open source can be used elsewhere to great success. Whether that is inside of a company, call it inner source if you want to, or in projects that are more restricted in terms of who is able to use them. For example, CC by non-commercial or ethical source licenses, but still really carry the spirit of open source because it's the spirit, it's these community aspects that we really see value in personally and that are also extremely valuable in order to create software that is of really great quality. So thank you so much for your time and I'm happy to take questions, one more questions now. And to hear your comments about this sort of more nuanced answer to the question of what is open source. Thank you very much.