Open Source Licenses with Matt McInnis, Tom Cudd, and Ray Deck

Show Notes:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

• Virtual Coffee: virtualcoffee.io
• Podcast Contact: podcast@virtualcoffee.io
• Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw
• Dan: dtott.com, Twitter: @danieltott

Transcript:

Bekah: 00:08

Hello and welcome to season 9 episode 3 of the Virtual Coffee podcast. We're grateful to be sponsored by Level Up Financial Planning, who understands the importance of finding balance between having an awesome life today and being confident and excited about your future possibilities. If you want to take your financial confidence to the next level, check out levelupfinancialplanning.com and you can get that link in our show notes. I'm Bekah and this is a podcast that features members of the Virtual Coffee community. Virtual Coffee is an intimate community of people at all stages of their tech journey and they're here on this podcast sharing their stories and what they've learned and we're here to share it with you. Here with me today is my co host Dan Ott.

Dan: 00:56

what up, Beck?

Bekah: 00:58

Nothing, nothing is up at all. So,

Dan: 01:01

All right.

Bekah: 01:03

all down.

Dan: 01:03

what? We have, uh, I got something to fix that for you. Today we are joined by three of our awesome members. Uh, it's a panel, if you will. Matt McInnis, Tom Cudd, and Ray Deck. And they are talking about open source licensing. Which sounds probably pretty boring, but if you listen to the episode, you'll see that it's actually pretty interesting. There's a lot of things to think about when it goes into that. And, um, whether you are a maintainer, like creating a project or, um, a consumer of open source products, products, projects, both, I suppose, uh, licensing can, can matter, you know, and can affect your decision making process. So, uh, it was really cool. We had, you know, these guys were on and, And all three of them have, uh, experience dealing with licensing issues, you know, both with work and with personal projects. Um, so it was, it was cool hearing their stories and kind of digging in a little bit to what, what kinds of things they think about, uh, with regards to open source licensing.

Bekah: 02:06

Yeah, it was nice to have the conversation, get some practical advice and also talk about some recent open source licensing news that had happened. So it was like seeing it in action. How does changing a license impact a project? And this is, that's one of the reasons why you should care about open source licenses. So it was really a fruitful conversation where we talked through some really interesting ideas. About open source.

Dan: 02:36

Yeah. Ideas and different scenarios you could run into. You know, from any point in the, in the project, uh, timeline. So, I dunno. It is, it is a cool discussion and I think you're going to enjoy it.

Bekah: 02:47

Yep, and we started this episode like we start every Virtual Coffee. We introduced ourselves with our name, where we're from, what we do, and because we are Hacktoberfest themed, our check in question was Hacktoberfest themed as well. We hope you enjoy this episode. Is Today's random question is, what is the first word that comes to your mind when you think about open source licenses? So, my name is Bekah. I am the developer experience lead at OpenSauced from a small town in Ohio. And, uh, I don't think that there's really a word that comes to mind, more of like, just a sound, like, uh. So this will be an interesting podcast episode. Go ahead, Dan.

Dan: 03:41

Uh, wait for the recording. Can you just do the sound one more time? I'm not sure if we got it.

Bekah: 03:45

Oh, yeah. Wait

Dan: 03:50

All right. Okay. Uh, alright, yeah, I'm Dan. Um, I am a developer in Cleveland. And, open source licensing, I don't know. I think, uh, confusion would be my word. You know, um, I have A couple times dug into it a little bit, and I don't really, I didn't really retain anything that I learned, you know. It was like enough to pick a license for a project that I was working on, and then I moved on and, Um, So yeah, that's, that's been, confusion is, is my word. Uh, Matt, why don't you get going?

Matt: 04:22

Yeah, thanks Dan. Uh, my name is Matt McInnes. I'm a developer, data scientist in Toronto, Canada. Uh, the first word that comes to my mind around open source licenses is probably, uh, why. I, I'm really curious always why projects open source themselves. Um, and I think that that helps me get to the nature of, you know, the probably the other, the other word I thought about saying is can I use, and I was hoping I could pick it back on that, you know, amazing can I use website, but, uh, it'd probably be why, you know, why did somebody choose to do this?

Dan: 04:50

Nice, I like that. Uh, Ray, go ahead.

Ray: 04:53

Hi, I'm Ray Dack, I'm based in Northern Vermont, I'm a data scientist by training, been doing software startups years, and, uh, the word that comes to my mind is messy.

Dan: 05:04

Mm hmm, that's a good one. Uh, alright, thanks. And, uh, finally, Tom.

Tom: 05:09

Thanks. Uh, yeah, my name is Tom Cudd. I'm a cloud engineer in the Kansas City, Missouri area. Uh, and the one word I think of when it comes to open source licensing is divergent. Because they always seem to be like, uh, you know, someone attaches a license to something and then they're like, oh, well, maybe we should use this one instead. Or should we use this one? Or which one should we actually be using? And nobody really knows.

Bekah: 05:45

