 This is a Birds of Feather session, which is meant to be more of a conversation and discussion. I've given this talk on open source licenses a couple times before, and it's always been more of a presentation. So what I want to do today is talk to you guys and first get an idea of what you want. And I don't know how many virtual attendees there are. So I think what I have to do is work with the feedback I can get from you guys. So to start with, I'm Jeff Shapiro, I work for the Linux Foundation, I'm the license scanning manager. So I've been working with open source licenses for a long time. Let me start by asking all of you in the audience, by a show of hands, how many of you know practically nothing about open source licenses? Okay. How many of you know a decent amount about open source licenses? Okay. It's kind of a little more than half, no, almost nothing, and a few of you know no, no more. How many of you consider yourselves to be an expert in open source licenses? Nobody. Okay. So my presentation normally takes about 30 or more minutes. So what I'm going to, but I'm not going to do the whole presentation in that format today. I'm going to go through some basics and go through, skip over some things. So I want to allow, allow plenty of time for discussion and questions because that's the format for today for a birds of a feather is supposed to be more of conversation and discussion. But because a lot of people in the audience don't know very much about open source licenses, I think you can't ask good questions unless you have some basic information. So again, I will be skipping through these slides fairly quickly, but the slides are available online. So you can encourage you to go back and take a look at them more closely later on. My goal is to basically teach you about open source licenses and why they're important and what does that, what does a license mean? And then specifically for today, because it's a birds of feather format, my goal is also to answer as many questions as possible and listen to, listen to what you guys want. So a license defines rights and obligations that a license or grants to a licensee. What does that mean? It means that the person who writes the code, the author, they get to choose what license it's under. If they don't choose anything, it's not open source. It's essentially like, I mean, you can still put the code up on the internet, but if you don't specify a license, then it doesn't give anybody any rights to use it in any particular way. So an open source license gives licensees, the users of the code, the right to copy, modify, and redistribute. And those three things are very important, and that's essentially what defines open source or what makes an open source. And it's also very important that most licenses have obligations. So the rights that you typically get with an open source license, as I said, let you inspect and copy the source code, make modifications, and create derivative works. So you are using that open source, you're mixing it with other open source or with maybe commercial or proprietary code. And the obligations that you typically have with most open source licenses are often provide attribution, so you're acknowledging that you're using it. You may have to contribute changes if you make them, depending on the license. Depending on whether the license is, there's two classes of license, which I'll talk about in a minute. Some of them require that if you create a derivative work where you combine the open source, then you are required to license that new work or that new body of code under the same license as the open source. And also very important, almost all licenses will disclaim warranty and liability. So you use it at your own risk. So there are permissive and copy left licenses, and the permissive licenses generally allow, so here's some examples, BSD, MIT, Apache, you may have heard of some of those license, Kubernetes for example, and many of the Linux Foundation-hosted projects are under the Apache 2.0 license. They generally allow you to use the code for almost anything you want. The copy left licenses, like the GPL, LGPL-style licenses, they also allow you to use the code, but they have stronger obligations. So if you have your own code that you are writing and you are mixing it with open source that's under your GPL license, that will, the GPL license requires that the combined work, your code plus the open source together, that that be released if you distribute it, if you send it out, you don't have to sell it, just even giving it away, then you are required to license that new combined work, including your code under that GPL license. And that's why they're called copy left licenses. They're sometimes called viral licenses, not everybody likes that name, but it is a common term. So one of the main purposes of a copy left license is to ensure that the code will remain open source. So if you have code under a permissive license, like a BSD or MIT license, and you combine it with your own code, you can then re-license all of that under a proprietary license. Let's say you work for a company, your company may want to sell that as a product, and they can re-license that combined work, and then that original code, excuse me, the open source that you use is still available to anyone else under the same open source license, but the combined work is now under the license that you choose, because the permissive license allows you to re-license the combined work. The copy left license does not allow you to do that. So let me take a moment and stop, again, since this is more of a discussion format, how does that make sense for the people who raised their hands and said, I don't know anything about open source licenses. Does that make sense? If not, I want to know. Tell me if you have questions. Go ahead. Actually, do we have a mic that we can give to the audience members? That would be really helpful. Great. Thanks. Speak loud, please. Oh, maybe the mic's not on yet. Okay, go ahead. So how does the strong copy left license affect providing service for that? How does the strong copy left effect repeat? So if this is an open source project which has, say, AGPL, right? So if we create a derivative software out of that, that should be AGPL. That's my understanding. I'm not sure I heard the whole question, so let me repeat it back. How does the strong copy left license affect providing services for that software? Providing services for the software. Yeah, so we host that software and provide that as a SaaS service. Okay, that's a great question. So it depends on the services that you're providing. If you're providing tech support or if you're answering questions or giving tips on how to use it, if you're not actually distributing the code, then you can provide whatever services you want and the license doesn't impact your providing services. In most cases, the license takes effect when you distribute the code or redistribute it. Okay, so quick question there, by distribution. So if I host it myself, for example, there's a database, I host it myself, I provide that as a service. I'm sorry, one more time, sorry. There's a project which is a database that is under AGPL. I host it in AWS and then provide database as a service. Okay, so you're hosting it. Does that contribute, does this constitute as a distribution or it's? Did you, did you, I didn't catch which license you mentioned. AGPL. AGPL, yeah. Okay, so the AGPL, I haven't gotten to this yet, the AGPL is a version of the GPL, it is a strong copy left license. The A stands for a FARO, so a FARO GPL. The AGPL is a little bit different than most other licenses. The AGPL says, so other licenses typically say these obligations take effect when you ship the code, you distributed somebody. The AGPL is different. It says these obligations take effect if you use our code on your server and it's on the same server or the same network as your other code. So it's license obligations basically reach out and touch everything on the server or on the network. So it is a lot, it's a very tricky complex license if you are having a hosted solution on AWS and by the way, I should preface this with saying that I'm not a lawyer, I'm an engineer. Even if I were a lawyer, I couldn't give you legal advice in this forum. I would need to advise you to consult your own legal counsel. That's my warranty that I have to give. But the AGPL will affect other things on the server and it really depends on what you're doing with that. But if you have other code on that server, the AGPL will most definitely or most likely almost certainly affect everything else on the server. Now not necessarily the operating system, you have to think about what layer it's at, but if you are using AGPL licensed code on a server, it will impact and very likely require you to re-license your own code on the server as AGPL. If you are mixing multiple components, open source components on that server, you need to be careful because you can't re-license somebody else's open source that they've released under a specific license. So you may need to check to see if the licenses are compatible. Just because you can do something doesn't mean you should do something. I think an analogy that I like with open source licenses is most people here, probably everybody here has a driver's license and drives on the freeway at some point in time. Most areas of the country have a speed limit on the freeway of 65 miles an hour, sometimes a little more. How many people here in the audience, let's see a show of hands. How many people here drive exactly 65 or less all the time? Okay, I don't see a single hand. I'm not raising my hand either. So we all drive 70, 75 sometimes. So open source licenses are kind of the same way. You can do something that violates the terms of the license, but it doesn't mean that you should. You can use code under a BSD license, which is very permissive, and forget to acknowledge or give attribution. It doesn't mean that your program is going to implode and stop working. It just means that you didn't follow the terms of the license. In many cases, nothing will happen. The people who wrote the code could come back and say, hey, you didn't give us acknowledgement. If you're a small company or an individual, that may be pretty unlikely. I'm not suggesting you do it. But if you're a really big company, you have more risk exposure, you need to be more careful about it. Everybody should be careful about it, but you need to look at your risk exposure. If you use AGPL to get back to your question on an AWS server, then you want to look at all the other open source components that you're also using in your service, whatever you're doing. And you want to see if the other licenses are compatible with AGPL. I have some resources that I point out on one of my last slides that you can look at, including the Free Software Foundation website that talks about license compatibility. So you can see which licenses are compatible and not compatible with AGPL. And so you want to check everything else you're using. And then, again, your own code will be impacted by that AGPL license. So if you have more questions about that, why don't you reach me after, let me move on a little bit and also get some other questions. So I did jump ahead a little bit and talk about some of the impacts of the copy left licenses. And I give some examples here, including the AGPL. This is a license example that I normally talk about in detail. I'm not going to talk about it, except to say that this is the MIT license. And if you read through it, it gives it an example of basically what I've talked about. The top part are the permissions or the rights that the license gives you. The middle paragraph, that middle sentence says, notice shall be included. That's your attribution. That's the obligation that you have. You have to give attribution. And the bottom is the warranty disclaimer, the software as is. I want to point out that a copyright is not a license. I'm not going to talk about this in too much detail at the moment. And then we have a few other things that people in the open source community know about that are different than open source licenses. We have a contributor license agreement, which is, it's a license, so it's an agreement, but it's not the same as an open source license. What the CLA is, what it does is it, you as a contributor or an author, if you are giving code to an open source project, Kubernetes or something else, it basically gives the project the rights to use the code that you're contributing. And it also requires that you are giving them the right to re-license your code or license your code under the same license as the project itself. So if you go to the Kubernetes GitHub page, and you'll see contributing.md, and you go down a couple levels, and you'll find a contributor license agreement, and you'll see the legal text that says, number one, you have the right to contribute this code. You are the author or otherwise have the rights to contribute it. And you are giving us the right to release it under the project license, which in that case is Apache 2.0. There's also something called a DCO, Developer Certificate of Origin. This was created by the Linux community a while ago. And a DCO is a bit different than a CLA. A DCO is essentially a certificate or a representation saying, I am the author of the code, or I otherwise have the right to contribute the code. So there's some similarities between the two, but they're not the same. And then I talk about SPDX. I'm going to come back to that later if we have time. Just simply, most of you, hopefully you've heard of a bill of materials or an SBOM. The SPDX, one small piece of the SPDX is something called a license identifier. So if you are contributing or writing your own open source project, it's a really good idea to use these license identifiers. It makes other people's lives much easier as far as identifying the license that the code is under. There are examples of dual licenses. Let me go back one sec. This is an example of what happens when you mix open source with proprietary code, which is a common use case if you're a downstream user of an open source project. So at the top, we have permissive open source, mixing it with proprietary code, and what we end up with is proprietary code. In the middle, we have a weak copy left license such as LGPL, Mozilla, Eclipse public license. And what we end up with is a combination where the way you are releasing the code actually matters a lot. So are you releasing, are you combining source code and compiling it into one binary object or one process or one executable? Are you releasing things as separate binaries that are dynamically linked? So those things make a difference specifically for these weak copy left licenses. They can make a difference other ways, but specifically with the weak copy left licenses where it matters the most. And if you mix open source under a strong copy left with proprietary code, what you end up with is open source under that same copy left license. Let me go to, let me ask some more questions. So I asked, you know, what's your level of expertise in licenses? And a lot of you were, you know, pretty, pretty new to licenses. Let me ask by a show of hands for everybody here. How many of you are are mostly consuming or are an end user of open source? Okay, it looks like about half. And how many of you are contributing code to open source projects? Also roughly about half. So that's a good mix. So if you are consuming open source, then you need to pay attention to your use case. Are you mixing it with other open source? Like the gentleman here who talked about mixing it on the server under AWS. Are you mixing it with proprietary code, which I gave the example of. So you need to, you need to think about that. That makes a big difference, you know, whether you are looking at open source under a permissive versus a copy left license. If you're contributing code, then, you know, are you writing all that code yourself? Excuse me. Are you mixing your own code with other open source and then contributing it? So you have to think of those use cases too. If you're writing all your own code, then you're going to most likely be contributing it to an open source project under either a CLA or a DCO. So you want to, you want to take a careful look at those. If you work for a company, most of many of us work for companies. If you work for a company, then the company may be responsible for the CLA or the DCO. And then you want to check with your legal team at the company that you work for. If you are mixing your own code with other open source and then contributing it, again, you have to be very careful that you have the rights to do that. How many of you are writing a new open source project from scratch and choosing a project license? Okay, a couple of you. So a few of you. If you are writing your own and you're choosing a license, also think about your use case. I like that word a lot. So, are you, is your intention to make that code available to as wide of an audience as possible? You want anybody and everybody to be able to use it for whatever they purpose, whatever purpose they like. You just want to share the code and you're happy when people use the code. It doesn't matter if they're giving it away to somebody else or if they're going to mix it with something else and sell it. You don't care. Then you probably want to consider a permissive license. Is your use case that you are writing open source and it's really important to you that that code always remain open source. If other people want to use your code, great. You're happy to have them use it. But if somebody wants to sell the code, then you don't want them to relicense your code. That's fine. That's just as good as any other option. Then you should probably consider a copy left license because that will guarantee that your code will always remain open source and nobody can relicense it. It's also worth noting, I was going to mention dual licenses. So it's very common that open source projects may be released under what's called a dual license, sometimes even more than two. But a dual license does not mean that both licenses apply at the same time. A dual license means that there are two licenses and the end user gets to decide which license applies to that use case. Let me mention, let me talk about that bottom example, QT. Most people have heard of QT. It's a GUI toolkit. They sell QT under a commercial license and they also make it available as open source under the GPL license. Why would they do that? Well, they want anybody to be able to look at QT, examine it, look at the source code, give it a try. And if you're using it for your own purpose or maybe say researcher at a university or something like that where you're not giving it to anyone else or you don't care if your code is open source, then they're happy to let you use it like that for free. But if you're a commercial company and you want to create a product and sell it and you want to use QT as part of your product, then they are more than happy to sell you a commercial license for QT which allows you to redistribute it and keep all of your code proprietary and then sell it as a product without any risk to your code and you don't have to release your code as open source. And you're happy because you get to build a cool product and ship it and sell it and QT is happy because they get to make a little money and they sell you a commercial license and then there is essentially no open source involved. So that's a good example of something that's dual licensed and then the end user has the choice. Let me go ahead and open up for more questions. I'm going to sort of skip over the license code flex. By the way, these are some great resources. So again, all these are on the sketch website. If you go and find this session, you can download a PDF of the slides. So a lot of it is your use case. So let me go ahead and open up for more questions. Question right here, if you can get the mic please. I think the people who are watching on the video stream will hear better if we use the mic. So there are some issues currently with Qflow which has an Apache license but it depends on Minio which has an AGPL license. Is that because Qflow would have to have an AGPL license if they used Minio? I'm having a little hard time hearing. It's okay. Go ahead and stand up and speak louder for me if you would. Go ahead and take your mask off while you're asking. So currently Qflow which is Apache is not able to upgrade their dependency on Minio because they changed licenses to AGPL. I'm just wondering, is that because if Qflow were to use newer versions that they would have to also be AGPL since they're using an AGPL license? So the one project is using Apache and you said they end the dependencies using AGPL? Yeah, the dependency updated to AGPL. Updated to AGPL. Okay. And so now they can't use newer versions of it. Okay. So that has to do with license conflicts and it also has to do with whether or not the people who wrote the, I think you said Qflow, it has to do with whether or not they want to change the license for their code which I'm guessing they don't. So the short answer is there are some license conflicts between Apache and the GPL licenses and even when there aren't license conflicts, if you mix Apache and GPL or AGPL, it will re-license all of the code under Apache and the new combined work is all under that AGPL license. So if Qflow is under Apache and they have this dependency and then they, and then, so by the way, you touched on an important point which is if you own the rights to the code, you're the author and you have the copyright to the code, you are allowed to change the license anytime you want. That being said, if you release open source under the Apache license, whatever this dependency is, you release it under Apache as version 1.0 and then you write version 2.0 and you release that under AGPL, 1.0 is always out there under Apache. That will never change. You cannot retroactively change the license for something that you've already released, so that's important. So Qflow, they can continue to use that version 1.0 under Apache indefinitely. And then this dependency, they change the license in version 2.0 to AGPL. The Qflow, they don't want to use it anymore because it would re-license, it would force them to re-license their code, which they don't want to do. So the people who wrote that dependency, they have every right to change the license later on because it's their code. But yeah, if the original code Qflow, if they were to use that newer version, then the copy left license would effectively re-license their code. So that's almost certainly why they are choosing not to update that code or update the dependency. Gotcha, thank you. And then I appreciate the explanation and then a follow-up question with a little bit less detail, but you probably know about this. Apple's decision to pivot from defaulting to ZSH instead of Bash, are you familiar with that? I'm not familiar with that specific example. It may have to do with the license. I don't know if that was for technical reasons or for licensing reasons. Licensing. So I know Bash updated the license and I'm not sure from what to what, but I know that that's why Apple switched to ZSH. I'm not familiar with that specific instance. All right, more questions please. Back in the back if you could handle the mic. Go ahead and take your mask off and speak loud, please. Sure. So what if your code is kind of a sit together with stuff from Stack Overflow and general comments? Will you run into any issues there? So you're asking about using code that's on Stack Overflow, for example? Yes, yes. So that's a great question. Just because code is available or visible or on a website does not automatically make it open source. Many websites including a lot of the websites like Stack Overflow, Stack Exchange, where you can answer questions, give code examples, many of them have a license or you have to sign an agreement or acknowledge that the code that you contribute to that website is available to anybody under an open source license. So some websites are better about that and proactive and say you post code on here, it's available to anybody under this license. But before you grab code off of a website, find out if does that website specify that the code is available to any reader under a specific license or the person who posted it, they may put a license with the code, either in the comment saying this is available under the Apache license or the GPL or whatever, or it may be in the header of the code. If you can't find any information about a license, legally you must assume that the code is not open source and therefore it's essentially like proprietary code. So even though you can read it, you don't have the license. It's the same thing like the speeding on the freeway example. Just because you can do something doesn't mean that you should. Hopefully that clarifies that for you. Okay, a more question over here on the other side of the room. We've got about two minutes left, so we'll do this and if we have time, one more question. I guess just a statement for Stack Overflow, it's Creative Commons. You have to attribute the fact that this came from Stack Overflow and also any changes should be shared and distributed along with your software. It's a strong copy left license. Okay, great. Thanks for that input. Okay, I think this will be the last question. Go ahead and speak up please. Hello. I'm curious to understand if the open source license, whatever the code was written with a first license can be changed to something else later and how will the users who are consuming with the primary license be impacted with it? Okay, I didn't catch all of that, but you're asking if I heard you say a primary open source license? Okay, let's say for example, I author an open source code for today and I release it with Apache and a few years down the line, I change it to something else. So is this possible? That is first question. And second, how will the users with the Apache license be impacted, meaning the primary license what I had open sourced with? Okay, so you release open source under Apache and then later you change it to something else? Yes. So again, the code that you released under Apache will always remain under the Apache license. And if you change your code or if you change the license later, the people who are using it under Apache still get to use it under Apache forever. And then if you change it, then somebody can use your new version under the new license, but not under Apache. So it impacts the code going forward. So all the code that's out there under a certain license will always be under that license. And if you change the license later, then people who use the code, the original code it's a little tricky. If you release a new version, an updated version under a new license, then it's kind of easy to understand because you have version 1.0 under this license and version 2.0 under a different license. If you don't change the code and you just change the license, but the code is identical, then essentially what you're doing is you're dual licensing the code. So if you change the license without making any changes to the code at all, I'm not sure if that's what you're asking about, but if you don't make any changes, then you have a version of your code under this license, an identical version of your code under a different license, and then somebody can choose to use it under either license because you already put it out there under the first license. So you can't force people retroactively to change, you know, to use it under a different license once you've put it out there under the first license. Okay, thank you. Yep, okay, we are out of time. Thank you, everybody. If anybody has more questions, please feel free to follow up with me later on. Thanks.