Walden Leverich on Open-Source Licensing
Charlie Guarino talks with Walden Leverich, CEO and founder of Tech Software, about GPL and the many possibilities of open-source software.
By Charlie Guarino02/25/2021
Walden Leverich: Oh, my pleasure Charlie. Thank you for having me.
Charlie: Walden, the reason why I brought you to this conversation today is I’ve been doing some investigation and I really opened up a potential—I hate to use the word—Pandora's box, but certainly a topic that there’s no shortage of information on, and that is open-source licensing. I can tell you that once I decided to go on this journey, to learn more about this, I'm easily now 15 to 20 hours in and it's seems a little daunting and I know this is an area that you would have some experience both, as a developer an as a user, which is why I thought you'd be a very good person to have this chat with today.
Walden: Yeah, thank you. It is something that we've played with professionally over—over a period of time. Certainly, I think one thing to throw out is that neither of us are attorneys; neither of us are providing legal advice here. We’re talking about licenses and those are legal constructs but we're throwing out our opinions and ideas on them.
Charlie: And much of the information I'll be asking you is what I've found in the public domain as well.
Walden: Sure. So, we come at licenses from two points of view, really almost three points of view, if you will. We produce software as a service solution and we obviously have license agreements around those. Those are our—our—that's how we make our money. Those are our commercial licenses if you will. We also, as part of creating that software, use pieces of open-source software, and honestly, not open-source software as well. All of which is covered under license agreements. So, it's important that we understand the license agreements that we're agreeing to as we use software, and then we have contributed some software back to the community. Things that aren't our core bread and butter things, tools, things like that we've created, that we've put open-source licenses on, so we've had to make a decision as to what open-source licenses to use ourselves.
Charlie: I'd like to just start at what I call the beginning of this, and that is that I just think the audience here needs to have a quick primer on what these licenses are, and why there is even a need for a license, and what they—the different types that are out there because in my research I found that there are many named licenses, but it can really be distilled down into just two different types of licenses. You want out about that?
Walden: Yeah. There are a couple different kinds of licenses that people would use; some would call them permissive and restrictive; others would go down and name them by their name whether that's the GP or MIT or BDS or the MSPL. There are if you will standard licenses out there that different people have adopted within the community.
Charlie: You know one thing I learned very quickly when I started this little research on my own was that it's alphabet soup, and I think you're already started that just by naming some of licenses. And of course, each of those are acronyms, and they do have real meaning although you mentioned, I heard you say GPL which is stands for the Gnu General Public License and let's start with that one because that—that goes into the one of the more, or perhaps even the most, restrictive license, GPL. Why don't you talk about GPL, what that is, just to have some basic understanding of what its intent is.
Walden: Sure. The GPL, and it's funny that you used the term restrictive. I too would call the GPL restrictive, and yet I think the proponents of the GPL would call it permissive, and we have to take a step back and say, you who’s view are we talking about here? From the user of a piece of software, if I'm a developer writing something for my company, the GPL put certain restrictions on me the user of that software, certain conditions that I have to meet around releasing my software and what licenses I can release it under. Proponents of the GPL would actually say that is not restrictive, it's permissive. It's ensuring that I permit others to build upon the software that I've built because I got to build upon the software that people built and released under the GPL, so it's funny even things as seemingly obvious as permissive and restrictive have flipped meanings depending on who's point of view, you're taking.
Charlie: Let's go from the perspective of me as a consumer, somebody who wants to incorporate one of these projects into my shop.
Walden: Exactly. Yeah, and that's what we're all doing, right? We're writing software for our company. Maybe our companies are ISV's; maybe our companies are warehousing and distribution companies, or banks, but we're trying to write a line of business applications that our companies are going to use. We're not creating open-source software for the i and we're going to use pieces of software under that license, under whatever license applies, and the GPL has some certain, what I would call, cautions around it, or concerns and specifically those have to do with what are the rules that I have to follow with this software and if I release my software. And release is a relative term here, I may be required to release it including its source code under the GPL to others, and so in the most extreme example you can make an argument that says if you use GPL software, you then have to release your software under the GPL. There are certainly caveats and exceptions and not always the case scenarios but as a developer writing something for my company, that's a caution. That's something that I cannot simply go out and grab a piece of GPL software, slap it into my warehousing, up and call it a day.
Charlie: So, with my research with regards directly towards GPL projects, there’s this discussion also of arm’s length, or is the software that I'm using, or I intend to be using, is that decoupled from my application or is going be embedded into my application. I think that might give us—that might give me some pause on how, if this is a product or a project I want to incorporate or not, how am I using this because certainly there are lots of tools out there that may be licensed under GPL, but they're perfectly valid for me to use in my shop, and nor should I shun them necessarily.
Walden: Absolutely correct. There's nothing we're talking about says don't use GPL. It just says be aware of what you're doing, and how you're using it. So, I think we can talk about three scenarios, the two outsides that are pretty obvious safe and unsafe, but then that fuzzy part in the middle. For example, if I go out and find some GPL software that does something I need and I copy it, and I come over to my RPG source member and I paste it and it's in the middle of my application, I think we can safely say that piece of GPL is an intimate part of my application now. On the other side if I go out and get a source editor and use that to write my RPG but essentially, it's notepad, then I used a piece of the GPL software, but I think we'd all agree that piece of GPL software is not part of my application.
Charlie: There's your decoupling right there.
Walden: You’re very decoupled right there. Then you have maybe the fuzzy middle ground. I go out and find a piece of software that does something. I don't put it into my application, but it runs queue batch, and it listens on a data queue and I write a piece of RPG that sends data queue entries. This piece of GPL software does something and sends back data queue entries. Is that piece of software part of my application? I think you can make an argument on both sides, that sort of the fuzzy middle ground. It's not built into my application, but it's certainly integral part. It's not as disconnected as the source editor was that I used to write my software.
Charlie: So, this I think explains why there is this potential fear are out there, and more than—more likely a lot of misunderstanding about GPL, but we're not—no pun intended. We are not restricted to only GPL projects. In fact, I think this I would venture to say the larger portion of what's available out in the open-source community is not GPL. It's probably more permissive, or just permissive.
Walden: Absolutely, and I think if you look at the statistics over the past decade, you'll see less and less GPL software and more and more MIT or BSD or Apache or MSPL, any of the, as you and I would both agree, the more permissive licenses. And I think the GPL just is such a famous license. It's hard to talk about licensing without the GPL being part of that conversation, but it absolutely isn't the only one out there and more and more people releasing software are looking at the more permissive licenses. The GPL does a marvelous job forcing a community, forcing you to give back to that community and grow the community, and that can be beneficial, but the other more permissive licenses take a different approach and say, let's get more people involved. Let's perhaps not scare people the way the GPL might and by doing that, we'll actually grow a community differently because we’ll grow a community with commercial software developers as well.
Charlie: So, what are your thoughts on—why would somebody—now, let’s just turn the tables for a minute. Why would I, as a developer, what would incent me to share code with the community and slap a GPL license on it?
Walden: The GPL essentially makes it so that if you write something as a developer, I can not come along, swipe it, turn it into a commercial product, become a billionaire and retire to Bora Bora on the hard work that you did writing that piece of software. And I think that's part of what the GPL tries to preserve, is the freedom of software, and the free distribution of software without commercial restrictions as opposed to what I can get away, if you will, in some of the more permissive licenses.
Charlie: All right. So, we've spent a lot of time, even in this short podcast, we've spent quite a bit of time on GPL, not that it was not worthy of it because I think it is, but it's not to dismiss the other ones that I think, as we said, are more prevalent. Let's talk about it though because if it's permissive, then it's permissive and it sounds like there have—because there are several different types of licenses under the permissive umbrella, there must be nuances to each one. So, do I need to worry about it, necessarily worry about, if it is MIT, BSD, Apache. Do I care? How does that all apply to me as a consumer of the-of the software?
Walden: I think what you care about as the consumer of the software, and when we talk consumer here, we're talking a developer trying to use that in another product. What you care about is, what is the license that is applied to the piece of software that you're trying to use and is that license acceptable to your organization? At the end of the day, yes, you're correct. MIT, BSD, SMPL, Apache, they're roughly say the same thing. They're relatively permissive. You’re probably OK with any of them but if I'm going to go and use software X, what matters is the license on software x so this is partially a cautionary tale of just looking at licenses and actually saying to yourself I'm about to use a piece of software licensed to according to these terms whenever they may be. Are those terms acceptable to my enterprise and am I in a position to make the determination if those terms are acceptable to my enterprise or do I need to run this up to my manager or senior management or corporate counselor or whoever is in a permission-in a position to make that determination?
Charlie: What I learned in my research is a lot of the permissiveness is more just about attribution, giving credit back to the person created the actual project itself. What I found more interesting was on my phone on any of the more popular apps, I found if you dig you can find this. I found it in the about sections, or the terms or notices section. I was surprised, or maybe I shouldn't be surprised, but I was to find dozens in one app, dozens and dozens of references to all different open-source projects that this app uses, which only speaks to how pervasive this really is.
Walden: Absolutely. We said at the beginning that my company delivers software as a service solutions and in our software, we use commercial and open-source licensed software, and we have an about page. Again, if you know where to look in the application, but we have an about page that lists those attributions and says, hey we used the software. It's licensed under this license. Here's a link to the creator. so that is part of that agreement, that license terms that you're agreeing to is to provide that feedback, and that attribution. It does not have to be a gigantic logo on your front page saying hey this is built on this open-source piece of software, but somewhere in their part of the deal, if you will, for being able to use this open-source software is that you have to at least give credit where credit is due and say, I built this partially using this great piece of software over here.
Charlie: So, I think there is a big take away here, and the takeaway that I see, is you would be well advised to consider using open-source in your applications, but you need to be smart about it. And what I mean when I say smart, you can't just do it without at least looking at the licensing of it, and giving—looking at then how it was intended to be used in your shop for sure.
Walden: Absolutely. I would almost go one step further and say not only should you not be afraid to use open source, but that you're probably doing a disservice to your organization if you're out of hand dismissing open source. Many of the fundamental underlying utilities today that everyone should be using are open-source utilities, and if you try to roll your own as opposed to simply using one that's already out there, you're wasting time trying to build it yourself when somebody else has already built it better, and they have already run into all the problems that you haven't thought of yet and fixed them. So, you're in a much better position using that open-source piece of software then trying to roll it yourself.
Charlie: And not to mention maintaining the application itself. I've seen developers post a bug and within hours that fixes come along, so there are many, many reasons why you want to consider using open source in your shops.
Walden: Absolutely and that does actually bring up an interesting point. We've talked about giving back to the community a little bit, and we said take source and at times give it back to the community, but even a smaller piece of that, report bugs back to the community even if you can't give your source code back, even if you don't make changes to the source code. But if you come across a bug, please go to that open-source piece of software's bug reporting utility wherever that might be and say, hey here is a problem I have found and as you say the developers may be very quick to fix it. They may not be. We're all developers. We understand we can't fix every bug today but we also know we cannot fix a bug at all if we don't know about it so we definitely should be reporting those bugs back to those software—I won't say software vendors, but back to the software projects.
Charlie: So, in the spirit of time, I'm going to start wrapping this up, but I do want to just make this final point to everybody, and that is that—I mentioned at the beginning of this, that I spent 15 to 20 hours. I probably could have spent double that or 10 times that. There is no shortage of this information online about open-source licensing, and I do—even on YouTube, you can find many, many videos. I want to just mention a couple of resources that I thought were particularly interesting, and the first one that really caught my eye was Choosealicense.com. The one will explain to you the different licenses that are available, and how you can use them, why you want to use them and of course with IBM i specifically, we want to look at OSSILE. That’s big one. That's on GitHub. Just Google OSSILE and you will certainly find lots of cool utilities that have been written directly for IBM I, and I think the final one I want to point out is just the governing body itself of the—what we call the Open-Source Initiative, or OSI is how people normally refer to it, and that you can find at opensource.org. Walden, I have a feeling you and I could discuss open-source licensing all day long because it's just a fascinating topic to learn so much more about. Okay, final question. Do I need to care about all of the different licenses that are out there or just the ones that are I'm considering using in my shop?
Walden: If you are that developer consumer, if you're trying to use pieces of software not releasing your own open-source products, then the only licenses you care about are the ones that apply to the software that you're trying to use, and so it really should narrow that scope down to what do I care about and typically these are not long documents. You mentioned OSSILE. Their license agreement is 21 lines. It's the MIT license. You can read it. You can understand it. It's not hard so definitely just look at the licenses for the products you care about and that's all you really need to worry about. If you're trying to release software, then which flavor of license becomes something you might care about.
Charlie: All right. Walden, I want to thank you for your time today. This to me was absolutely fascinating and I'm so happy that you shed little light on this. Final disclosure, or the final reminder disclosure, is that neither one of us are lawyers and certainly that's a point that I want to just drive home because we are talking about legal terms as Walden did say. I want to thank you for your time, Walden.
Walden: My pleasure. Thank you for having me.
Charlie: Absolutely and to everybody listening to Tech Talk, I'll be back with another podcast next month, but in the meantime make sure you check out some of the other content on TechChannel. You can subscribe to their weekly newsletters, webinars, e-books, solutions directory and more on their subscription page. Take care everybody. Talk to you soon. Bye now.
Charlie Guarino // President, Central Park Data Systems
See more by Charlie Guarino