I think that's probably a good place to start. So, um, I, I know that we've all been involved in open source in some capacity, but what are, What is the process, or how do folks get started considering, like, what license should I use to begin with?

Matt: 06:01

I'll, uh, you know, just jumping in on that, I think the first thing I look for is, you know, when I jump on GitHub, if I'm looking for software, see if I can integrate it into my systems, I look to see if there's a familiar license attached to it. And, you know, to me, those are, you know, the Apache license or more commonly the MIT license, which means I can use it with attribution. And that's almost certainly my starting point for trying to figure that out.

Dan: 06:27

Do you, you, um, so you look at licenses, like when you are, you know, considering adding a package, uh, do you make different decisions based on if it's a personal project or a work project? Like, you know, what kinds of, what kinds of like, what was your thinking process? You know, when, when you're looking at those.

Matt: 06:49

It's such a good question, Dan, and I'll, you know, open it up after this for everyone to kind of take that on. For me, it's, um, it's not a different choice. Um, I think, you know, I have such limited time to learn, you know, and develop my skills these days that I really don't want to invest my time into something that I can only use in a limited capacity. Um, so if I see there's a license attached that, you know, is highly permissible for personal projects, but has like a non commercial and other things. You know, a portion of it, I usually turn the page almost immediately and I'd love to hear what other people think about that too.

Tom: 07:27

Yeah, I'll jump in here. One of the things I noticed, uh, early on in my career is that I liked to, uh, separate and create distinct, you know, platforms for when I'm doing work and when I'm doing personal projects. Um, so I also am very careful to uh, to only use software that Permisses. That gives you permission to, uh, to use it for, for financial gain. Because, um, if I'm creating a personal project, I, I don't usually just create things for fun, uh, eventually. If I, if I do something on the side, I'm, I would, Like it to make money, uh, so I don't want it to be restricted in that way um Which is which is interesting because that's the almost the exact opposite of what I do with work. We we we look for software that has commercial, uh Uh, options because we need the support. Uh, and I have, um, the benefit of when I work in the office, there's actually, um, specialists that I can turn to that actually read through the license agreements and acknowledgments and do all that kind of, like, they actually read all the EULAs and all the stuff that you are allowed and not allowed to do and say, yes, we can use this or no, we can't, and sometimes I wish, uh, like I had a, you know, A way to do that other than on my own for any personal projects.

Bekah: 09:05

Chat GPT. Just throwing it out

Ray: 09:11

Yeah, the, uh, when I'm looking at what to, if I'm creating something that I was going to be put into the open source domain, I will pick the MIT license every day of the week. Uh, it allows other people to build on top of it. And most of the time, if I'm building something in open sources because of the tool that other people are going to use, if I'm looking to build something I want to offer as a service, then I'm going to Basically put no license onto it in GitHub, which is sort of the trick to say that even if it happens to be a public GitHub, nobody can actually do anything with it because the light because you reserve all of your copyright. That is the default position of anything that you write. You own it. The, um, the, the, and when I'm looking for like what licenses would be in the software. If I'm looking for it as something that I'm going to be taking as open source, uh, that I'm incorporating into what I'm doing, incorporating at like the static linking or compilation level, uh, yeah, I would similarly look for either LGPL, MIT, you know, something similarly highly permissive. Uh, if, but I've also been in a number of situations where it's like the, the technique is you have a service. Right? And their software, they have decided to open source and they're going to put like either a dual license or a much more restrictive viral form of license. I mean, anybody can remember the AFL from back in the day, which had a similar thing going on so that I can better understand how to use that service. Right, which is separate from the question of what I would be incorporating as a, you know, as open source. So I'm going to be compiling it, and I think that that that's the kind of distinction between like dynamic or service level linking versus static linking that was a very big deal back in the early days of the Free Software Foundation and sort of has sort of stuck in my memory as a way of thinking about what's, what's the way that I'm going to be interacting with the software and therefore what kind of license do I care about?

Dan: 10:56

Uh, yeah, so that's, that's like, I mean, thank you all for those answers. I, I think maybe it would be good, this would be maybe a good time to see if we can break down some of the, like, more common, like we're, we, we've all, like, we've all been thrown around some, some terms that if you're been using open source for a while and you, you know, you think about this sort of thing, you, you kind of, uh, You learn, I guess, over the, over time, but maybe for some of our listeners that aren't as familiar, uh, we could break down some of the different types, like the more common ones, uh, Ray, you mentioned the MIT license. Um, I don't know, I don't know how detailed to get into this cause I think there's a million variations of all the licenses, but, um, maybe we could. I don't know, break down at least some of the like top level, top level, like ones, uh, that you're looking for when you're, when you're, when you're digging in, um, Ray, do you want to start us out? Like, uh, what is the MIT license for instance?

Ray: 11:48

