>> Announcer: Live from San Francisco, it's theCUBE, covering Red Hat Summit 2018, brought to you by Red Hat. >> Hello everyone, welcome back to theCUBE's exclusive coverage of Red Hat Summit 2018 in San Francisco, Moscone West. I'm John Furrier, my co-host John Troyer, and we are here with David Levine, Assistant General Counsel of Red Hat, we've got the lawyer in the house. Who's billing for this hour? >> Exactly. >> Welcome to theCUBE. >> Thank you, John, it's good to be here. >> So, obviously the legal challenges, putting GDPR aside, which I don't want to get on that rant, we're not going to talk about, is licenses. In open source, this has been an enabler but also an inhibitor for many in not knowing what license to use or what code is, licenses mean for them, their role in the community, all of this stuff could be a morass of gray area, or just no one's educated in some cases, right? So it's tough. >> And that's what I do. I mean my job is to help bring some order to what you describe as some morass, right. How do we help reassure especially enterprises that it's safe to go in the water, it's safe to use open source. Red Hat is an open source company, our entire business is built on open source, and that sort of has a couple aspects to it. One is on the development side, you know we collaborate in the development of software, but what really enables that are licenses, open source licenses. And much of Red Hat's software is built on top of a particular license, which is called the copyleft license. It's known as the GPL or the General Public License. And it's a great tool to foster collaboration, right? What copyleft means is if I create a piece of software under a copyleft license and I give this software to you, I give it to you with all my copyrights. So you have the right to copy it, to distribute it to John, to improve upon it, but the only requirement is if you give it to John, you have to give it to him with the same rights and you have to give him the source code, and if you improve upon it, you have to license the improvements to him under those same rights. So it's this whole virtuous circle, right? I create something, I give it to you, you're able to continue to improve on it, you redistribute it, and we all get to share... >> Furrier: So if I create value, do you get that back? >> If you decide to distribute it to me, you don't have to, >> OK. >> David: But if you distribute it to someone else, then you have to give it back with all those same rights. >> Furrier: So you're paying it forward, basically all the rights forward, >> Exactly. >> Furrier: A dose of good ethos. But then if I improve upon, I create a derivative work, whatever the legal jargon is, >> Right, right. >> Furrier: And I have, this is a magic secret sauce, ten percent of it is magic secret sauce, now I distribute that product, I pass along the license. >> David: Correct. >> Including my secret sauce. >> David: If you decide to, there's nothing that requires you to do it, so a lot of our customers sort of build their secret sauce internally, they keep it within their companies and it doesn't go out any further than that, and that's perfectly fine, but if you decide to distribute it, you have to continue to... >> What does that mean, >> Furrier: Distribute, distribute the software to a partner or the product itself? >> David: It could be both. >> So the product is sold publicly as a service, say a cloud service, and I've got some secret sauce. >> David: So if it's a service, it's a great question and it goes into legal issues, but generally speaking, if you're providing a service that's not a distribution, so I don't really have access to the software. >> Furrier: That's actually a really good thing for developers. >> Yeah. >> Well, it's an issue, we are now in a service-oriented world so that's a, we are, maybe that's one of the next things that we as a technology community and an IT industry have to deal with. Certainly, it seems though, David, before we get into the new news here and the specifics of the new development, but open source was scary... A generation or two ago. It seems like, at this point especially in cloud, it's the new normal. Is that as you, inside Red Hat, as you all look at your landscape, it doesn't seem like you have, do you have big Fortune 100 lawyers coming in and yelling at you now versus ten years ago? >> It's a great point. So I've been at Red Hat for 13 years now, so I've seen sort of tremendous change over the years, and when I started in 2005, we were having a lot of discussions with customers about the copyleft aspects of the GPL, you know, this requirement to give back, and there were companies that were concerned about this, but over time, they've become more sophisticated and they're realizing that, notwithstanding what their lawyers were telling them, it really wasn't that dangerous, and I have very few of those conversations today. Most people get it. >> Furrier: And also a lot's changed since that time, I mean right now I think people are seeing the benefits of projects being out in the open, where it's fostering great collaboration. And the productization piece can still exist >> Yeah. >> With that, so that dynamic between productization, AKA commercialization, and open source projects is interesting. So you could almost make the argument, it's easier to be compliant if you just make everything open source because, rather than just re-engineering any fixes, the community can do it for you. >> David: Absolutely. >> So this efficiency's already been proven. >> David: Absolutely. And you know, customers are concerned about compliance with all of the obligations under the open source licenses, and one of the things that I try to tell customers is if you take open source, you build it into a product, rather than spend a lot of time focusing on pulling out the obligations into a separate file, just make the source code available, republish it and you get to participate, you get to push your contributions upstream and so you a whole community that's supporting the contributions that you described. >> Furrier: Okay, so what's the big news here that GPL, version 2, okay, so first of all, what's the current situation? You guys made a quick tweak in this GPL 2-3 situation, what was the current situation, what was the motivation? Why the change? What's the impact? >> David: So I talked earlier about the GPL and the GPL has very exacting requirements. I mentioned that if you're going to distribute the software to John, you have to give him the source code, and you have to include a copy of the license. Understanding what is source code, what has to be, what has to accompany it, depending on how you're distributing the software, that's not always an easy question, and so companies don't always get it right. And one of the challenges with GPL, version 2 is that there is no grace period, and so if you miss something, if you make a mistake in the way that you've tried to meet your license obligations, your license is terminated and you're a copyright infringer, sort of, right at that point in time, and that scares a lot of our customers, it scares enterprises. They need more predictability, they want some level of fairness. >> This is the grace period you're talking about. >> David: Yeah, this the grace period. So, there's no grace period in version 2 of the General Public License. That problem was fixed when they came out ten years ago with version 3 of the GPL. So version 3 included this grace period in it, but the challenge is that a lot of code today remains GPL, version 2, so what do we do with that large existing code base? And so, the solution was to adopt the cure provision, or the grace provision from GPL, version 2, I'm sorry, version 3, for GPL, version 2 code. Stop me if I'm speaking too quickly or if I'm getting too technical. So the idea is >> Let's rewind just back 30 seconds. So, do a little playback. So, if we can apply GPL, v.3 to the v.2 code, >> So, the cure period. >> Oh, just the cure period. >> So I'm adopting >> David: the cure period. >> Got it. >> David: So, the license stays the same, the only difference is, I've said that if you fail to meet your obligation to John when you redistribute, I'm going to give you 30 days to fix the problem. >> Furrier: So essentially you grandfather in the v.2 with the grace period. >> We're giving this grace period. >> Troyer: And this is a corporate promise. This doesn't change the license, this is a corporate promise. >> So it's a promise >> David: by any copyright holder, so in my example to you, I'm the sole copyright holder here, but in the Linux kernel, there are thousands of copyright holders. So the Linux kernel developers back in October adopted this same approach, adopted the GPL v.3 cure period for the Linux kernel, which continues to be licensed under GPL, version 3. And then in December, Red Hat led a group of companies that included IBM, Google, Facebook, we all adopted it for our own copyrights. So, we together, those four companies own a lot of copyrights to open source code. And then again in March, six more companies joined us. SAP, Microsoft, Cisco, HPE, Soothsay, CA Technologies, and at the Red Hat Summit today, we're asking developers to do the same thing. We want to show that it's a movement, that we want to cooperate in enforcement, because we think ultimately if we want more people to join the open source ecosystem, we can do that by making enforcement more predictable. >> Furrier: And so what specifically are you asking startups? What's the ask for developers? >> For developers, if you go to, we have a site on GitHub, so it's the GPL Cooperation Commitment, so gplcc.github.io/gplcc. >> And what do they do, just take a guess? >> And you go there, and there's the statement, the same commitment that the company's made, and you go in and add your name to the bottom of the file and submit a pull request, like developers know how to do on GitHub, and your name will be added as a supporter. >> Into the record. >> David: It would apply to every new copier. >> That gives them the primary source (mumbles), or write... >> David: It gives anyone who takes that code, has that piece of mind. >> Furrier: Well, great stuff, great one-on-one on the GPL v.2, v.3 grace period, it's super cool you guys are doing that. It's just such a hassle, I'm sure the complaints have been crazy. The bigger question for me as I look at, cause I love that the innovation comes from open source, we're seeing that both on the collaborative side in the project, but also people are really productizing open source and its running everything. The question is, where do I have code that I, you know, people are programming like crazy, they're slinging code like it's nobody's business right now. So, I might be afraid I'd be liable if I'm an enterprise or a startup that, through venture capital or an M&A process where something's going on, wait a minute, we can't actually sell this because that's his code over there. You didn't comply with the license, so there's always these tripwires in the mind, and sometimes that's just fear, this is a general kind of license hygiene practice. What's your take on that? What's your advice to entrepreneurs, to enterprise developers, to be safe? What should they do as their approach? >> David: That's a great question. I mean, what you want to know is where's my code coming from? And you have, it's a license issue, but it's also a product security issue. If you're taking something from someone, they took it from two places down the food chain, what's the provenance of that code? So, just like from a security perspective... >> Furrier: I've seen M&As go south because of this. >> Yes, so you want to know the source of your code, get it from a trusted source. Make sure that you understand what the license terms are. One of the things that we're trying to encourage developers to do is make sure you attach a license to it, because if you don't, a user or startup's not going to know what rights they have. And that can become problematic if they have a liquidity fight. >> Furrier: Okay, so here's my next question. So, the next question is obviously open source is growing and people are joining projects and/or creating projects. So this is a hypothetical: I have a project and I want to donate to CUBE code, to the open source CUBE community. Do I just ship the code, do I have to pick the license, what's the best license? And then I want to also have in the mind that I might use Linux and other things, so I have code I've written, proprietary code I want to open it up, I've got to pick a license, like, do I just go like that and pick the license out of the hat, or... >> Lots of times, it's sort of dictated for you. So it depends on the ecosystem that you're working with. I mean, if you're working in the Linux kernel ecosystem, generally it's going to be GPL, version 2. So you have to look at what other projects you're working with, is this part of a particular project that already has an existing license? And then it's a philosophical point. I mentioned before, the GPL is a copyleft license. It forces sharing, right, so it protects John's rights downstream from you, but there are other licenses that are permissive and give you lots of rights, but you could decide what you want to do with it downstream. So if you're okay with people taking your code downstream from you and making it proprietary, then using a permissive license is fine. But if you want to ensure this virtuous circle, then you want to pick a copyleft license. >> Troyer: Paul, do you think we have reached the end stage of open source licenses here? Are you, you know, GPL v.3 is ten years old, and after we started from MIT and Apache, and I could probably list a couple of others and I haven't even been paying attention, so, are we settled down, are we about done? Are you looking for things? >> David: That's a great question. So I was at a conference two weeks ago in Barcelona put on by the Free Software Foundation in Europe, and one of the conference sessions was The Future of Copyleft. You know, is there going to be another copyleft license? Do we need GPL, version 4? It's, you look at what the GPL has done and how many projects are governed by it, and how it's forced this collaboration, it's done amazing things, but it's pretty complicated. So is there a simpler way of accomplishing the same objectives? But I don't know that people have the stomach... >> Furrier: And the answer is? >> Uh, (laughing). I'll come back next year and let you know what I learn... >> Were you worried about, and now I'm going to ask, have to ask this, ask me how you can support open source licensing, so I'll ask you: how can you and me support open source licensing? >> David: So, take the GPL v.3 Cure Commitment, commit your name to supporting greater stability and predictability and fairness in the way enforcement takes place. So, I mean it's an exciting project. It's kind of fun to pull the whole community together. >> It's quite an accomplishment, too if you think about open source principles are now, again, we don't want to skew other events, but okay, this beginning of another generation of open source greatness certainly, remember the glory days when there was a Tier 2 citizen in the enterprise, you guys made it Tier 1 but now it's going to a whole other level with Cloud-Native, and you're seeing open source ethos being applied to other markets, not just software development. So, you're starting to see the success create this circle of innovation. Have you guys had the "pinch me" moments inside Red Hat, saying, "hey, this is actually working, and really well"? >> David: I think just a couple touchpoints, I mean, I think, look at where Microsoft has come, right? When I joined Red Hat, that wasn't a friendly relationship, but now they've embraced it. Who would have thought 15 years ago that we'd see Microsoft on board and we have. And your point about where else is open source going; one of my colleagues spoke about a year ago to seed developers who were interested in open sourcing seeds, because there was concern about seeds becoming patented and not being able to grow food. And so, thinking about ways to open up the market in seeds. >> Productization is a great thing. >> Yeah, absolutely. >> On the legal front, what's on the horizon? Any hurdles you see, opportunities, challenges that your guys are working on? Obviously, there's always the legal framework, we just commented before you came on with Chris Wright about Blockchain and some of the tokenization around content, we might even see a token economics model in software down the road. So, a lot of interesting legal things happening to rights if you open them up. What's your thoughts on the future? >> So, one of the areas that we're focused on, as is Red Hat, is containers. So what does it mean if you put open source software layers in a container? What does it mean if there are proprietary layers in there? Does it mean if you add, if you take my open source software, add a proprietary component, package it in a container and give that container to John, what does it mean for your proprietary layer? Is that, does that have to be licensed under the GPL? And so we spent a lot of time thinking about that a number of years ago and luckily concluded that it may improve the situation as opposed to adding any concerns, so we're thinking about the impact of open source licensing and containers, ensuring, again to your point earlier, what's the provenance of the code? There's so much code now available, making sure that there is a license associated with it. >> It's almost, you just declare all code free. (all laughing) >> Absolutely. >> Well certainly a lot of new things you're seeing, societal change is impacted, you've got self-driving cars and all kinds of new things that are just mind-blowing on a legal framework standpoint. First-time challenges, so you're busy, you're always going to have an interesting job. >> I really think that I have the best job in Red Hat, because I get to think about these things. What does it mean from a licensing perspective? What are the new issues that we're going to face as the technology evolves, the market evolves? And... >> Furrier: Super important, I mean there's tripwires in there, and again, if you don't think about it probably, I know or I've seen from experience, great companies lose big-time acquisition opportunities because of some faulty code on a license, and it's just killed things, and I've seen enterprises get (laughing). I mean, little weird things could happen, you've just got to be on top of it. >> David: I mean, look at what Tesla did in open sourcing their patents, making their patented technology available so that, to help the whole autonomous car industry. We've been doing a lot of work in the patent area as well to ensure that patents don't become an inhibitor to the change that you've described. >> Furrier: It's a great conversation, provocative, legal and open source software. These are competitive advantages and opportunities, not challenges and compliance, old-school guarded secrets. Open it up and good things happen. David, thanks for coming on theCUBE. Thanks for sharing the insights on the legal perspectives of licenses as open source software continues to power the globe on a global basis, the global economy, and the technology innovation coming. It's theCUBE, bringing you all the live action here in San Francisco. We'll be right back with more after this short break. (upbeat music) (inspirational music)