 Good. Hello. Welcome to Open Source on Ramp, where we explore various IT subjects from an entry level. One of the most important parts of Open Source is the licenses that are used. You can't have Open Source without a license. So here to shed some light on this very important topic is Jeff Shapiro, the license scanning manager for the Linux Foundation. Thank you. Thanks. Thanks, everybody. Can everybody hear me okay? Great. So as Eric mentioned, I'm the license scanning manager for the Linux Foundation. I just joined pretty recently. I'm going to be talking about a lot of the basics about licenses and then dive into some more of the finer points and technical things about licenses. I just want to, before I start, I want to say that I like my job and it's really interesting, but licenses can also be really boring. So let's just say, talking about licenses is not the most exciting topic that there is, but it is still something that is necessary. So it's boring, but it's still really important. So when I started recently at Linux Foundation, my boss introduced me to OKRs for anybody who's familiar with those. So I thought it would be fun to have an OKR objective and key results for this talk. So my objective is to teach you about open source licenses and why they matter. My key results are your objectives. So your objectives for the talk are to understand different open source license types and attributes, sort of all the different things that go into an open source license. Hopefully have some clue by the time we're done on how to get started identifying license conflicts. And if it's applicable to you, if you're creating a project, say, for example, you'll have somewhere to start if you're going to choose your own open source license for your own code or your own project. Now, disclaimer, I am not a lawyer. I know a lot about licenses, but I'm not a lawyer. I'm an engineer. My goal is to talk to you, engineer to engineer. If you're not an engineer, it's OK. But I like to talk to people, developer to developer, to sort of say, this is as a developer, this is what you need to really care about. You may not need to care about all of the legal intricacies of the license, but as a developer, these are the important things. And also, since I'm not a lawyer, I'm not giving you any legal advice. That's really important to say. The lawyers tell me that that's really important. So this is a quote from Wikipedia that I kind of like. I'm just going to read it really quick and then point out what's the most important thing here. So what is a license? We're all familiar with, say, like a driver's license. A driver's license gives us a ride or privilege to drive a car. So a license in general is something that gives us a ride or a privilege. In this case, an open source license. So according to Wikipedia, a license defines the rights and obligations that a license or grants to a licensee. Open source licenses grant licensees the right to copy, modify, and redistribute source code. These licenses may also impose obligations. So the important things here are this, I don't know if you can see this little laser, license or that is the person who essentially authored or owns the code. And licensee, that is the user of the code. Copy, modify, and redistribute. Those are key terms that are very common in most, if not all, open source licenses. And the very last thing may impose obligations. That is also key. These obligations, in addition to giving you these rights, the obligations are things that are requirements. They're the things that can get you into trouble, theoretically, if you don't follow them. So let's look at these in a little more detail. Again, the common rights that are granted by open source licenses are the right to use, inspect, and copy the source code. Because that's what open source is all about, right? We're all familiar with open source. We all use and love open source. So in order to do that, we have to be able to read it, have it available, copy it, redistribute, make modifications, et cetera. And very important, create derivative, excuse me, derivative works and redistribute those derivative works. Sometimes it's called a derivative work. Sometimes it's called combining the code. But you're not, you know, what's the point if you're just taking that open source? Sometimes we do this. Sometimes we take that open source, it's a package or a library, and we make use of it, and we re-distribute it exactly as it is without making any changes. But one of the beauties of open source is, of course, we can modify it, we can make it better, we can fix bugs, we can patch things. So the rights give us the ability to do that. Now the obligations that I talked about, now I just want to point out, these are examples. Not every open source license has all of these obligations, and there are lots of other obligations that aren't listed here. So these are some common examples of obligations. Provide attribution. That just simply means acknowledge that you didn't write the code, you got it from somewhere else. So that seems pretty basic. And in fact, it's a very, very common obligation for what we call permissive licenses. So I'm going to talk about what that means in a moment. But the attribution or acknowledging, telling people where you got this from is a very, very common obligation. Contribute changes. That's not as common, but some open source licenses will request or even require that if you make changes to the open source project and then redistribute them, they want you to provide those changes back to the open source project. So that's not as common, but it does happen. Provide derivative works under the same license. This is common for what we call copy left licenses, which I'll describe in a minute. Provide derivative works under the same license. What does that mean? It means you get open source from somewhere, you use it, you combine it with your own code, might be more open source or proprietary code, but you are essentially modifying it, making changes, adding things to it, combining it with other projects or other libraries. There are licenses that have obligations that say if you use this open source, you're welcome to do all of these things, and then you create this derivative work or combine it with something, and then you want to send that out into the world as open source and provide it to other people or post it on GitHub. If that obligation exists, it's saying that you have to provide that derivative work under the same license that you got this code in the first place. So that's an important obligation and important distinction between different types of licenses. Another thing that's very common in most open source licenses is to disclaim warranty and liability. How many people were at the keynote this morning? Most of you guys. Do you remember, I'm sorry, I don't remember the gentleman's name who said this. I think it was the gentleman from Google. Do you remember when he was talking about as is? Most people know what as is means, but as is means, here it is, take it or leave it. If it doesn't work, I'm sorry, but there's nothing that I'm going to do about it. That's the very non-legal definition. So, disclaim warranty and liability. Most licenses will say this software is provided as is. There's no warranty. I accept no liability. You use it at your own risk. So again, you are agreeing by using that project or that package, you are agreeing to use the software as is. So now I'm going to talk a little bit more about some of the things that I said earlier, the different types of licenses. Open source licenses are generally categorized in two ways, permissive and copy left. Many of you may have heard this term before. You may already know exactly what it means, or it may be confusing. Permissive licenses generally grant more rights with fewer obligations. So they allow using that project or that open source in most situations. And as I said, they typically have very few obligations. In fact, the most common obligation with most permissive licenses is attribution, which we talked about, acknowledging where it came from and that it wasn't your work to begin with. Copy left licenses are a bit different. They generally grant many of the same rights to use copy redistribute the code, but they generally have some very specific obligations about what you can do with it if you redistribute or downstream. Copy left licenses are designed to ensure that the code will remain open source. And I'm going to give more examples of how that works and what it means in a few minutes. But generally it means that with a permissive license, you can create a combined work or a derivative work and you can release that under a different license because the permissive license gives you the right to combine and create derivative works and then redistribute it under the license of your choice typically. And the copy left license does not allow that. Copy left license says if you use this project or this code, you typically need to redistribute any derivative or combined works under that same license that you got that open source from. And neither one is better or worse or right or wrong. They're just different. It's a different philosophy and like we've talked about diversity a lot today and yesterday, I think it's great that we have this very large diversity of licenses. Okay, there's only two categories but there's lots of licenses in each one. But you have a choice, right? It's a preference or it depends on your philosophy or what your goals are. And we'll talk about choosing a license later on. Copy left can also be subdivided into strong, excuse me, strong copy left versus weak copy left. So I'll talk a little bit more about that as well. One point I want to make which I said, I think I touched on copy left ensures code will remain open source. So that's including derivative works. And that is kind of one of the main points for choosing a copy left license is that you want to be sure that those derivative works remain open source. So with a permissive license, you are allowed to combine open source with proprietary code, for example. And you are allowed to release that combined work under whatever license you choose, including a proprietary or commercial license. And with a copy left license, you usually can't do that. There are a couple other classifications that I want to mention as well. Public domain, public domain is not actually a license but it is still worth mentioning. I'm going to talk about copyrights in a minute. Public domain specifically means that the code no longer has a copyright, that the copyrights have been disclaimed. And if something is public domain, it can essentially be used anywhere, anytime, for any reason, for anything. But it's also worth pointing out that the term public domain can have different meanings in different regions. So what I've described is primarily true in the United States based on United States rules and laws and regulations, but it may be considered or may be treated a little bit differently in other regions. And proprietary. As we all know, there are plenty of commercial companies out there that sell products based on proprietary code. And many of those contain, in fact, most of those probably contain some amount of open source in them. But they are typically released under a commercial license, which is often called a EULA or TOS. So EULA is an end user, those are generic terms. EULA is end user license agreement. Everybody's probably installed something on their laptop and had to click through a couple of license screens to say they accept the license. That's typically called a EULA, end user license agreement, or TOS is Terms of Service, more common for, say, a web application. But it's important to know that in the case of proprietary code, the source may or may not be disclosed. Now, typically it isn't. Typically all we get is a binary. But there are cases where proprietary code actually has the source disclosed. There are companies that publish SDKs where you can buy a commercial license for some development kit and they actually give you the source code. But it's still under a commercial license. So it's important to know that just because you can see the source code, that does not by itself make it open source. There has to be an open source license that gives you those rights. So again, if, and this is true also in my experience doing license scanning and compliance, engineers often think if they find random snippets of code on the web somewhere, that's great. I've gone to Sourceforge or I've gone to GitHub or somewhere and I found this piece of source code and there's no license information to be found anywhere. Just because you found source code, that does not by definition make it open source. There has to be an open source license. So now I'm going to give some examples of the different license types. Again, most of you have probably heard of these or seen them or you may be very familiar with them. I'm going to start out by saying my point on the bottom, most if not all of these license have multiple versions. So permissive licenses, for example, and these are many of the most common ones. So BSD, which is Berkeley software distribution, there are, there's the BSD0 clause, there's the BSD2 clause, the BSD3 clause, which is also called the new and revised BSD license, there's the BSD4 clause. So there's a bunch of different versions. MIT, not so many versions, but still a couple. Apache, most people know about Apache 1.0 and 2.0. 1.0 is now deprecated and 2.0 is commonly used. The artistic license, which is also sometimes known as the PURL license. CC's, Creative Commons. Notice that CC up here is CC-Buy and down below, that's a different license. So weak copy left, let me just take a minute, excuse me while I take a drink. Let me take one minute to talk a little bit about the weak versus strong copy left. The weak, so they both have the same general principle of having an obligation that says, if you release or distribute derivative or combined works, they must be under the same license. The strong copy left has basically stronger obligations or restrictions. The weak copy left typically has obligations that are specific to how the work is combined or how the derivative work is created. And I'm going to talk about that in more detail in a minute. But just for example, in many of the weak copy left licenses, if you have sale a dynamically linked library, that is a common example of when the copy left provision does not apply. In fact, the first one on that list, the LGPL, the original version of LGPL was actually called the library GPL. So GPL is the GNU general public license, in case you didn't know. So the first L originally stood for library and then they revised it and it now stands for lesser, the lesser GPL. And they called it the library GPL originally because they were giving an exception for dynamically linked libraries. So if you use the source code from this LGPL project and you mix the code together, then the terms, the obligations about the copy left applying this license to your code too, that all applies. But in the case of dynamic linking, they say we give you an exception. If you just use a binary version of my library and you're dynamically linking it, then you can still release all your own code under your own license, whatever you choose, and you don't have to worry about the terms of the LGPL. So those are the general principle behind the weak copy left license. Then there's the eclipse public license, Mozilla public license, common public license, GPL with exception. Let me explain that in a second. And then under a strong copy left is the standard GPL license. There's the older versions and then the most common ones in use today are the GPL v2 and GPL v3. You will often see, if you look at code with the GPL license, that it often says you can use this code under GPL v2 or later, which means at your discretion, you can apply any later version of the GPL to that code if you wish. There's one very, very notable exception to that. I mean, there are other exceptions, but the most notable exception to that is the Linux kernel itself, which is under GPL v2 only. That means you do not have the discretion to take the Linux kernel and redistribute it under a different version of the GPL. It is v2 only, and that's the way it's going to stay. I'm not going to get into the discussion of why that is, but we can talk about that later, perhaps. The AGPL is an interesting license. It stands for a Faro GPL, and it is one of the notable exceptions in that its obligations have to do with their network-based. Most of these copy-left obligations come into play with distribution, which I'm going to talk about. In the case of the AGPL, if software is hosted on the same server, then those obligations also apply. Then the last one there is CC by SA for a share like. Just very briefly, GPL with exception. How many people know what autocomf is? Anybody? A few people? Okay. Autocomf is a very common Unix or Linux utility to create config files. It's under a license called GPL with autocomf exception. That exception says, so it's under the GPL license, and that autocomf exception says, by the way, if you are, I'm paraphrasing, it says, if you are using autocomf to generate your own config files because it basically does code generation, and there's often confusion about how licenses apply with tools that generate code. Not so much with compilers, because that's pretty well understood, but when there's a lot of code, when there's tools that specifically generate code or generate scripts, sometimes there's confusion. The GPL with exception says, if you use this tool to generate these scripts or these config files, those config files are not subject to the terms of the GPL license. They're under your own license or whatever you choose. Another very notable exception, another notable example to the GPL with exception, is a long time ago when Sun Microsystems first released Java, they came up with the Sun GPL license with class path exception. I don't want to take too long talking about that, but it was basically so that if you, since Java doesn't use dynamic linking, if you use jar files where classes are loaded using the Java class loading, it basically said that your code, even though you're sort of combining it with code from the JDK, your code is not subject to the GPL license. Okay, so now I'm going to give a brief example of one particular license, one of the most common permissive licenses. This is the MIT license. So people, this is a, the MIT is a pretty brief license, but just looking at it, okay, it looks like a bunch of legal mumbo jumbo. Sorry to the lawyers in the back there. So the first thing we see is we've got the copyright up top. Then we've got this paragraph that says permission is granted free of charge, et cetera, et cetera, to use copy, modify, merge, publish, distribute, sub-license, and or sell, et cetera, et cetera. So that is granting you the rights. That's the whole thing about granting you the rights. This is what makes it open source. That second piece in the middle there, the above copyright notice and this permission notice shall be included in all copies, et cetera. That's the obligation. In this case, it's the attribution. So this is the obligation. So if you look at other licenses, there may be much longer Apache or GPL, for example. It may take you a lot more reading and dissecting to figure out exactly what the obligations are. Consult your legal counsel to be sure. But those are the, in this case, that's the obligation. So it's attribution. And then that bottom paragraph is the disclaimer of warranty. It's the as is. Okay. I want to point out that a copyright is not a license and vice versa. So every creative work typically has a copyright, a book, a piece of music, a movie, software. The copyright typically exists whether or not the copyright notice is explicitly stated. So if you write a piece of code, you own the copyright to that even if you don't put a copyright notice up top. Now, you should put a copyright notice up top because that's good practice. But you still own the copyright even if you don't put that notice up top. The copyright is typically owned by the author, but in many cases, it's owned by an organization or a company. So if you work for a software company and you are writing that code as an employee of that company, then typically that company will own the copyright. The copyright owner is the individual or organization that gets to decide what license that code is under. Okay. So that's really the distinction is you own the rights and you get to decide what the license is. I mentioned this before. If you can't identify the license, the code may or may not be open source, but you can't take it for granted. If you can't identify the license, you kind of need to assume this may not be open source. And then I mentioned there's an exception about the copyright owner decides which license applies. So this isn't exactly an exception, but some of you may or most of you may have heard of the contributor license agreement. So this is another quote I stole from Wikipedia. A contributor license agreement CLA defines the terms under which intellectual property has been contributed to a company or project, typically software under an open source license. So what does that mean? It means that if an open source project has a CLA, then if you are going to contribute code, because many people here are contributors, of course, if you're going to contribute and there is a CLA, then you need to agree to the terms of the CLA. And typically what that means is that that CLA spells out you're contributing, you are agreeing to grant certain rights to the project to distribute and release your code under the license that they choose. So you will, of course, hopefully will know what that license is before you contribute. But basically you are granting rights to the maintainers or the owners of that open source project when you agree to the CLA. An alternative to the CLA is the developer certificate of origin. So this was actually introduced by Linux Foundation. I'm not going to discuss philosophy of better, worse, or right or wrong or anything of that sort. But the DCO was created as an alternative as perhaps a lower barrier to be able to contribute code. And many if not most Linux Foundation hosted open source projects have a DCO and not a CLA. And it is essentially the contributor is certifying that they are either the original author of the code or if they're not the original author that they have the right to contribute that code. And if you're not the author maybe it is a derivative work or something that you've modified and then you're contributing it to that project. That URL on the bottom there is a link to the full text of the DCO. And I would encourage everybody to take a look at that. It's not very long. Dual licenses. Now that you think you've got everything about licenses figured out you're going oh no this project has two licenses. What does that mean? So some projects are released under more than one license. So these are two examples. I just chose them. Pearl is released under the GPL or artistic license. In this case if you're using the Pearl source code you get to choose the license that you're using that under. So it's your choice. Why would projects do this? Well some projects want to make it easy for people who are doing different types of open source projects to take that code and use it. And we're going to talk about license conflicts in just a moment. So maybe this solves some license conflict problems if you get to choose the license you use it under. Another example is the pretty well-known GUI toolkit QT which is released under the GPL or commercial license. Why would they do this? Well QT is a commercial company. They're in business to make money and they sell a product called QT. But they also want everybody to be able to examine that code and see how great QT actually is maybe try it out. They also want people who are using it for their own personal use and not redistributing because remember GPL comes into the obligations come into play when you create derivative works and redistribute them. So if you're using it for your own purposes maybe you're an academic institution maybe you're you know whatever you know you're just somebody doing code in your garage. You can use QT under the GPL license without paying anything for it. But if you're another company creating a commercial product that you're going to sell and you want to use QT to create your product which lots of companies do then they want you to buy a commercial license. This is actually pretty common. A quick question in the back here. So most of those terms have to do with distribution whether or not you're selling it. It doesn't matter whether you're whether you're selling it or so I'm not sure I'm not sure I can answer that question quickly but feel free to talk to me about that but let me just say that if you don't purchase in the case of QT either you purchase a commercial license and then you use QT under that commercial license and the GPL does not apply at all or if you don't purchase the commercial license it is by it is under GPL and then and so your choice is to purchase the commercial license but feel free to to ask me that in the back the JSON license. So if I remember correctly the JSON license is based on on the MIT license but what exactly is the question? There's two questions. One is the license is used restrictions but I mean the license sense of for example don't use this for X type of project still considered open source. Ah there may be some debate about that. It may still be considered open source but there is actually debate about certain like like there's a license this is not exactly an answer to that question there's a license called the MIT do no evil license it says this is under the MIT license use the software for good not evil the lawyers have a have have fits about this and they basically say you know don't use it because there's no way to define what's good and evil it's impossible so I'm actually gonna I'm actually I'm I'm running a little short on time so I'm gonna punt on that question for now. Okay when do the obligations take effect? So we've talked about this somewhat already but most obligations are triggered by distribution when you redistribute the code doesn't matter if you're giving it away for free or selling it the notable exception to that is the AGPL which I talked about briefly which those those obligations are triggered by by hosting on the same server integration so this is particularly applicable to those weak copy left licenses is is your code fully integrated like source code mixed together is it dynamically linked or separate executable so commercial companies all over the world use the Linux kernel under the GPL v2 how is it that they do that well the kernel is a separate executable it's a separate layer you've got kernel space and user space it's a completely separate layer say from your application so unless you're actually in there doing doing stuff in you know tinkering with the kernel itself if you are just using the kernel on your server you're fine because it's a completely separate process separate memory space separate executable have you modified the code those are that can trigger certain obligations so let me talk about conflicts I'm gonna try and step up the pace a little bit so I don't run out of time mixing different open source licenses so many licenses are compatible with with each other but not all so you have to look at the obligations to see if any of them are conflicting I give an example here specifically between the apache and gpl license the apache 2.0 and gpl v3 are considered compatible but it's worth noting that it's one way it's not a it's not a two-way street if you combine works under apache two and gpl v3 the combined work is now under the gpl v3 but earlier versions have conflicts so you need to you need to be careful about that mixing open source with proprietary code this is a big topic there's a lot to say about it but let me just say that most permissive licenses are compatible with proprietary code because they have very few obligations most copy left licenses typically have some conflicts with proprietary code but in bold there depending on how the code is integrated or combined so I talked a bit about that already so you really need to know if you're using open source with a copy left license you really need to know how you're combining it and integrating it with with your proprietary code here's a quick graphic example of of how that works so the open source is on the left in the middle we are combining the code there so you can see from up the top you're combining permissive with proprietary code you are allowed to now re-license that and distribute it under a proprietary license if you mix weak copy left with proprietary code you can do that and you can still your proprietary code can remain proprietary typically as long as you aren't violating the terms of the license and so in this case I'm showing an example of dynamic linking so like if it were lgpl and you were using it as a dynamic library for your derivative work then then the proprietary code would remain proprietary and on the bottom there strong copy left but what you get out the other side is is open source okay contributions so many of you are hopefully contributors if you are contributing to an open source project think about what is the project license hopefully there is a project license if there's no project license you should talk to the maintainers and ask them to clarify that is there a CLA or a DCO and are you comfortable with those terms the bottom one is important do you have the right to contribute the code in the first place which is kind of the point of the DCO so are you making a contribution of your own code or somebody else's code choosing a project license who is your audience and what are your goals do you want to be proprietary code friendly do you want to ensure that your code will all including derivative works will always be open source my brief recommendation is stick with a well-known license unless you have a really good reason not to because then everybody will know what it means choosing a permissive license again this is for creating your own project you want to be say proprietary code friendly and you're happy with people creating derivative works and relicensing them if they choose also it's important to note that the Apache 2.0 license includes explicit language about patents a lot of the other permissive licenses are are either don't include explicit language so if you care about patents that's worth taking a look at choosing a copy left license again neither one of these is better or worse or right or wrong but choosing a copy left license you want to be sure that combined works or derivative works will be released or redistributed under that same license if that's important to you then you should choose one of those types of licenses and whether you choose the weak or strong copy left license will depend on your ultimate goals okay a couple of resources that hopefully will be useful this is very really quickly because I'm out of time open source initiative is a great reference for looking up specific open source licenses as well as the open their open source definition the spx license list also has a great reference with a list of not every single licenses out there but but most of the common licenses and some that you probably haven't heard of the reuse creates some has some tools that help developers apply licenses to their own code and make sure that they're done in sort of a standard fashion so that's useful the GNU and free software foundation has a great reference with information about all the various varieties of gpl licenses and a lot of other licenses and and their opinions about where conflicts may be and Apache has something similar a great reference and FAQ with information about their licenses and also some opinions about where conflicts may occur and last but definitely not least Linux foundation provides a free training called open source licensing basics for software developers so if you aren't tired of licenses by now please take a look at that course and you can learn even more so thank i know i'm out of time thank you very much appreciate your your coming to talk to hear me talk today