The essence of the MIT license, which I think is sort of a downstream of the old BSD license, um, is go ahead, um, make derivative works from it. Go ahead and make changes. Go ahead and use it. Uh, credit us for, credit the author, uh, that you have, so you're not, uh, uh, you, you don't get to, um, say that you created this thing that somebody else created. But R that go to town, uh, is basically the most permissive of the licenses, um, and the one that I think is most favorable if you're looking to incorporate it into a broader project that might have some commercial, uh, application to it.

Dan: 12:25

What are some of the other licenses that we might run into, uh, uh, on a given, you know, on a given day?

Matt: 12:32

I think another one that's, one that I see a lot of is the Apache license or the Apache 2 license, um, which In essence is they do anything, uh, and, you know, feel free to anyone to add to this, but, you know, you know, maybe just like think about the categories of what these licenses so we can give a framework to thinking about them. I think that there are these, like, what are the main parts that I look for? One of them we talked about a little bit earlier is, is there an obligation to do something? If I use this commercially, um, and that could be in the case of the LGPL license. I, and Greg, correct me if I'm misremembering, but, uh, if I use a software, so like a gem or a JavaScript library to contextualize this and I use it in my system, but I decided to modify it in some way, I believe I have to. Publish my modified version as an open source. Not the whole app, but just my modified version of that library, uh, as an open source with the same license. Cool. And then, so, one of the dimensions is, what do I have to do with this? If I, what are my obligations if I use this commercially? Another dimension is, um, what are my, what are the implications if I use this as part of a bigger project? So that's where I'm sure later on we'll talk about what copyleft is, but, you know, as an example, if I use this JavaScript library as part of my project, do I have to open source the whole project now? And that's, uh, part of this copyleft idea. Um, and, uh, Those are really two of the big silos there, but going back to Dan, your question there, the MIT as Ray had mentioned is the biggest one, I think. The Apache too, which means you can do anything you want with it. And then I think the LGPL, which is, you can do anything you want with it, but if you change it, you got to publish those changes, which I think is super fair as well.

Dan: 14:19

Yeah, yeah, thank you. Uh, I mean, we might as well just at least define what, what copyleft is. I think if you Google something like, you know, uh, what are some open source licenses or whatever, most articles talk about copyleft and they talk about permissive licenses, right? Uh, so can somebody try and define what copyleft means for us? Anybody?

Ray: 14:44

left?

Tom: 14:45

Are there any lawyers on the call?

Matt: 14:49

A catastrophic death sentence to your project might be like my, uh, Yeah,

Ray: 14:55

Go ahead. Alright, I was just gonna say that like the, uh, the copyleft is a more, is a more common term nowadays, but like particularly in the world of software business, the term that came up 20 years ago and I still hear from time to time is viral. And the idea is that like the GPL is viral. If you have GPL software in your system, stack the link to it, um, it's a virus. Uh, that now changes the licensing of the rest of your software, that then forces the rest of your software to have to be distributed as GPL itself. This is something that happened to, uh, and, and, and that triggers on distribution. So if you distribute, Your software that is linked to software that's on the GPL, you then need to distribute your software on the GPL as well. And then there are some interesting lawsuits about this, like particular people who make routers like Netgear, I think went through this a while ago, where they had to distribute the firmware right for their routers as a result of having incorporated GPL software into it because they got sued by the FSF. And the, and that's something that, uh, I think a lot of software companies worry about in terms of, uh, is this going to cause a problem? It's actually one of the reasons why, you know, when you sort of look back like, you know, 16, 17 years ago, um, SAS became a much more popular thing because it was an end run around that licensing. Because you could use all the GPL software you want because you were never distributing the software. Right? You're providing people access to your software. So in addition to being a way to get recurring revenue, it was an end run around this licensing allow you to make use of all the stuff that got built up around the, um, around that software. So one of the key, and that also led to things like the AFL, uh, and licenses like it that would attach the SAS basis. So like there's this little bit of a You know, um, you know, cat and mouse game going on of how are people exploiting, uh, open source software for commercial use and how then do you lock that down? And that's sort of, you have the permissive software at one end. That's sort of the MIT LGPL level. You have the viral attachment in the middle, and that's going to be like the GPL, you know, uh, uh, AFL, uh, license. And then you have, um, You know, basically, uh, you know, split licenses, right? That say, hey, it's open source if it's non commercial, but you're not permitted to use it commercially. And those would be the three, uh, three levels I would look at, you know, when I'm thinking about what software to use for business. Things that are allowed to be used commercially at all, or first, or require a fee for it. Things that have a viral attachment, that's GPL level, and things that are permissive, which would be the MIT LGPL level.

Dan: 17:36

Awesome. Yeah. Thank you

Ray: 17:38

you know, nuances.

Dan: 17:39

