 Can you hear me now? So this might be boring for people who aren't lawyers. It might be boring for people who are lawyers. But something I was really interested in. It could also be terrifying for non-lawyers, too, I suppose. Sometimes non-lawyers find contracts really scary. So I'm going to talk about the on-popular open source licenses. Just to get off, I am a lawyer, but I'm not your lawyer. Looking around the room, I'm pretty sure I'm definitely true I'm not the lawyer for anyone in this room. This isn't legal advice, nor is this presentation intended to be comprehensive. It's only 20 minutes long. And these are my opinions, not the opinions of my employer. You can tell because even though my employer paid for my trip, I didn't use their slide deck. So you don't know who I work for. So OSI category has about 83 open source licenses that they've approved as being open source. And they categorize them. And if you go to their list of licenses, they identify which ones are the popular licenses. So these are the licenses that I think everyone's pretty familiar with. There's a reason why they picked them off Apache, the BSDs, a subset of the GNU licenses, MIT, and the Mizzile public license. But there's actually a lot of other licenses besides that. So if you dig a little bit deeper, they've got other categories of licenses too. It's just informational about how these things are. But there's licenses that are international licenses, special purposes licenses, miscellaneous licenses, uncategorized licenses. Licenses are involuntarily retired. The interesting thing about this is that a lot of these categories are kind of meant to indicate to people. I'm like, don't use these. Superceded, non-reusable. The problem that I see a lot in contracting, my company only provides professional services. And we only provide professional services around free and open source software licenses. So typically when we have a contract, they're going to mention the use of open source licensing. And in those contracts, typically what they do is they just talk about open source generically, or open source as approved by the open source initiative. And this is a pretty typical one. If anyone uses AWS, you agree to this clause where it says that some of the material is going to be provided to you underneath a separate license, and it's an open source license, and that you agree to those terms. When I see that in a contract, I try to read all of the resulting material, but this basically sweeps in anything that counts as open source. Now for this particular clause, they don't even say as approved by OSI. But I also see this pretty typically in contracts as well where they say you can only use source code that's distributed underneath the terms of a license as approved by the open source initiative and listed on this website. But there's a lot of them there. So my question to myself was like, why do I keep agreeing to all these licenses if I've never read them? I should actually read all of these licenses. So I went through and that's what I did, and I pulled out some of the things that I found those licenses that kind of surprised me. Things that I don't really think about when I think about an open source license. I've got my idea of what it means to be open source. Yeah, there's the open source definition, but I also have my theories about how you can deal with those things. Now it doesn't actually line up with all of the open source licenses that are approved by OSI. Certainly not all of the licenses out there that are substantially similar to them or that people call open source. So I'm gonna focus on the licenses, the properties of licenses that aren't popular or things that I think were kind of surprising there. So all of these licenses have met the open source definition or at least OSI at one point said they did. I'm not sure if all of them would be approved again because the way approval happens has changed over the years. So some of these are older licenses. But my goal here is just to give you a sense of when you say that you're agreeing to, that you're okay with an open source license or you'll take material underneath any open source license approved by OSI, these are some of the terms that you might be agreeing to. So the first thing I wanted to point out just to tell you that there might be some really surprising things here is what kind of material do these licenses apply to? Now two really popular licenses, the AGPL and the Attachee 2.0, they're not surprising, right? AGPL applies to any copyrightable work and Attachee 2.0 applies to anything that's a work of authorship. Now at least underneath US law, those are basically the synonymous. Those terms mean basically the same thing. But if you look at other licenses out there, they're not that broad. So some of these licenses only apply to software and they leave software undefined. So it's written in English so it's gonna be the common meaning of the word software in English, right? If you're using the zero clause BSD license, you can't license anything underneath zero clause BSD that's not software. Same thing with the IFC license. I don't think those two licenses are particularly uncommon actually. They seem to get used a lot even though that's not things that people usually think about as examples, but they're widely used. There are less common licenses, the adaptive public license, which I know there's software out there that's using it although I've never come across it in my job. That only applies to computer programs, whatever that means, they don't define it. And the CESA license, which maybe is more popular outside of English-speaking jurisdictions, only applies to software and documentation. And then you have other licenses that are really specific, right? Licenses, these are the non-reusable ones. The framework license only applies to the framework's code base, whatever that is. They don't actually define that, right? But there's a license that you can't actually reuse anywhere else. But it's out there. So and some of these licenses are there. So you can't actually just pick up any of the OSI approved licenses and use them at anything because if you tried to license your material underneath the framework's license, you wouldn't be licensing anything all because you're not frameworks and you can't make the framework's code base. So in general, what are these licenses applied to? Well, I think there's probably three categories, right? There's the licenses that apply to all copyrightable works, right? Which is what I typically think of. You can apply these licenses to anything. But then there's also the licenses that only apply to software and documentation. And sometimes that actually gets a little hairy because we'll talk about those associated things that get sweeped up in there. And then there are the licenses that just apply to software. So I know it's a common practice amongst open source projects to say, well, just put everything in the Git repo and we'll apply one license to it. We don't need to worry about how we license the documentation. But if you're using a license that only applies to software, you're not actually giving a license for that documentation. Or if you're writing a video game and you wanna have an open source video game, typically what I expect out of the video game, right? Is that you've got the game engine. That's the software. And then you've got the levels and all of the character art. Well, if you've decided to license your video game underneath one of these licenses that doesn't apply to all copyrightable material, you might not actually be giving a license out for all of that other material, right? So you actually do have to look at these licenses and their scope a little bit more. So just don't assume that all the licenses operate the same, is my point here. And I'm gonna show you some reasons why as we go through this. It's similar for the material that applies to is the rights that are granted. I tend to think of all open source licenses providing you basically the same rights and the differences between them will be the conditions that are placed in those rights. But that's not actually true. So the Apache license, again, it's a pretty prototypical example. They grant you a copyright license and a patent license. And I'm not gonna get into like patent versus copyright license kind of stuff that people talk about or these lawyers talk about. But it gives you all of the statutory rights underneath US copyright in these licenses. So you can pretty much do whatever you want. But then there are other licenses out there like the fair license, which literally says usage of the work is permitted provided that. So the only thing you can do with material provided underneath the fair license is usage. What does that mean? I mean, I would actually say it means you could use it and that's not the same thing as modifying it. It's not the same thing as distributing it. It's not the same thing as making copies of it. So if you're actually gonna look at that text of that license, like the conception of what you can do with OSI approved license software, it's pretty wide ranging here. It doesn't mean that you can actually modify it. Now, I think probably at the time that they approved this license, there was an idea that this actually meant that you could use it for many things including modifying and distributing it. But my question to you is gonna be that happened. I think this license was approved about 20 years ago. When you bring this in front of a judge or if you get into a contract dispute with your partner in this or the person you gave it to you, like they might have looked at the word usage and thought the word usage meant usage. And that's not what it means or not what OSI thought it meant when it was approved. There are other licenses that are a little bit more complex. So maybe the fair license is so simple you can say, well, that's clearly not what usage meant. It has to mean those broader rights. But when people get more specific about what they mean for those rights, it's a little bit harder to make that argument that they were just being sloppy with their language. So the open group test suite license says that you can modify it, sure, but you have to keep the original test modes are being preserved, right? So you can make modifications to this but you have to leave the stuff that's already there in place. You can't remove stuff. And they're really specific actually about this, right? So if you make modifications to it, you have to make sure that the executables that come out of it have a different name so they can't conflict because you have to leave the originals in place underneath the original executable names. And on top of that, you're required to write documentation on it, right? So I'm pretty sure that everyone's who's software developer in this room has never written a piece of software and then failed to write documentation at the same time, because we all know that's the best practice and we would never do that but you might have some colleagues out there who are a little sloppy and they don't write documentation. But here's a license that says you're violating the open source terms if you don't write documentation, right? There's also licenses out there that remember, these are only licenses that have been approved by OSI, right? So I know there are other popular open source licenses out there that are similar to this one that aren't approved by OSI but this one's been approved by OSI. The QPL from Trolltech, I think this was, QT was distributed on it for a long time, so a pretty popular package that says you can copy and distribute the software in an unmodified form, right? That's a right, of course you can do that, right? You can make modifications to the software and you can distribute your modifications but only as patches, right? So you can't actually distribute your modified software, right? You can't just put that in place. You've got to distribute the unmodified software and then patches along with it, right? That, I don't think that's a normal expectation. So there it's fulfilling the expectation that you can modify it but it's being really specific about how you can distribute those modifications. So I'm not gonna read all the licenses to you and I'm not gonna list every license but I just wanted to go through some surprises there. So one of the things I think is most surprising and most concerning to me is when there's restrictions on the use of the software because I tend to tell people, like well what's open source software? I'm like well open source software is software that you can use without any kind of restriction. Like that's literally what I tell people when I talk about this stuff and then there might be restrictions on like modification or distribution but you can use it for anything, right? Well the frameworks license has a restrictions on use of if you're gonna provide services around this they actually specify how much money you're allowed to charge for those services. It's gotta be a fair market value license. Now the first time I read this I thought like oh that's kind of like a cap you can't charge too much. Then I thought wait, if I was actually the licensor maybe that's a floor because maybe I was trying to create a market for it where I said well I wanna provide services and I don't want someone coming in and undercutting my prices so if you're gonna sell services you at least have to be selling the services for at a price that would be worthy of business for me. You can't knock me out of the market by giving services away for free. This is in an OSI approved license. And then restrictions on use too. I think most people think of the network copy left license as having a restrictions use, right? If you're using your open source software and a cloud platform that SaaS, right? Software as a service. I can't remember the acronym that the meaning for free software foundation uses right now software as a slave or something like that I'm sure. And I'm like they think of network copy left licenses like oh if you use this that means that you have to share the source code and the example they always point out is the aphero general public license. Well I'd like to make one thing clear here. All of the licenses, there's 10 licenses that I would classify as network copy left licenses. Of those 10 licenses there's actually one license that doesn't actually have conditions on the use of the software and that's the aphero general public license, right? The conditions on the aphero general public license actually have to do with modification of the program. If you modify an AGPL program and then you use it to provide a SaaS service that's when you have to offer that source code. But if you don't modify it you don't actually have to do that, right? So it's not a restriction on use but those other nine licenses those all do restrict your use of the software. If you use that software to some degree you need to provide a source code. And some of those are actually really kind of interesting. The open software license which I think is really interesting because if you look at this large ecosystem of the license here there's a lot of derivatives of the open software license out there. This is really influential at least for lawyers who wanted to make their own at least in a period of time. And they make it clear that external deployment means using the software. If you use that software you offer that software someone else to use you need to distribute your source code to them, right? And it's on use, it's not on modification. There are other licenses that do it too and how they get this scoping out there, right? Because there's some criticisms of the AGPL license about well it's only to people who access the software. Well what does that actually mean? Is there a way of getting around that? The European Union public license at least version 1.2. Just a caveat on this as well it's not a criticism of OSI. I appreciate the people who are on that board are doing this volunteer and it's a very hard job. I'm on boards and nonprofits as well. I was only looking at licenses that have been approved by OSI and are also listed on the website. So I think the EUPL has, 2.0 has also been approved but it was not listed on the website at the time that I made my list. I don't know if that has changed because I made my list a couple months ago. So version 1.2, if you provide access to the essential functions of the software to anyone you've got to give them a copy of your source code. All right, so there's a way of shading who you have to give this to it. So it's not just people you give copies of the software to, you have to provide source code too. It's not just people who are accessing the software but if they have access to the essential functions of it. So if you think about like the MongoDB disputes right now if anyone is following that, that's the essential functions, right? Like that might actually be a little bit broader than what they're proposing underneath the server side public license. And I mean, I can go keep going through all these. The reciprocal public license has an even broader one. Modifications means, so the scope of the software here they actually go beyond just the program that you're talking about. It's not just the program that's licensed under the reciprocal public license. You have to provide source code too. But you have to provide the source code to any program that replaces or otherwise alters the original functionality of the licensed software. So if you've got another program running side by side with your reciprocal public license software that is somehow modifying its function, right? Like maybe it's closely related to the APIs or you're doing a callback or something like that. You can kind of expand the scope of this copy left software distribution requirement. Now I don't know if that's a good idea. I think there's probably a reason why a lot of people haven't come across reciprocal public license software. But it's out there as an OSI approved license. So if you're really interested in making sure someone's distributing all of the software that they use to host your software, you might want to distribute only through reciprocal public license. I suspect not a lot of people will use your software at that point because they're scared about that scope. But there's an OSI approved license out there for you to use. Now just to get to the stats, I don't plan on getting through all of my slides because I went through and had a fairly comprehensive spreadsheet until I got bored and gave up keeping track of things. But here are some things that I thought were interesting about these OSI approved licenses. And I say over because towards the end around license 75, I just stopped updating my spreadsheet for common things. But there are over 30 OSI approved copy left licenses that are copy left. I actually think it's probably about 50-50. So the idea that copy left isn't popular, it's not true. Most businesses who are writing open source software licenses are making them copy left. Copy left is what businesses want. Over 24 of these licenses have a choice of law clause. So for those of you who aren't lawyers, that's determining what jurisdiction's law is gonna apply, right? So if you use this license, you might be finding out that you're subject to the laws of the Netherlands. Even though you've never been to the Netherlands. Or Japan, if you're using a particular font. Over 18 of those have a hard-coded specific jurisdiction. 19 of the licenses have a choice of venue. That means the court that you're gonna have to bring your cause of action in, where you can sue, right? You might find yourself, even though you've never been to Colorado, you've never been to the United States, all of a sudden you find out that if you wanna sue to enforce your license, like if you use the reciprocal public license, you've gotta go to Colorado to bring that lawsuit. Which would be weird, right? If you're suing the guy down the street from you in Belgium and you've decided you both mutually agreed that the only court you're allowed to use are the Colorado courts, a little strange. And there's, I thought this was kind of weird. There's one license approved by OSI, and this isn't really a problem. Like I think this is fine. That doesn't have a warranty disclaimer. And I just kind of like assumed warranty disclaimers were universal to all open source licenses. And I wasn't even keeping track of it until I came across this one. I was like, oh, maybe we should start reading these warranty disclaimers. So here's a list of the jurisdictions that I found amongst those licenses. I won't read them all. New York was the most popular. I thought California was gonna be in the lead for a while, but it turns out New York was the most popular. And these actually really matter. So some of these jurisdiction selection clauses don't actually just apply to the license. But one of them says any action or suit relating to this license, right? So that could actually be like on your contract claims, your personal injury claim. Like if you're using a piece of hardware that's running open source software that's licensed underneath the open software license, and it injures you, right? It's a lawnmower because lawnmowers are gonna have free software in them now if they don't already. All of a sudden you have to sue for losing a finger in whatever jurisdiction that the open software license actually defines. Some of these jurisdictions can be modified by the licensure, they just kind of, that little default to one location, but a lot of them can't. And it's a very similar situation with venues. This is actually really interesting. I do, my company does a lot of contracting with state and local governments in the United States. So there's some interesting things there. So some of these jurisdiction selection clause and venue selection clause depends upon who you are or your role there. So underneath the European Union public license, you'll actually pick the law of the country where you have a presence. And if not, it defaults to Belgium. Which I thought was, you know, that actually kind of made sense. Rico, when they wrote their public license, they had a pretty normal clause. I'm like, well, we're gonna do this in California. You can only sue us there. That's where all the lawsuits are gonna take place. But specifically, Rico can sue for an injunction anywhere they want, right? So they can come after you and stop you from doing stuff. But to resolve the ultimate dispute, you have to come to California, right? Cause why not make yourself privileged? So just reading these things are actually kind of interesting, right? Like you can't just look at the conditions that you're dependent upon. You also have to look at the more legally boring kind of stuff. Same thing with warranties. No license to the original work is granted except underneath this disclaimer. Well, what's interesting about that is that jurisdictions actually restrict what kind of warranties you're allowed to have. And they might invalidate your warranty if it's too broad. Some jurisdictions will say that if you disclaim a warranty so broad that personal injury and death can't be compensated, you're not warranting against that, then you gave no warranty at all. Well, if you gave no warranty at all, you don't have a license, right? So if you happen to be in one of these jurisdictions and you're using a license that makes your license dependent upon a warranty that's illegal there, you're committing copyright infringement. So maybe we need to pay attention to those a little bit more. I know I'm getting close on time here and I don't plan on getting through slides, but there's other interesting things here, too. Third-party beneficiaries, that's not a thing underneath open-source licenses, right? The only person who can sue to enforce is the copyright holder. Well, unless you're using the adaptive public license, in which case recipients, any recipient of the software can sue any other recipient of the software. Or if you're using the NASA open-source agreement, in which case the United States government is allowed to sue you. Anyone like jury trials? Don't use the Eclipse public license version one. Like you won't be having one. There are some other weird things, too. I won't go through these in detail. Attribute requirements, if you're using the attribute assurance license, you've got to sign it with a GPG key, which I thought was kind of weird. So that's my time, but I just wanted to kind of make the point of when you're using open-source licenses, read it because you might be surprised at what you're agreeing to.