Do We Still Need Strong Copyleft Licenses?

  |  Compiler Team  
Open source

Compiler • • Do We Still Need Strong Copyleft Licenses? | Compiler

Do We Still Need Strong Copyleft Licenses? | Compiler

About the episode

It’s a good idea to understand the open source licenses governing the projects you use. Luckily, it’s less daunting than you may think. We start with the very basics of copyright and move to open source and the difference between permissive and copyleft licenses—and how they govern the world of open source software.

But we learn how these distinctions may not be as relevant as they once were. The landscape of tech is changing. Developer culture isn’t what it used to be—and neither is how we consume software. We ask: Do we still need strong copyleft licenses?

Compiler team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

All right, Johan. What do you have for us today? Today, I want to talk about open source licenses. Okay. We work for an open source company. True. We do. But I'll go ahead and be brave and admit that I don't actually know all that much about the licenses that kind of support the whole community. How much do you know Brent? Angela? I know a little. I know that there are licenses that you can apply to the code that you put out on GitHub. You can pick a couple. You usually pick the one that you've picked the last time depending on the last project that you use. It's more of like a cookie cutter. You just pick one that's open and you keep moving. You post it on your repo so folks know that they can just use your stuff freely. I don't know any more than that. Brent, what about you? I think licenses to me are a little bit like alphabet soup, because they all have acronyms and they all... I know the acronyms and I have a vague understanding of them. But I’ve got to admit, I don't know a lot about this topic. Well, today we're going to sift through that alphabet soup. It's a lot to go through. Soup sifting. But the one thing that I really want to focus on today are copyleft licenses. Now, that's a certain type of open source license. Okay. They were once really popular and now, and they're kind of losing their edge. I wanted to ask, do we still need strong copyleft licenses? Is that heresy? Are you allowed to ask that question, Johan? I don't know. Well, it's too late. He's already asked it. I've asked it. It's on the air. I guess we got to do this. This is Compiler, an original podcast from Red Hat. We're your hosts. I'm Brent Simoneaux. And I'm Angela Andrews. We're here to break down questions from the tech industry, big, small, and sometimes strange. Each episode, we go out in search of answers from Red Hatters and people they're connected to. Today's question, do we still need strong copyleft licenses? Producer Johan Philippine is here to help us out. In order to understand everything about open source, we're going to need to have a little bit of a baseline understanding of copyright. Everyone's heard this term before. I'm just going to give you a very high level non-legal definition. It's basically a legal protection for a piece of intellectual property. In today's episode, we're going to be talking about code as intellectual property. And it gives the copyright holder exclusive rights over the copying and distribution of that property. Typically, that's the default state of any piece of software. There are some extenuating circumstances where that's not the case. Really, you shouldn't be posting code without a license at all because it's seen as bad practice as it can lead to confusion. There are open source licenses and there are proprietary licenses. Is that the right way to think about this? Broad strokes? Yes. I mean, technically it's proprietary on one side and then open source and freeware and free software licenses on the other side, but we're not going to discuss all of them today. We're just going to cover the open source licenses. Got it. Now, in order to go over a lot of these definitions and really help us understand the different types of open source licenses, I needed some help. So I talked to a lawyer. Heather Meeker is a partner at O'Melveny & Myers and she's an expert on open source licenses. You need open source licenses to share software. There are plenty of projects that don't even have any license terms. Now, that's not a good thing because that means it's not clear that people will have the right to use the software the way they want to. If you want to share your software, you need to put some sort of open source license on there so that you're making it clear to everyone else, Angela, like you were saying that it's not closed source that they can actually use it without any repercussions down the line. Now, within open source, you've got two more kinds of licenses. And first off, they are the permissive licenses. These include the Apache License, the Berkeley Software Distribution (or BSD License) and the MIT License. Those are the ones I've heard of and used. It's what a lot of people think about when they think about open source. You slap a license on it and you're just saying, "Okay, here you go. Just use it. I don't really care what you do with it." I think what I hear you saying is that this is both protecting the person who has originally created this or the group of people who have originally created this, but then it's also giving permission to other people to use it and change it and do whatever they want with it. Yeah, exactly. Here's how Heather Meeker put it. A permissive license, that is almost no protection for the license or really, the only protection is that there's what we call a warranty disclaimer. Those are the terms in the big capital letters. And they basically say, "Here's the software. Do what you want with it, but whatever you do with it, it's not my problem." On the other hand, there's the other kind of open source licensing, which is called copyleft. It's a bit more restrictive, but it's a mirror of copyright. So copyright, copyleft. Oh my God. Are you keeping track? There's that light bulb moment, right? Oh God. A few of these copyleft licenses, those are pretty popular. The GPL or the GNU General Public License, that one's probably the most popular one. And then there's also the Mozilla Public License, MPL. Those are both widely used copyleft licenses. Copyleft is... It's probably the most complicated concept in open source licensing, but you can really reduce it down to a couple of pretty simple rules. The rules are if you distribute the software in binary form, either modified or unmodified, you have to make the source code available to people who receive the binaries and you have to make the corresponding source code available. All right. Let's see if we understand copyleft. Angela, do you want to do this together? Yes. Let's see if we're tracking here. Oh boy. Here we go. All right. You start. The copyleft is basically where you are saying, "I'm going to take this license and because you're going to use this code, you're going to have to adhere to it. Meaning anything that you do with this code and anything that comes from this code, you're going to have to share." Am I getting that right? Like you have to make that source code just as open because you've used this piece of software that has this particular license. Is that tracking? That's part of it. If you make that source code available because you are distributing that piece of software, that's when the copyleft comes into play. If you make changes, but don't distribute or only distribute the program internally, then the GPL or other copyleft licenses do not compel you to share the source code. Got it. But wait, there's more. I knew you weren't done. How did I know there was going to be more? Because it's complicated. Yes. The other thing to keep in mind is that using copyleft covered code does not automatically mean that it covers your proprietary code. A lot of people misunderstand it as viral or infectious and that's just not the case. If the copyleft covered code is not added to, or is not required to run the proprietary program, then it does not extend the terms of the license to that program. Meaning that it does not move through your stack. Exactly. In some cases, it would. But in most cases? In most cases, it does not. Okay. Now again, one last time as a reminder, if you're not distributing the code externally, the copyleft terms don't apply. Okay. In my mind, I'm almost imagining a whiteboard and we're going to draw little boxes on there. At the top there, we have copyright and open source and then underneath the open source box, it's going to branch off into two other boxes. And one of those is going to be permissive licenses and this includes licenses like Apache, BSD, MIT License, and then the box next to it underneath open source licenses is going to be copyleft. And these are licenses like GPL and MPL. Is that right? Did I do it? You did it. You nailed it! All right. All right. Now, we know what we're talking about and we've got some of our acronyms straight. We'll see. Let's take a look at how we got here. In the '90s and the early aughts, not a great time for open source in terms of public perception, there was a lot of fear, uncertainty around open source licenses and it didn't really help that new licenses kept popping up all over the place. And there were a lot of debates at this time, right? Oh, yeah. There was a debate raging about which kind of free or open source licenses was "better" for the community. Permissive versus copyleft. Raging. It got real heated. It's cooled off since then. I kind of want to know more about it though. That's a story for another day. Yeah. I was really only vaguely aware of what was going on in open source at the time. So, for a detailed account of the early days of open source, I spoke to Josh Berkus. He's a community architect at Red Hat, but he's also a long time member of the Open Source Initiatives Review Board. If you go back to 2002, it was standard practice that if you launched a brand new open source project, you wrote your own license from scratch rather than reusing existing license. And the only real exception to that was a lot of people reuse the GPL Version 2. But if you weren't using the GPL Version 2, often you wrote your own license and by 2005 or so, most of us who worked in open source were realizing that this was a real problem, that users could not be expected to keep track of a catalog of open source licenses that had hundreds of different licenses in it. Can you imagine trying to get your start in open source and just seeing the sea of licenses and not having any idea what the differences were between all of them? That would just be so intimidating. For sure. It's definitely something that could be considered a barrier because there was no formal agreement on what type of licenses and people just writing, free-styling, coming up with more and more licenses. How do you choose? How does one choose? We're in 2005 where all heck was breaking loose. This sounds like a very chaotic moment, right? Yeah. But thankfully with some effort in the community by organizations like the Open Source Initiative, The Debian Project, and the Free Software Foundation, the open source community has kind of rallied around five to six licenses as the standards. Over time, standardization has been one of the huge hidden benefits of open source licensing. Before open source licensing was quite so prevalent, when you did a due diligence process on software licensing, it was extremely complicated. The process would be, you would get a list of components and a list of licenses and you would have to read every license and then compare that against what the company was doing with the software and see if they were consistent. And that would create a lot of work for the lawyers. But just imagine if you were a developer trying to figure out if you could use a piece of software and this is something that Josh Berkus has told us about. Back in the day, you would have to read all of these licenses to figure it out yourself if you didn't have the resources of a company or a lawyer to do that. It was a huge problem. This feels a lot easier for a company to navigate. For sure. Because you have your in-house counsel or you have your lawyer on retainer that is going to help you navigate all of this. This seems very complicated for an individual. Yeah. Yes. I mean, imagine having to sort through this catalog or not even the catalog, like reading the legalese inside each and every one of these licenses to see if they can apply to your product. I mean, we don't even read the EULAs. Can you imagine trying to comb through an open source license and trying to decipher the legalese in that? That can't be easy for the lone developer. There's a lot of chaos. People are writing their own licenses. There are a ton of licenses out there. Standards start to be created. What happens next? Well, it turns out that when you standardize something, it makes it much easier for a large group of people to understand what it means. And so, that wasn't just a boon for open source licenses. That was a boon for the software industry as a whole. The attitudes have changed hugely and people are not as afraid of, say, copyleft licenses as they used to be. But at the same time, copyleft licensing has become a little less popular than it used to be. I think if you look at the statistics, every year, the number of projects or however you count it, because that's actually a non-trivial question. They move a little bit more towards the permissive licenses like Apache, BSD, MIT and away from the copyleft licenses like GPL and LDPL. And I think that I would mostly attribute that to a sort of generational change in how developers feel about releasing their own code. The industry has changed and then the mindset of developers has changed over time. I think I'm having a little bit of trouble understanding what Heather is saying there. Can you parse this a little bit for us? Sure. Basically, as the standardization took root, the industry as a whole kind of changed in its view of open source, because everyone started understanding them a little bit more and thinking like, "Oh, okay. If I put a copyleft license or if I use a piece of software that has a copyleft license on it, it's not going to make my entire program, my entire stack open source." It just means that that one piece of software that is attached to it is going to stay open source. And so, there's a lot less fear about using open source software and copyleft software. Now, that kind of changed the attitudes because that fear was gone and people started using it more. Developers now have a much... it's much more ingrained in them that "share your software" is not only okay, it's actually the preferred way to do things because if you do that, then everyone has this shared understanding of what they can and can't do with the code based on the license that's attached to it. Well, I think in a way, the copyleft licensing model is a bit of a victim of its own success because it worked extremely well for Linux and it was very necessary to get people to share improvements to Linux. They needed a license like that that had a legal compulsion to share source code, but as time went on, I think the industry internalized the value of collaboration in a way it never had before. In part, because it was forced to, having to comply with the GPL. And so, in that respect, people will often share changes even if they're not compelled to by the license. What you're saying is that there's a generational shift that has happened. There are developers and there are companies that came about before the standardization and they sort of had to go through this struggle and go through this process. And so, they understand the value of this. And then there are developers and there are companies that have come about after these standards have been set and after these licenses have become largely accepted and so, they take it for granted. Yes. Here's the question though? Is this necessarily a bad thing? It's kind of an open question at this point. It is because products are still being created. Software is still being put out there, open source software, which is the popular way to do anything nowadays. I think it is not curbing innovation at all. That shift to more permissive, I think that's just the way the open source movement has kind of moved. So much so, I mean, you think of there are events around contributing to open source. It's ubiquitous with sharing and learning more about a product and contributing and being a part of something big. This generational change that you mentioned is kind of indicative of the generation that has changed. You know what I mean? This is just what they do now. I like to see that. We all know now that open source is better. That would be a great way to think about it if the world of tech kind of stayed where it is now. The culture has changed in such a way that everyone is sharing and open source seems to have won. But unfortunately, the world of tech does not stand still. No, it doesn't. And that has some possible challenges to the open source licensing model. With this idea that the community is now kind of taking licenses a bit for granted and maybe not taking as close of a look as we should be, there's a fear and there are actually some instances where companies take advantage of more permissive licenses and shift things back to a more proprietary world. Because open source has become the default, a lot of people no longer actually read the terms of the software they're using because they're told upfront not really to worry about it. And that creates an opportunity for people who want to tinker with licenses in a malicious way. Because if people are not looking at how, what they want to use is licensed, then it is very easy to accidentally adopt something that was, in fact, not genuinely open, that contained terms that you didn't actually want to agree to because you were assuming that everything was certifiably open source license and it actually isn't. That's a pretty big problem. Companies slip in, either they'll take an existing open source license and add a single clause to it that basically invalidates the whole open part about it or they'll come up with another new license that is somewhat similar, but takes it much farther than what a typical open source license would do. That really kind of puts a damper on what open source is. Most of us are just average tinkerers and now, it's like, again, buyer beware, you really don't know what you're getting yourself into unless you're going through this with a fine tooth comb. You just have to be careful it seems. Is Josh saying that people are doing this on purpose and being malicious or is he saying that it is by accident? He's saying that some companies are adjusting the open source license to better fit their business model. And that's not necessarily a bad thing. I mean, we don't want to denigrate companies because they're trying to make money, but the problem is that if they're trying to sell something as open source when it isn't, then at that point, you're deceiving your user. How do we fix this? Vigilance and education. Josh suggests having organizations and big companies like the Linux Foundation, the OSI, Debian, the Free Software Foundation to do a little bit more to educate, which is what they did 20 years ago to get everyone to agree on standards and to agree on the open source definition. But once everything became accepted and standardized, that education component kind of fell to the wayside. And so, he suggests kind of starting that back up again and getting people to understand what open source means and to teach them to be a little bit more vigilant about the licenses that they're using and on the software that they're trying to use. That's a doable fix. That's something we've done in the past. What's less simple though is that there's kind of a dark cloud that's growing over the world of open source licenses. Now, remember at the top of the episode, I mentioned, we'd come back to distribution? It's basically the basis of copyright and copyleft licenses like the GPL. They rely on that distribution of the software to be enforceable at all. We talked about when distribution triggers the license term, but the way we're using software is changing and that means distribution isn't such a straightforward term anymore. We have shifted from an industry where most software is delivered in the form of physical media or direct downloads of binaries or direct downloads of software distribution bundles to a software world in which the majority of software is used as a service either over the web or over a mobile network. And a lot of the focus in license text on some of the older licenses, it's focused around sort of physical redistribution of the bits in the program and therefore, there's a big open question in how do we ensure that licensing terms are respected if the way that things get deployed to the user is now as a service on a public web resource. Johan, can you decode some of this for us? I can certainly try. I think what Josh is saying here is that when you're accessing a program on a cloud-based service through your browser, for example, you're not actually downloading anything to your device permanently. You're not installing software like we used to from CDs or downloading from the Internet and then installing it on your computer. There's the argument that the software is therefore not being distributed. At that point, you're accessing the software at its source, but you're not permanently copying it and moving it to your own computer in order to use it. We're just using it in the browser and it's back somewhere on someone's server out of our grasp and they're giving us access to it. Exactly. There's really nothing physical about it anymore. That kind of throws up in the air, the enforcement of these copyleft licenses. If you're not distributing the software, then, well, you don't really have to share the source code, so goes the argument. There's some talk about enforcement here. What does enforcement look like? This is like legal action, right? Exactly. Enforcement basically means that if someone verifiably takes open source code and then distributes it without complying with the license terms, they could be sued. There was a period where everybody was wondering whether the licenses were enforceable at all and who would enforce them and so forth. And that pretty quickly gave way to a model of community enforcement, meaning enforcement by groups who usually represented individual authors. Often, they did it free of charge, it's like pro bono representation. And they would try to get people to comply with the licenses that the way that they operated and the way they still operate is that their main goal would be compliance instead of going after companies for damages or injunctions. They just wanted people to share and to comply with the license, but there's kind of a wrench thrown in the works about whether that can persist. What has changed though is what we've talked about where the whole culture around development has drastically shifted towards sharing an open source and doing that as a default. And so, when companies are caught doing this, there are a lot of non-legal repercussions to skirting the letter of the law in order to break the spirit of the law. Once upon a time license enforcement was a bigger part of the world of open source. And even now, it's less important than it was because fewer organizations are interested in violating a license because even if there is not legal enforcement against them, there is often a backlash in other ways, a backlash in social media, a backlash that hurts their PR, a backlash that hurts their ability to hire people. And as a result, the sort of legal enforcement angle of open source is less of a concern than it would've been like 15 years ago. But now, when companies are caught red-handed, there's all these other ways in which they get punished for it basically. And it seems like that can have a big effect on the company's or the person's reputation. Yeah, because another thing that's possible with open source is if a project changes their license or they abuse the license or they do something that flies in the face of the open source community and its values, people have the ability to kind of vote with their keyboards, I guess. If someone is doing something that they're not okay with, they can easily find another project that will do something very similar. I want to return us to our question: Do we still need strong copyleft licenses? Johan, I want to know what's going on in your head. Having talked to Josh and Heather, what is going on in your head now? Oh, so many things. It's complicated and it's a tough question to answer. Going back just a little bit, when we were talking about the proliferation of licenses, there is also this debate raging about which kind of license is better, permissive versus copyleft. Which one would be better for the free and open source movement? And what I don't want to get is back into that kind of debate, because it seems as though we've largely moved beyond that. Yeah. That is what is, I think, largely good for everyone. And with the licenses that are out here and available now, it gives you a choice, so you can arm yourself properly when you put a project out there. I think it empowers the person who's putting the code out there. I think that's a really good idea because sometimes we just put stuff out there and we don't think about the consequences. This arms us and this gives us power. This allows us to protect ourselves and also keeps up with the... What's the word I'm looking for? There's a term that people use and they use it in Red Hat, like the culture of open source. The open source way? Right. You're still being open, but you're just setting those guardrails, protecting yourself, protecting the end user. I mean, that's a win-win. We all want to protect ourselves especially if we're dealing with something so ephemeral. But I think at the end of the day, this is really about what we value, what we value for ourselves, what we value for the people around us and what we value for our industry. And just like you were saying, Angela, it really is about choice. It's about having the choices available to you to enact what you value in the world. Exactly. We want our listeners to take that and run with it. The Compiler theme song is licensed under the Creative Common license. That means we want our listeners to remix our song, so I want you to flex on it. I want you to jazz it up. We would love to hear what you come up with because that's what open source is all about. And the best part about it is we're going to take some of those and play them in a future episode, so let's see what you got, okay? All right. We are going to put some instructions down in the show notes so go check that out. You can also go to redhat.com/compilerpodcast to learn more. All right. I can't wait. Me too. And that does it for this episode of Compiler. Today's episode was produced by Johan Philippine and Caroline Creaghead. Victoria Lawton compels us to share everything all the time. Our audio engineer is Kristie Chan. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Huge thank you to our guests, Heather Meeker and Josh Berkus. We also want to thank Jeffrey Kaufman and Richard Fontana for helping us get the legal details of this episode right. We are not experts and they are, so thank you very much. Our audio team includes Leigh Day, Laura Barnes, Claire Allison, Nick Burns, Aaron Williamson, Karen King, Boo Boo Howse, Rachel Ertel, Mike Compton, Ocean Matthews, and Laura Walters. If you like today's episode, please follow the show. The best way to help us out is to rate the show, leave us a review or share it with someone you know. Take care, everyone. See you soon. All right, goodbye.

More about open source

Typically, it refers to a type of software released through a specific kind of license. But open source is more than just code— it’s the people, processes, and principles that make it all work.

Publicaciones en el blog

Los motivos por los cuales el futuro de la fabricación se basará en el open source

6 de febrero de 2024  |  

...

Open source

Publicaciones en el blog

El Estado del Open Source Empresarial 2021: cuatro resultados que podrían sorprenderlo

2 de marzo de 2021  |  

...

Open source

Programas originales

Open Source Hardware | Command Line Heroes

Open source
Historia de la tecnología

Programas originales

Open Curiosity | Command Line Heroes

Edge computing
Open source
Historia de la tecnología

Programas originales

Ready to Commit | Command Line Heroes

Desarrollo y distribución de aplicaciones.
Open source
Historia de la tecnología

Sobre el podcast

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.