Right. Yeah. I think with all of these, there's different little small versions of each one. You know, I know there's different versions of the Apache license, for instance. I assume there's different versions of MIT. I'm not really sure. But, um, but yeah, there's, there's like, well, as you can see, there's, there's lots of different ways. Uh, Lots of different options out there, right? Lots of different possibilities. Okay, so we talked about, like, alright, so there's kind of two ways, or two things to think about with licensing, right? There's, uh, packages that you're consuming, and there's... You know, licensing your own work, right? Um, so can somebody talk a little bit about like, uh, I know we've touched on it a little bit, but, uh, what kind of thought you put in, like, what kind of decisions you're making and what, what, what's your thinking process when you are licensing your own project? And I can already feel the, the, it depends coming, right? And so, um, I guess there's like, there's different kinds of projects, right? There's, there's like, um, a package that, you know, you're, you're. Making use, being available to other developers to use in their projects. There's, um, uh, an app or something, right? Like a, uh, like a CMS or something, you know, like, I don't know, anything, anything that's like that, or, or just even a website, right? Like I have my own website is on GitHub and it's public. Um, and so that's just content, right? Um, So, what are some, what are some of the things you think about, and you can choose any of those, those paths forward, whatever is most common for you, I suppose. Uh, what are some things that you think about when licensing your own, uh, your own projects?

Tom: 19:11

I'll say to raise point, uh, earlier, um, whether out of laziness or the fact that the default option is just the way to go. When I create projects, like in my GitHub, I usually don't attach a license to it. Um, And now I have, when I have created projects for use in, uh, workshops or presentations where I need to give people code, I, I do usually attach a license to it. I usually just attach the Apache Foundation license just for the sake of making things very clear. Um, and that's one that I'm probably most familiar with and, and comfortable using, um, just from, Over the years of my working with various Apache projects. Um, so that's um, that's usually how I do things I haven't had anything that hit hits such a drastic use that I felt the need to attach any kind of Software license to it, you know, most of my projects are not, you know, hitting the big time and get picked up or even Getting on the, the microservices selling list. So, uh, but for the most part, um, yeah, I don't attach a license to things unless I find, uh, a necessity for it.

Dan: 20:30

That's really interesting. And that, that, the concept of, of that, you know, uh, project not having a license being, you know, fully reserved is I think an important thing to, to highlight and maybe something that not everybody knows or understands, right? If you come across a project that doesn't have any license, you know, like everybody has said, it is. Like, all rights are reserved, right? But there's still that big fork button up there, you know? And, uh, uh, the GitHub, um, Terms of Service, I think, allow forks, but I don't know what you would do with a fork if you're not allowed to, like... I mean, maybe somebody can answer this question for me. If the project doesn't have a license and you fork that project, are you then not allowed to make any commits to it or whatever? Like, you know, what's the... I mean, I suppose you... Now I'm getting myself turned around because I really don't know what the answer is. Does anybody have, like, a concept to that? Like, let's imagine that you're trying to fix a bug. Is that... I suppose if you fork it, you're not using it, right? Somebody's got to interrupt me because I'm just going to keep... I'm

Ray: 21:31

Let, let's take software out of the, out of, out of the picture for a minute. Let's say, uh, that you know, Dan, you wrote a blog post and I decided that your blog post has lots of typos in it, and I go make a copy of your blog post, and then I fix the typos and I post it up on my own. That would be a clear violation of your intellectual property, right? So the same software is just content, right? It's just text under the covers. It's exactly the same.

Dan: 22:01

Right, but if you have, I mean, and the only way to do any part of what you're describing on GitHub is to fork it first, right? Because you can't push branches to somebody's, somebody else's repository, right?

Ray: 22:13

Copy it. download it. Yeah, sure. I take your point.

Dan: 22:15

no, no, sure, but like, let's say you see that blog post of mine. That I wrote my one serially blog post and you notice my many typos and you fork and you're like I want to fix this for Dan not to publish on my own site like not to steal it, right? but like, you know, and so you you fork it right and then you Have to clone it down to your machine and you fix the typos and you push it up to your fork and now you've modified the forked version of My blog post and then you send a pull request into my site, right? Like you're not doing anything nefarious You're trying to help me and I have no license on my site What? Have you broken any rules? Is that okay? Like, I don't, like, this is, this is now, now I'm like in the, in

Ray: 22:55

There's no damages because I haven't profited from it, but I've done something wrong, which is I have published by putting it up onto a public site. I've taken your content, right, and altered it. It's called a derivative work, and I didn't have a right to create that derivative work except under very specific circumstances like satire, right? If I was looking to make fun of Dan, I would be allowed to do that under satire rules. I could make a parody of Dan. We could make Dan GPT. There's a whole bunch of

Dan: 23:22

I don't like, I don't like how this conversation is going.

Ray: 23:25

there. But the, uh, but, but, but the, and, and the reason I think sort of looking at content, sort of clarifying that way, because the code isn't different. Code is just content. It's just the, it's just the, the, the artifacts that come out of our brains, right. That we're articulating a way that just meant to be, be read by a machine, I suppose, being read by a person.

Bekah: 23:43

Okay, so can I ask a more specific question about this? So, recently, Terraform changed their license, right? And so, a bunch of folks have, uh, forked and cloned that repository and are now using their forked version. That, that can't be okay, right?

