 from San Francisco. It's theCUBE, covering Red Hat Summit 2018. Brought to you by Red Hat. Hello everyone, welcome back. This is theCUBE's exclusive coverage of Red Hat Summit 2018. In San Francisco at Moscone West, I'm John Furrier with 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? Welcome to theCUBE. Thank you, John. It's good to be here. So obviously, the legal challenge is, you know, putting GDPR aside, which I don't want to get on that rant, but we're not going to talk about it, is licenses in open source. This has been an enabler, but also an inhibitor for many in not knowing what licenses to use or what code license means for them, their role in the community. All 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, you know, bring some order to what you describe as a 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. We collaborate in the development of software, but what really enables that are licenses, open source licenses. And much of Red Hat software is built on top of a particular license, which is called a copy left license. It's known as the GPL or the general public license. And it's a great tool to foster collaboration, right? What copy left means is if I create a piece of software under a copy left 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? You know, 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. So if I create value, do you get that back? If you decide to distribute it to me, you don't have to. But if you distribute it to someone else, then you have to give it back with all those same rights. So you're paying it forward. Basically, all the rights forward. Exactly. So it goes good ethos. But then if I improve upon it, I create like a derivative work, whatever the legal term is. And I, oh, this is a magic secret sauce. 10% of it is magic secret sauce. Now I distribute that product. I pass along the license. Correct. Including my secret sauce. If you decide to, there's nothing that requires you to do it. So, you know, a lot of our customers sort of build their secret sauce internally. You know, 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 know, you have to continue to distribute. What does that mean distribute? Distribute the software to a partner or the product itself? Yeah, it could be both. So the product is sold publicly as a service. Say a cloud service and I got some secret sauce. So if it's a service, it's a great question. It kind of goes into sort of legal issues. But generally speaking, if you're providing a service, that's not a distribution. So if I don't really have access to the software. 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, that's the next, 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 kind of the new news here and what were the specifics of what were the new development, but open source was scary. A few, a generation or two ago. It seems like at this point, especially in cloud, it's the new normal. Is that as you, and inside the red hat, as you all look at your landscape, it doesn't seem like you have, do you have like big Fortune 100 lawyers coming and yelling at you now versus 10 years ago? It's a great point. So I've been at Reddit for 13 years now. And 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 copy left aspects of the GPL. 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. And also a lot's changed since that time. I mean, right now, I think people have seen the benefits of projects being out in the open where it's fostering great collaboration and the productization piece can still exist with that. So the dynamic between productization, aka commercialization and open source projects is interesting. So you can almost make the argument, it's easier to be compliant if you just make everything open source because rather than re-engineering any fixes, the community can do it for you. So this efficiency has already been proven. Absolutely. And customers are concerned about compliance with all 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 all 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 have a whole community that's supporting the contributions that you described. Okay, so what's the big news here? The GPL version two. Okay, so first of all, what's the current situation? You guys made a quick tweak in this GPL two, three situation. What was the current situation? What was the motivation? Why the change? What's the impact? So I talked earlier about the GPL and the GPL has sort of 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. Well, 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 two is that there's no grace period. 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. Yeah, this is the grace period. So there's no grace period in version two of the general public license. That problem was fixed when they came out 10 years ago with version three of the GPL. So version three included this grace period in it. But the challenge is that a lot of code today remains GPL version two. 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 two, I'm sorry, version three for GPL version two code. Stop me if I'm speaking too quickly or I'm getting too technical. So the idea is- Three, one, just back 33 seconds. So like do a little playback. So if you can apply GPL v3 to the v2 code. The Cure period. Oh, just the Cure period. So I'm adopting the Cure period. 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. So essentially your grandfather in this v2 was a grace period. We're giving this grace period. And this is a corporate promise. This doesn't change the license. This is a corporate promise. It's a promise 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 the same approach. Adopted the GPL v3 Cure period for the Linux kernel, which continues to be licensed under GPL version three. And then in December, sort of Red Hat led a group of companies that included IBM, Google, Facebook. We all adopted it for our own copyrights, right? So we, you know, together, you know, those four companies own a lot of copyrights and open source code. And then in again, in March, six more companies joined us. SAP, Microsoft, Cisco, HPE, SUSE, CA Technologies. And at the Red Hat Summit today, we're asking developers to do the same thing. You know, we want to show that it's a movement that, you know, we want to cooperate in an enforcement because we think ultimately, if we want, you know, more people to join, you know, the open source ecosystem, we can do that by making enforcement more predictable. And so what specifically are you asking startups? What's the, what's the ask? So for developers, if you go to, we have a site on GitHub. So it's, it's the GPL cooperation commitment. So gplcc.github.io slash gplcc. Can you go there? 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 and would apply to any for some good. That gives them the promos or your stop-all or rights. And you know, anyone who takes that code has that, that peace of mind. Well, great stuff. Grid 101 on the GPL v2 v3. Great, great. It's super cool that you guys are doing that. It's just such a hassle. It's just, I'm sure the complaints have been crazy. The bigger question for me, if I look at, because I love it, the innovation comes from open source. We're seeing that both in the collaborative side and the projects, but also people are really productizing open source and it's running everything. The question is, when 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 and reliable if I'm in enterprise or startup that through venture capital or 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 it's just fear. This is a general kind of licensed hygiene kind of practice. What do you, what's your take on that? What's your advice to entrepreneurs, to enterprise developers to be safe? What should they do? Is there an approach? It's a great question. I mean, what you want to know is, you know, where's my code coming from? And you have, I mean, it's a license issue, but it's also a product security issue. Right? I mean, if you're, you know, taking something from someone, they took it from, you know, two places down the food chain. You know, what's the provenance of that code? So, I mean, just like from a security perspective. How does she emanate herself because of this? Yes, you want to know the source of your code. You know, get it from a trusted source. You know, make sure that you understand what the license terms are. You know, 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, you know, a user or a startup's not going to know, you know, what rights they have. And that can become problematic if they have a liquidity plan. Okay, so here's my next question. So then the next question is, obviously open source is growing and people are joining projects and or creating projects. So it's hypothetical I have a project and I want to donate the CUBE code to the open source sort of CUBE community. Do I just ship the code? Do I have to pick a license? What's the best license? And then I want to also have in the mind that I might use Linux and all the things. So I have code, I written, proprietary code, I want to open it up. I got to pick a license. Like, do I just go like that and pick a 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 two. So you have to sort of 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 copy left 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 copy left license. Paul, do you think we have reached the end stage of open source licenses here? Are you, you know, GPL v3 is 10 years old, you know, 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 we looking for things? It's a great question. So I was at a conference two weeks ago in Barcelona put on by the Free Software Foundation Europe. And one of the conference sessions was the future of copy left. You know, is there going to be another copy left license? Do we need GPL version four? You know, it's, you look at sort of 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. You know, so is there a simpler way of accomplishing the same objectives? But I don't know that people have the stomachs. And the answer is? Yeah. I'll come back next year and let you know what I learned. Well you're wearing a button. Now I'm going to have to ask this. Ask me how you can support open source license. So I'll ask you, how can you and me support open source license? So it's take the GPL v3 cure commitment, you know. Commit your name to supporting, you know, 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, you know, pull the whole community together. It's quite an accomplishment too if you think about open source principles. Again, we've been talking about the skew other events, but okay, we've just beginning of another generation of open source greatness. Certainly remember the glory days when it was a tier two citizen in the enterprise. You guys made a tier one, but now it's going to a whole nother level with cloud native. And you're seeing open source ethos being applied to other markets, not just software development. So you start to see the success create this circle of innovation. And you guys have the pinch me moments inside Red Hat saying, hey, this is actually working. That really well. I mean, just a couple of touch points. I mean, you think, you know, where Michael's Microsoft has come, right? When I joined Red Hat, I mean, that wasn't a friendly relationship. And now they've embraced it. You know, who would have thought, you know, 15 years ago that, you know, we'd see, you know, Microsoft on board and we have. And you know, your point about sort of where else is open source going? One of my colleagues spoke about a year ago to seed developers who are interested in open sourcing seeds. You know, because there's concern about seeds becoming patented and not being able to, you know, to grow food and so thinking about ways to sort of open up, you know, the market and seed. So- Oversization is a great thing. Yeah, absolutely. On the legal front, what's on the horizon? Then he hurdles, you see opportunities, challenges that you guys are working on. Obviously, there's always legal framework. You know, we just commented before you came on with Chris Wright about blockchain and, you know, some of the tokenization around content. And we might even see kind of a token economics and so forth down the road. So, I mean, a lot of interesting legal things happening to rights, if you open them up, what's your thoughts on the future? Yeah, so, you know, one of the areas that, you know, we're focused on, you know, as this Red Hat is containers. So, what does it mean, you know, if you put open source software layers in a container, you know, what does it mean if there are proprietary laders in there? Does it mean, you know, if you add, 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? So, we spent a lot of time thinking about that, you know, a number of years ago and luckily concluded that it actually may improve the situation as opposed to, you know, adding any concerns. So, we're thinking about, you know, the impact of open source licensing in containers, ensuring, again, to your point earlier, what's the providence of the code? I mean, there's so much code now available, making sure that there is a license associated with it. Some of us, you should just declare all code free. Yeah. Absolutely. Well, certainly a lot of new things you're seeing societal change, this impact that you've got self-driving cars and all kinds of new things that are just mind-blowing at a legal framework standpoint, first-time challenges. So, you're busy, you're always going to have an interesting job. You know, and I really think that I have the best job in Red Hat because I get to think about these things. You know, what does it mean from a licensing perspective? What are the new issues that we're going to face as sort of the technology evolves, the market evolves, and... Super important. I mean, there's tripwires in there, and again, if you don't think about it probably, I know from I've seen from experience, you know, great companies lose big-time acquisition opportunities because of some faulty code on a license. And it's just killed things. And then I've seen enterprises get so... I mean, little weird things could happen. You just got to be on top of it. I mean, look at what Tesla did in open-sourcing their patents. You know, making their patents and technology available so that, you know, it helped the whole autonomous car industry. You know, we've been doing a lot of work in the patent area as well to ensure that, you know, patents don't become an inhibitor to the change that you've described. It's a great conversation, provocative, legal, and open-source software. These are competitive advantages and opportunities, not challenges and compliance, you know, old school, you know, 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, global economy, and the technology innovation that's coming from us. theCUBE bringing you more of the live action here in San Francisco. We'll be right back with more after this short break.