Matt: 24:06

this is a great question, Bekah, and please again, correct me if my understanding is wrong here, but my Understanding about situations like Terraform is that the version of the code is licensed. So I think what you're seeing with Terraform is people are attaching to the last open version of the software and seeking to take that version into a different direction as a community to compete with Terraform, who has presumably been the primary committer to that repo. Um, which I think is a really interesting thing to watch evolve. You know, to use, I love your question, Dan, I think it's such a really good one. It just said, like, you know, I think there's a couple of things that if you're listening to this and you're not as deep into licenses, just to really give, like, to make that concrete when, if like Matt forked Dan's blog post, um, on GitHub, right? So I go in, I fork Dan's blog post, I make these corrections, and then I maybe send a PR, or maybe I don't back to Dan. Uh, that, you know, when we say that Matt has published that work, uh, the reason for that is that if some user stumbled onto Matt's GitHub, and clicked on that repo, and maybe didn't notice that it was forked from Dan, uh, you know, and they look at this blog post that Matt wrote, Um, they would incorrectly attribute that work to me and I did not have the right to fork that. So I think that's where like the ethical and like the professional piece comes in. It's like, yeah, I'm violating that copyright because somebody who went down that path would see that and think it's my work. And that's problematic. And the other thing I think that's really helpful to clarify for folks that really aren't in this is we were talking about, you know, publishing something to GitHub as an example. Uh, And having no license attached. So what does that actually look like on GitHub? And I think there's, there's two places that I, I see this in, you know, kind of confusing ways and what we're used to seeing in GitHub repos is a file in the root directory that's all capitals called license. md. And that is the attached license to the project, and GitHub will pick that up automatically and put some more information if it's a known license. In fact, you can even use GitHub to attach a known license to your project. The other place that, uh, you sometimes see that is if it's a JavaScript file or repo in particular. Is if there's no license. md file, you may see in the package. json file, uh, a field there for the license. And some of the things I'm used to seeing there are, there's, it's not just being empty, you could just see MIT in there, but those are indicators of a license being attached as well, but. Yeah, I think that might be just helpful context for those pieces, but going back to your comment there, Bekah, about what's happening with Terraform, that's my understanding of that particular situation is the community is trying to grab the last open version and then run with it.

Dan: 26:53

Ah, that's a really interesting situation. I hadn't, I hadn't heard about that. Um. The, uh, honestly, the concept of a license being attached to a specific version is really interesting too. That's another thing that I hadn't thought about. Um, and I think probably... It speaks in favor of either being very, very careful and thoughtful with attaching a license to a project or not attaching any license to a project, right, at the start. Um, because you could run into that problem that Terraform has now run into where they want to change their license to be more restrictive. But the code that was released up until they made that change is still under the old license, right? And you can always do this in GitHub. You can go and look at old commits and old branches. I wonder if they're going to end up deleting... I mean, those forks exist, and I think it sounds like they're legal. Um, they probably could go in and edit their, you know, the git history or whatever, however you do it, and delete the old versions. Um, but still, you know, that's a really interesting

Tom: 27:54

You know, I think what we're we're getting at with this, um, particular bit of news, and it's, it's happened in, in software for years and years and years. This is, this is sort of a known path for business commercialization. You open source your software to a point to where you feel like you've got The potential for really excellent market share by going to a business software license, um, and, and taking that opportunity to, um, accelerate your commercialization of the software, um, but There's two sides to this. Yeah, if it's a company that needs to make money, they got to do what they got to do in order to make money. And if you were in the same boat, you might consider the same thing. What I have seen with um, as the open source moves to more closed source, the, the novel ideas and the innovation that comes with, um, An open source model kind of dries up. So like Terraform, when it came out was pretty innovative, uh, and still is. Uh, and the, the concern is that that innovation that made it one of the most powerful infrastructure tools available to cloud engineers like myself, uh, it. It could be, uh, it could be damaging to the long term prospects of being able to, uh, innovate and, and do cool things with your infrastructure in the cloud. Um, so there are, there are two sides to that coin. Maybe some of that innovation goes away. Maybe, uh, that company now doesn't, you know, go under because they can, uh, they can get people to pay for their software and support. So

Dan: 29:48

Yeah, that's, I mean, like, thank you, Tom, that's, that's a really good point. And, you know, I have seen, I've seen both things. I, I've seen some companies moving more towards closed source. I have also seen, um, companies with paid products, open sourcing their, their code, right? Um, what, the one that comes to mind in, in my mind is craft, uh, CMS. And that's only because I, I use it a lot, but, um, they're. They're owned by a company called Pixel and Tonic and they made a CMS and it's a paid product and it used to be you'd go on their website and pay money and then download a zip file or whatever, right? And at some point, this was a few years ago, but they open sourced their CMS product and it's a paid product, right? Um, and the, but the code is open source, right? Um, and the licenses, uh, is not any one of the You know, like usual ones, I suppose it's, uh, it's kind of short and it just basically says you can do whatever you want, except that you cannot interfere with the licensing, like. piece of this software, right? And so when you install CraftCMS locally, you can run it as much as you want as soon as you publish it. I've never seen it shut down, but it'll show a big red banner that says, you know, this is like, this is a non licensed version, you know, go here to Go here to buy a license. Right. Um, and this is like not, when I say license. Now, I'm not saying, uh, an open source license. I'm saying like, buy basically you're going to buy a code. You know, that, that unlocks it. Um, but it's a, it's really interesting model. I don't, I don't know if anybody has seen anything similar to that, but I, and I think that they're getting some of that, um, Juice that Tom was mentioning, um, that, you know, you, you can go, I can go and, and file issues or, or fix things, um, because it's still a product that I love and I use, and even though I pay for it, um, per, you know, site or whatever, um, that doesn't mean that they don't need, like this way they can get some of that open source help and some of the innovation and suggestions, things like that, um, while still being able to make money

Tom: 31:46

You You At

Dan: 31:46

of it, I suppose. And, you know.

Tom: 31:48

and like Kubernetes is an example of an infrastructure tool that is open source, but has a number of commercialized options and native implementations by the cloud providers that make plenty of money off of it. But it's as impressive a tool as it is, I think, because of the foundation that it's associated with the cloud native, uh, CNCF, uh, cloud native, uh, whatever the C other C Stanford, uh, foundation, uh, and, and they, they built, uh, you know, a mechanism to support that kind of open source software with, um, you know, backing by like Google and other organizations that commit a certain number of developers to it. So, uh, it is being propped up, but it's being heavily used by those organizations. So it's, it's a mutually beneficial, uh, arrangement.

Matt: 32:45

I, uh, you're touching, you're both touching on a topic I care a lot about, which is why, why do people open source these things in the first place? And I, you know, I, I'm going to throw a question over to you in a second. Dan, I'm going to throw this right back at you, but, um, you know, having worked in the cloud space, uh, at Microsoft previously, you know, and also just at the personal level, one of the things that I find really interesting and a little bit, you know, Uh, it strikes me at the values level is when something is perceived as like benevolent, benevolent, but it's not really, it's actually self serving and deliberately self serving. And, uh, and for those, and I become really fascinated about that and then go on a mission to clarify that for the world. And, um, you know, and Dan, some of the reasons that you're describing, uh, I think I wrote craft CMS, uh, the, you know, engagement with the community developers, potentially helping move that project forward. Uh, you know, getting a better connection and making that CMS better. Um, a lot of those, they, they could've and probably did before open sourcing it. And I'm sure they had relationships with their customers. They probably have a customer success department. Um, so I'd love to hear people's reasons just focusing on that example. And Dan, maybe if you're open to starting, why would they do this? What is CMS to take? Their product and open source it, presumably attach a commercially open license to it. I can check that, uh, which has a business risk of somebody taking that and then starting a competing company, or maybe their license specifically prohibits that, but. Why would folks think that they would do

Dan: 34:24

That's a great question. I would like, if anybody else has answers.

Bekah: 34:28

I don't have an answer about craft, but I do have an answer for other organizations and it's government contracts. Um, so for some, um, government contracts, you have to have an open source license or your software has to be open source, uh, in order to, um, be able to get those contracts. So there's some transparency over who is contributing. And I think that there's some kind of legislation coming up in the U. S. In the next couple of years that will say that if somebody from particular countries touches your code base, then it's not eligible for a government contract. So, um, uh, we should definitely fact check that or someone should fact check that. But I, I do know that that is one of, uh, the big considerations for, um, pretend open sourcing projects,

Tom: 35:18

I can, I can tell you that, um, when working in the enterprise, uh, and I've worked with some large companies and small companies and everything in between, um, as clients, uh, the word that you get. thrown around a lot is indemnification. So like who is responsible when something bad happens because of that software? Uh, and, and so there is a question of, um, large corporations, fortune 500s, they often will go to, um, commercialized software because they want support and, um, And if there's a, like a security risk, uh, related or, or if there's a breach related to that software, I, I hate the use of the violent language, but I've, I've heard managers say one throat to choke when something bad happens because they need to reach out and go, like, this is, this is not good and you are responsible for it. And so there is the, um, The move away from true, full, open source in some, um, corporations, because they need to be able to, to, uh, essentially sue somebody if something goes drastically wrong.

Dan: 36:41

Yeah, that's, that's how I feel like, you know, when you think about licensing and things like this, this is like getting sued. If something goes really wrong, it's, I feel like, uh, one of the big worries and one of the like situations where I'm like, well, I don't even know, you know, I'm just going to pick whatever. Will protect me from being sued, you know

Tom: 37:05

I'm just

Dan: 37:05

don't know. It's not a situation, you know, I want to run into, right? Um, yeah, I mean, I mean, you know, Matt, Matt, like go back to your question. Like, why would, why would somebody open source their, their product? Um, you know, I mean, I don't really know. I was just like trying to search around, see if I could find their blog posts from when they did it, but I can't find it yet. Um, but the. For me, I would, I would think, I mean, I think engaging the community is like one of the things, I mean, I'm sure you're right. Like, I know that they did have like a help center or whatever, like you could submit, you know, help requests and things like that. Um, and when you paid, you could download the, I think actually you didn't have to pay to download it. Right. You would download it. Like, I don't know. I don't really remember. I'm trying to remember years back now, but, um, before I think you would download it and like license it inside the software itself. Um, And so, you know, it, you're not like getting any protection from people trying to steal it, for instance, right? I mean, if, if I wanted to steal it back then, even if I had to pay for it, I could pay for it, and then I had the source code. You know, it was always, it was always a self hosted thing. I mean, it wasn't like ever a, or at least primarily a service that you pay for, right? You know, so I, I always had access to the source code, so if I was a bad actor, I could have done that. regardless of whether it's open source or not. And, um, and so I think that there's not like not a lot of downsides to open sourcing. And I think that's where they landed, you know, is you get, you get like, we love, we love open source. Listen to the rest of this season for more reasons why we love open source. Right. But, uh, the, there's a lot of positives, you know, and there's clearly some negatives, but I think that, um, it, I think it like, The positives outweigh the minor, you know, negatives, I think, in my head. That's my answer, not being them, you know? Um, that's, like, my imagining them answer. I don't know if that makes sense at all.

Matt: 39:02

that? That makes perfect sense. And I pulled up their license and I think it's just really interesting given the topic of this conversation to share because it's a non, um, so this is the CraftCMS license that I'm pulling as of today, which is the 18th of 2023, September 18th. Um, it's interesting here. So at the very top is copyright their company at Pixel and Tonic Inc. And it starts really well. So permission is granted. To anyone obtaining a copy of the software, to use, copy, modify, merge, publish, dada dada, subject to the following conditions. And number two is, don't, uh, use the same license on more than one project. Number three is don't mess with the licensing features, and number four is pay up. So payment shall be made, uh, immediately upon receiving a prompt from us to pay. So it seems like what they've done in their license, uh, that can help sort of expose their motivations, is they're trying to, I think, box out other people from using the software to operate their business. So they're preventing other companies from starting up saying, Hey, we're going to operate a CMS company here. Uh, and we're just going to use this and go sell the companies who want to CMS. It doesn't seem like that fits the context of the license, although it's not clear, but they also get all the benefits of open sourcing, which are numerous, including. All the things you described it, right? Like the community engagement. I could be a client and just want to see a new feature in the product. I could just go make it. Um, the, you get a lot of trust. You open yourself up to government contracts, Bekah. Uh, all those nice things. So it's. It's interesting here. I think this is, this is a topic I think around open source licensing I'm most interested in and I want to come back at some point to, uh, talk about the, uh, Tom's comment about kubernetes. It's one that's close to some of the experiences I've had before, but, uh, you know, it's interesting looking at these.

Dan: 40:46

Yeah, yeah, it's a, it's a, it's an interesting use case for sure. And, um, I, it seems like it's working out for them, you know, from what I can tell. Uh, you know, and I'm glad. You know, I'm glad they didn't have to, like, go back or whatever. Um. The, the, another like topic that has been, that I've run into a number of times with, especially with my work with Virtual Coffee is, um, and I would be curious to see if anybody has run into this situation or knows any solutions. But, um, so if you. are on the Virtual Coffees repo, right? There is code like there's code that create, you know, generates the website. It uses packages, things like that. There's also a lot of content on the site. Right. Um, and I have been in the situation, like what I want to do in those situations. And this is the same with like my personal blog, right? Is have a separate license for. The code and for the content and I wonder if anybody has run into that scene that has any examples of that. I tried, I've tried finding examples and have failed a bunch of times. So, um, this is my, this is my, I've got, you know, four other people on this call. Maybe somebody can help me a little bit. Yeah.

Matt: 41:59

Yeah, may I jump in on? So this is something we see in data science a lot. The, um, you know, data science, of course, the field of machine learning, AI, all those things that are all synonyms for each other. Now they are. They used to, you know, spark battles with math geeks like me. Um, but, uh, something we see in data science a lot is, like, if you take a look at the one thing we're ChatGPT, OpenAI assembled a huge dataset. They wrote code. to train a model, and then on the other side, a model came out of the product of those first two things, the data and the code that was used to generate the model. This is the fourth category I'll leave out. The thing that we see very commonly in data science is that the data, the code that uses the data produced in a model, and the model, which is more specifically the model weights, are licensed differently. And sometimes one is open source, sometimes none are open source, uh, sometimes a couple of them are, uh, and sometimes they have different licenses. And very often what we see is that there's a repo, there's a data folder that has a license in it, uh, or it's a separate repo, and there's a, you know, model code folder, or lib, or, you know, source, uh, that has the code that produces the model, and then there's like a model weight. Folder, uh, that has those things and each of them has their own separate license in them. So it could be that that would be an approach, uh, borrowing from the old data science world that could work. I'm not sure. I'd love to hear other people's thoughts.

Ray: 43:30

I'm actually curious, as a question of fact, uh, Bekah, you work for an open source company, um, a lot of the software is open source, uh, you write a lot of content for them. What's the license for the content you're writing for them?

Bekah: 43:42

the content, uh, we use a Creative Commons license for all of that, um, which is generally. Better for creators, it allows you to maintain control over some of the things that you're doing and offer some permissions to other folks who want to use that. Um, so that's the standard for our content and for our courses. It's, we use a Creative Commons license. Um, our proprietary stuff, stuff with the open sauce name all gets Apache and pretty much everything else is MIT.

Dan: 44:10

do those,

Ray: 44:10

distinction? I just wanted to ask very quickly, is that something you sort of do at the top level of your repo or at the organization level, or how does it become clear which pieces, because it's all content, right? It's either code or human stuff or whatever. Uh, how, how, how, how do you as an organization make that kind of distinction as you decide what kind of license can go with which of the pieces of the puzzle?

Bekah: 44:30

I think for Creative Commons, when we're using that, it's more of like, what is the educational purpose of this? Like, we have a course. So the intent is to instruct other people and to help them get into open source, which is a lot different than like our docs repo, right? Like that's, we're giving you documentation about our products and the things that we're doing there. And so maybe the distinction is in how the audience anticipates using that thing.

Ray: 44:56

Great. Thank you.

Dan: 44:59

Yeah, that's, I mean, I love that. And like, I'm glad you brought that up. Cause it's, you know, Bekah's works at opensauce and, you know, like, like we said, there's a lot of different types of things going on there and that's really interesting, like, and you had those answers, you know what I mean? And so like, you guys have thought about that, obviously a decent amount. Um, I had never considered, and I don't know why, uh, really, but having licenses in subfolders. Um. And I guess part of it is like, I don't know what is either implied or explicitly like said when you're looking at something. And we've been talking about GitHub, so I assume most of the, excuse me, most of the legalities are the same on other, you know, code, code, you know, hosting providers. But, um, you know, if you see a license file at the top level of a repository, you, I think, can assume. And I don't. I suppose it's probably somewhere explicitly stated on GitHub that that license is, you know, covers the, all the things that are in there. Um, when a license is at a different level, I wonder, you know, a folder down, right? Um, so, like Matt was saying, right? If you have a content folder and a code folder, for instance, just to make it simple. Um, And the, you know, I don't know, like, what would you do? You have two license files in each of those folders. Do you put a license file at the top that just says, hey, check out these? These subfolders for the licenses. I don't know. I'm trying to think of, think through how to do that because I like, I like that idea. And now I'm just trying to think through how to execute it.

Tom: 46:34

I mean, mechanically speaking, I have created separate repos for content and code before and I, for other reasons, but, um, I see no reason why that wouldn't be a feasible solution just to make very clear everything in this repo is this license, everything in this repo is this other license to allay confusion. I mean, I, I, I'm glad Bekah brought up the Creative Commons License. It's, uh, it's one that I have used for some of the content that I have written, and also, I know that, um, other, uh, forms of artistic expression have enjoyed the use of the Creative Commons License because I think it, it gives the ability to To do things like essentially remix or reimagine what was what was created, um, you know with attribution and and allows creators to feel comfortable putting their their content out there now, obviously We get into the realm of whether or not people, um, do the right thing with licenses or not. And, and I know we've talked a lot about AI, and there is some question as to whether or not, um, different, uh, methods of ingesting content and information are adhering to the use of those licenses. But maybe next season needs to be all about AI instead of open source. That, that sounds like an entirely other, uh, one hour topic in and of itself.

Bekah: 48:06

Yeah, thanks so much. And I want to thank everybody for being here today to talk about licenses and open source. Uh, I think that I know that I learned things and I'm sure that all of our listeners will learn a lot too. So thank you so much for being here.

Ray: 48:21

Thank you. Thank you.

Dan: 48:24

Yeah, thanks everybody. I also learned a lot, so I appreciate it. All right. We'll see you guys next time.

Bekah: 48:30

Bye.

Dan: 48:34

Thank you so much for listening to this episode of the Virtual Coffee Podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel, and edited by Ashley Mulder. If you have questions or comments, you can hit us up on Twitter @VirtualCoffeeIO or email us at podcast@virtualcoffee.io. You can find the show notes, sign up for the newsletter, buy some VC merch, and check out all of our other resources on our website, virtualcoffee.io. If you're interested in sponsoring Virtual Coffee, you can find out more information on our website at virtualcoffee.io/sponsorship. Please subscribe to our podcast and be sure to leave us a review. Thanks for listening and we'll see you next week.

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.