Open source and licensing

I’m Nadia Eghbal…

And I’m Mikeal Rogers.

On today’s show, Mikeal and I talk with Heather Meeker, intellectual property lawyer at O’Melveny & Myers. Heather spent over 20 years on legal matters related to open source, and has published several books, including Open Source For Business: A Practical Guide To Software Licensing.

Our focus on today’s episode with Heather is open source licensing. We talked about why open source licenses are historically significant, how much developers really need to know, and how much developers think they know about them.

We also talk about mixing commercial and open source licenses, and how lawyers keep up with an ever-changing landscape.

Heather, you started your career as a paralegal at a record label in Hollywood. How did you go from that to taking the leap into becoming a practicing lawyer?

Well, I had a very zigzag course to my career - that’s probably the nice way of putting it. There was a thing going around on Facebook a while ago about listing your first seven jobs, and when I did that I think I got up to the paralegal job, so…

Oh, wow! Tell us about your first six.

I’ve done a lot of different things. I was out of college for 12 years before I went to law school, and during that time I was a computer programmer, a professional musician, and eventually ended up working as a paralegal. I got into that because I was working as a musician and I desperately needed some money, so I got a temp job at a record company. They put me in the legal department, and then there was a permanent position, and they put me in that, and then one of the paralegals left and they put me in that job. Then it was a bad economic time and they were actually letting lawyers go, so they gave me a lot of their work, and I decided “Well, I could actually be a lawyer and make a lot more money doing the same work”, so I went to law school.

It was a long and zigzag course, but during that time I was interested in what we call content music, and also had worked as a programmer, so by the time I got to law school and this thing that they called - at least at that time - convergence of the content in technology industries was going on, so it was a very natural fit for me. After that, I kind of never looked back.

Were you working on anything around intellectual property or the things you’re doing now, while you were taking on all this lawyer work from previously departed lawyers?

Actually, I was working on intellectual property but it wasn’t software-related, it was music-related. So yes, I learned a lot about copyright when I was doing that, and then after I went to law school, I started applying it to technology.

And where was open source when you started specializing a little bit more deeply?

[03:51] Well, I first heard about it in around 1996. By that time, it had been going on for a while, but I would say it had not hit the business consciousness of the world. People describe it as a hobbyist movement before that point - I don’t know if that’s exactly accurate, but it wasn’t something that the technology business was embracing. That really started happening at least from where I was sitting in about 2000, so it took a few years between the time I first started paying attention to it and the time it burgeoned like crazy.

I had started to take a look at free software, reading the GPL, trying to figure out what was going on there in around 1996, and I just found it incredibly interesting. I kind of pursued it as a matter of personal interest. My clients were asking about it, but it was mostly just something I found intellectually interesting. I tried to learn all about it I could, and then it turned out that in about 2000, particularly when the internet bust started to happen, people really started focusing on open source as a way to save money. After that time, it just kept snowballing and snowballing until, as they say today, it’s eaten the world.

You mentioned that you had a programming background before - is that one of the reasons why you took such an interest in it even before it was being demanded by your clients?

Yeah, I suppose so. I mean, I have to say that my tech background is ancient, really. It’s several generations back. It’s like, every two years it’s another generation back. But I was always interested in software, because I found software interesting from the work I’d done in it, and just kind of as a matter of personal interest. Something that was like an extremely complex software licensing paradigm was just about exactly my cup of tea.

Were there any particular legal issues right around the time that you started diving in, that caught your attention or really rooted your experience?

Well, I think everyone who gets fascinated by open source or free software probably starts by reading the general public license, and being interested in what it has to say. It’s a very complex document, so it requires a lot of attention to try to figure out what you think it means. Also, there was this sort of ironic thing going on where the free software advocates were trying to limit the scope of copyright law through a copyright license almost. I don’t know if that’s exactly accurate, but they were trying to get people to give away some of their copyright rights with a copyright license. It’s your classic being an agent provocateur from the inside, and I think anybody who gets interested in open source starts by marveling at the beautiful structure of how that was done, and getting interested in the implications that it has for software licensing.

That’s really interesting. That’s one of the earliest open source licenses, the GPL. How have things changed, and how has the open source landscape changed from then until now, and how have you kept up with all those shifts?

[07:49] Open source licenses have gotten a lot more standardized over time, or at least people have fully embraced the benefits of having them be standardized. Today, there are still people writing open source licenses, but this notion of license proliferation is considered a definite negative in the community. If you roll back the time 20 years ago, you had the GPL and you had a few others, but people still thought it was a good idea to write new ones. Now, there’s a real notion that it’s not really a good idea to write new ones. That is, I think,q mostly sensible because they tend to be kind of difficult documents to interpret, and you have to, for instance, import a lot of knowledge about how they are used, and so forth.

Most of them are shorter documents that don’t have a lot of detail, so every time you write a new one, when you start on day one you don’t have any history with the license to use to interpret it, and that’s difficult.

I should step back… For instance, GPL version two became widely accepted by industry, but a big part of that was that industry got comfortable with the community norms for how to comply with it. That is sort of outside the four corners of the license. Normally, when you’re interpreting legal documents, you basically just look at the four corners of the document. You look a little bit outside, but one of the primary roles of interpreting licenses is you have to look at what the objective meaning of the license is. With GPL version two you had this long history of use that was very helpful and made people much more comfortable about what it meant, understanding that it’s a very complex document.

That’s the long way of saying that today everybody understands the value of standardization in open source licensing, meaning standardization of the license terms in a way that was kind of a side benefit of open source. So if somebody comes to you and says, “I’m using this software in a tender Apache2 or a tender GPL2”, I know immediately what that means, whereas in proprietary licensing, you have to actually read every single license.

Over time, a lot of what has changed is that people have converged on a half a dozen licenses or so, almost to the exclusion of all else. There are still new licenses being written, but they tend to be at the margins.

I hadn’t really thought about that before… I guess proprietary licenses - everyone’s drafting their own version, so it’s almost like a meta benefit of open source itself as what it’s done for licensing.

It is, and when you hear people complain about license proliferation, I think it’s very interesting. Because in proprietary licensing, there is nothing but license proliferation, [laughter] so it’s a little hard for lawyers to hear complaints about license proliferation… It’s like, “Yes, and…?” Because every copyright owner has the right to set whatever license terms…

It’s actually something that we talk about at GitHub where I’m at now…

Yeah, it’s hard for lawyers to get used to, but I would kind of turn it around and say that the standardization is actually a benefit, it’s kind of an extra added bonus of open source licensing, and that’s a great thing.

[11:55] Then how much do we pair it down to… Like, do we really only need one type of license for each situation? Something we suggest is like Apache 2.0, GPL and MIT, but then we hear complaints from BSD saying “Why aren’t we included in that list?”

Yeah, I mean… If anyone can tell me the difference between BSD and MIT, I’d really like to hear it. There’s really no difference between the two. They’re obviously different documents, but substantively they’re so close to identical that nobody really treats them any differently. Then I think what you would have to add to that list are the so-called “weak copyleft, or file copyleft” licenses like LGPL, or Mozilla Eclipse and that kind of category of licenses. You do need those, because you need copyleft licenses that apply to libraries or files, but you can really break it down to permissive Apache and BSD/MIT, and then GPL, LGPL, and I’ll vote for Mozilla because, of course, I like Mozilla.

Biased. [laughter] It sounds like licensing has changed a lot of times since you last went to law school, right? So for a space like open source, where everything is changing so quickly, where do you go to keep yourself fresh and learn about what’s going on, and how do you continue to self-educate?

Well, I always tell people that being an open source lawyer is kind of like being a tax lawyer, in the sense that you spend an incredible amount of your time keeping up on what the rules are and what’s going on. I think compared to other legal practices, you have to spend more time doing that. There are certain practices that are like that.

For me, maybe 15 years ago I would read everything I could find about open source licensing; now it would be impossible, because there’s so much out there. I’ve gotten more selective in what I am reading, just because I don’t have the time to read everything anymore. There are a couple of discussion groups I’m on that are very useful, and at this point I kind of know the people I like to follow. When they write interesting stuff, I will always take the time to read it and maybe even communicate with them about it.

I have maybe half a dozen people I’m looking for the stuff that they’ve written. Then the IFOSSLR, the law review that’s done by the people who started the Legal Network and Free Software Foundation Europe - that’s a great law review. If you are disposed to read something more like a law review article, that’s a really good place to start.

Honestly, there’s been a fair amount written about open source licensing in traditional law reviews, and I usually don’t find those terribly useful. I’m more interested in stuff that’s very pinpointed, on a pinpoint issue, or something that is practice-related. And of course, anything that gets published by Free Software Foundation, Software Freedom Conservancy that’s like a position on an issue, of course I will be reading that, so that I would understand what their positions are.

[15:50] Are there any things that you just decided to opt out of staying on top of, because they just got to be too much? Like, “You know what, I’m not gonna keep following the Oracle/Google lawsuit…” Is there anything like that?

Yeah, I had to follow that, but…

Yeah, note for our listeners - you’re involved in that lawsuit, right?

Yeah… So for example, there’s a discussion group to discuss new open source licenses, and I pay some attention to that. There’s no way I could possibly read all of it, so I’m trying to figure out what am I gonna be reading and what am I not. I don’t know, there’s just a lot of stuff written out there that I can’t follow. The things that take the most time to weed through are the discussion groups; it’s just the nature of discussion groups. Maybe you don’t wanna read every single comment that anybody’s making, particularly if they’re arguing with somebody else about something, but you do want to keep your finger on the pulse of what attitudes people have and what they’re talking about.

Do you think formal law education in law schools knows how to teach open source?

I don’t think they know how to teach law… [laughter]

That’s the bigger problem!

I mean, that’s the real problem. I could go on all day about that. Law schools teach people to be judges, they don’t teach people to be lawyers. Or at least, I would say that’s probably true of the top echelon of law schools. Ironically, it’s probably true that the lower tier of law school you go to, the more you actually learn about being a lawyer, because they teach you more practical stuff.

There are certainly classes on open source in a lot of law schools these days; there will be a seminar or something to that effect, but all law school classes tend to be pretty theoretical. That is the problem with legal education, or an issue, I guess. There are probably people who would disagree with me and say it’s not the job of law schools to teach people how to practice; that’s the job of law firms. And I guess that’s maybe a fair comment… But you’re really not gonna learn much that’s actually useful in counseling clients in law school.

It’s a great idea to learn the basics of open source, and one of the reasons I say that is that open source licensing tends to be… I’ve called it “Bizarro-World IP”, and that’s because it tends to be very opposite from everything you learn about IP, and rightfully so. As I said, it’s kind of a mechanism to get people to give up IP rights… Being exposed to it is really useful, because it takes a while to absorb the ideas, and you don’t wanna be absorbing those ideas the first time you have an actual issue to figure out; you wanna be comfortable with the ideas already.

So it’s great to get exposed to it, but realistically people who are studying law really should not be expecting to learn very much about what’s actually useful in counseling clients. That’s just the nature of a law school.

And you published a book, Open Source For Business, last year. Why did you decide to publish that book?

You know, I am the kind of person who works out what I’m thinking by writing. If I come upon an idea that I wanna focus on, the way I work through it in my mind is by writing something about it. What I did over the course of the years as I was learning about free software and counseling clients, I would come up with ideas or issues that were interesting, so I would write some short piece about that.

[20:13] Then, in about 2006-2007, I started feeling like it would be useful to collect all that stuff into a book. So I took all the stuff I had written, I added a few more things and put it together. Of course, the stitching together of it took hundreds of hours, [laughs] but that is the nature of writing books… Even though I had basically written the whole thing already.

So I did that book, it came out in 2008, and then it really needed an update and my publisher was not inclined to do an update, because unsurprisingly, my sales were less than that of Harry Potter books. [laughter]

Niche topic, I’m sure.

Yeah, it was the kind of topic where there are maybe a few thousand people who really wanna read a book about it, but they REALLY want the book… [laughter] So I think the book was very successful given the audience, but it’s never gonna be broadly successful.

Then I decided, “Okay, now I’m gonna publish on my own because that means I can update whenever I like”, not that I have been as diligent about that as I would have liked to be… So I just basically rewrote the book from scratch, because it had been 7-8 years by then; it was really time to do a total refresh of it. Some issues that seemed important in 2007 really didn’t seem that important in 2014, so I added some stuff and took some stuff away, and did a huge update.

One of the things I did on the book which was a lot of fun is there’s a fairly detailed technology tutorial in it, because a lot of lawyers who are trying to grasp open source issues struggle with some of the technology concepts, and in open source licensing some of those actually matter. In lots of IP licensing it doesn’t really matter that much, but I wanted to give people the opportunity to learn the technical concepts too, so I put a lot of effort into that. The technical tutorial in the book is greatly expanded from the previous one.

That’s awesome!

That sounds great! We’re gonna take a short break, and when we come back we’re gonna get into what developers need to know about licenses, versus what they probably think that they know. We’ll be back in a minute.

And we’re back. Alright… Heather, one of my favorite jokes that I heard recently was “I’m not a lawyer, but I play one on Reddit.” [laughter] Developers are somewhat notorious for playing lawyer. What are some of the biggest misconceptions out there that developers have, and what are the important ones that people tend to get wrong?

First I’ll say that there are a lot of developers who are extremely sophisticated about open source licensing, and then there are a lot of them who basically have no concept about it at all. The problem is distinguishing between the two. If you’re a person in business and you’re not an engineer, the first question is “Should I be listening to what my engineers are saying or not?” There is a certain decision point there.

The ones who don’t know that much about it, the things they get wrong are – I think the classic misconception is that it’s okay to dynamically link to GPL code. This is a meme that has been traveling around for at least 20 years and it’s basically wrong.

What does that mean?

If you’ll forgive a small foray into the technology, when you build a program it’s not just one big, amorphous blob, at least not usually. You build it in pieces and you kind of stitch it together. That process, at least in a language like C or C++. It’s called linking - you take all the little blobs and you stitch them together, and that’s called linking. There are at least two ways to do that: one is dynamic and the other is static.

The static way is where you tell the program that’s building your program, “Just put it all together and smash it into one binary.” That’s static linking. Once it’s put together it doesn’t change, in the sense that all the blobs are sticking together in exactly the same way, and that fact doesn’t change.

Dynamic linking is something a little more sophisticated where one of your blobs, say, might do something that you don’t wanna be doing all the time, like printing a file. So you tell the builder that is building your program, “Build the program, but leave the printer blob on the side. When you need it, go get it, and execute it, and then flush it out of memory.” It’s a way of conserving memory at an expense of operating speed. Now, you can tell I’m an old programmer because I don’t even know if programmers think as much about that anymore, but we used to be always trading speed against memory usage. It’s one of the reasons why you have dynamic linking. You don’t wanna be stuffing your memory full of code that you’re never using, or rarely using. It’s much more efficient to say, “Okay, when you need that thing, go and get it, execute it and get rid of it.” That’s dynamic linking.

To make a long story short, GPL is for whole programs, and if you put the program together as one big blob or a bunch of blobs, it doesn’t really matter from the point of view of GPL compliance, whereas a license like LGPL allows you to use a dynamically-linked library and bifurcate the licensing. [27:58] A proprietary program can use an LGPL library as a dynamically-linked library. I am greatly simplifying the rules there, but that’s a sort of basic compliance rule.

So that’s the difference… It’s a difference about how you engineer the build of the program, and LGPL in particular is directed towards libraries that are primarily used as dynamically-linked libraries.

And also in a lot of modern dynamic languages, everything is dynamically linked; nothing is statically linked.

That’s a really good point. The LGPL and the GPL - the way they’re written and the compliance rules that people talk about are really focused on a language like C, that has this notion of static and dynamic linking and building. The higher-level scripting languages… There’s almost not a concept like that. And you’re right, they’re much more like dynamic linking. The programmer in that case has less granular control about how the program executes. The value of the low-level languages like C is that you have a lot more control and you also have to tell the program a lot more about what you want it to do. The higher-level languages do a lot more without you telling them a lot of details, but you have a little bit less control. Those higher-level languages tend not to have even a concept of static linking.

If you’re a businessperson or a lawyer and you talk to an engineer and you say “You can dynamically link this library” and you get a blank look, the most common reason for that is that the person you’re talking to is developing in a language that doesn’t really have that kind of concept. That may very well be so. A programmer like me who is ancient - they will all understand the concept because the higher-level languages tend to be a little more recent, by which I mean in the last few decades. [laughter]

What are some things that you think some developers are quite sophisticated about legal issues? What do you think are some things they get right, or that they know a lot about?

Engineers who have been around open source for a while, particularly ones doing Linux kernel development often have a very sophisticated and nuanced sense about GPL compliance in the Linux kernel space. That, I think, is where most people find the most challenge in figuring out what GPL means. Again, when you stitch stuff together in a Linux kernel, which is essentially one big blob - I mean, it does have the ability to have dynamically-linked modules in it, but they call it a quasi-monolithic architecture, meaning that it’s basically one big binary blob.

The engineers who are working on that will have a very good sense about what GPL means in the context of kernel development and what you can or cannot do. Their knowledge is particularly useful when you get into these very detailed questions like “What if you have multiple processors? What if you have a small embedded system that can’t have dynamically-linked modules?” and so forth and so on.

[32:09] When you get down to these very detailed questions, it’s ultimately kind of the engineers who know the answers and not the lawyers. Many of the engineers who have been around a while know the compliance rules best, better than the lawyers do, because what they are telling you is what community practice is. And ultimately, particularly with GPL and particularly with the Linux kernel, that is what you’re trying to figure out - a little bit more than a pure legal question of what the license means and what you might argue in court.

So for developers that are not working on kernel-level work, and who aren’t working with the GPL - let’s say your average developer today who just wants to write something and put it up on GitHub and then slap an MIT license on it… How do you think that developers’ self-education is changing, going from that highly sophisticated developer who might have this very deep understanding of GPL issues, to today’s developer who might not really care at all, but still wanna open source their work?

Yeah, so the conventional wisdom is that the new kids on the block don’t care about licensing issues at all…

And is that okay?

That’s perfectly okay. I mean, as long as they’re not treading on other people’s rights, they can decide to share their code with anybody and let anybody do anything they want with it; that’s their prerogative as a copyright owner.

I would say a few things to developers who are thinking about this stuff. First, you have to have some license, because the default with no license is no rights. I actually spend a moderate amount of time in my practice contacting developers on GitHub or elsewhere and saying, “Could you please apply a license to this code? And if you would like people to be able to use it, use BSD, MIT, Apache, or even CC0 (Creative Commons Zero), which is a public domain dedication.” I would also say as a corollary to that, “If you really don’t care even about people giving you credit in the sense of delivering a license notice, dedicate it to the public domain.” I think people underestimate the amount of burden involved in license notices, even for licenses like MIT/BSD. So if you really just want to set your code free and let everybody do whatever they want, dedicate it to the public domain, because that’s actually what you want.

I would really summarize it as “Any license is better than no license.” If you really don’t care, don’t burden the world with any licensing requirements at all. I guess one final thing I would say is that you can always move from a more copyleft license to a less copyleft license. If you decide to release code and you put GPL on it, you can always change it to MIT later; that’s very easy to do. Going the opposite way - you can do it, but anybody can still use the code under the more permissive license, so it doesn’t work very well. If you’re uncertain, you typically use the more copyleft license first, and then change to a more permissive one later, if people ask you to do that.

[36:05] I’m a little bit curious - mostly for my own personal reasons - what is involved in migrating from one license to another? I know that you’re involved in the Mozilla public license version two, and that was a very large effort to migrate to. I think that there’s this conception that if licenses are “compatible”, then you can just move around them freely, but my understanding is that is actually not true, even though most people seem to believe that.

Well, there are two things going on at work there. One is the versioning of a particular license. Many of the copyleft licenses have this mechanism in them that, say, if you take the code under this license as it exists today, and the license steward (the person that wrote the license) issues another version, then any recipient can use the code under the version that exists today, or any later version. That is the default for most copyleft licenses.

For instance, when we were working on Mozilla, anybody who had code under 1.1, which was the most common version at that time, could then automatically use it under 2 once it was issued, assuming the code was issued under that default structure, which is this version or any later version. So in a way, you don’t have to do anything in order to version a license and have the code available under the new version. There are some exceptions to that, and of course the notable one is the Linux kernel, because that is under GPL 2 only, and not later versions. For that, you really can’t migrate to a new version. Then there’s a separate question about changing licenses in all other circumstances, and that is if you have a codebase with a specific license on it, can you then change the license? Sometimes you can, but sometimes you can’t.

For instance with the kernel, there are literally thousands of contributors, and the license basically can’t be changed because you would have to go to every contributor and get their authority to change it. One thing that people do in order to avoid that problem is use something called the contribution agreement, which gives rights to the project steward, who then can choose the outbound license. That is actually a relatively unpopular thing to do, particularly in community projects, but it’s done in most corporate projects today.

That means that if I’m running a project, you as a contributor just grant me the right to do whatever I want with the code, and then I decide the outbound license. Then, all I have to do is stick a new license notice on the code, and going forward everybody can use the code under the new license, but importantly, it doesn’t stop the rights under the old license for the old versions of the code. For that reason, people don’t usually change licenses unless they’re doing a pretty major update to the code, because it just doesn’t make a lot of sense to do that.

[39:40] I think we need to walk it back just a little bit, because a lot of times when I talk to newer developers they think that in open source a license essentially means that they’re no longer the owner, or that the author is no longer the owner, and they’re essentially just putting it out in the world. But there is this distinction that the author/authors of a work are the owner, and the public license is in agreement with the public. So what you’re saying is that if the authors agree to take on a new version of the license, or somebody wants to use a new version of the software under a newer version of that license - many licenses have that provision - or there might be a CLA in place where a steward can have the rights to shift the license if necessary.

Yeah, exactly. As to the question of ownership, one of the core principles of intellectual property is that intellectual property rights are the ability to exclude others from doing things. So if you are a copyright owner, you have the right to prevent other people from doing certain things with your copyrightable material - copy, distribute… The rights that are enumerated in the copyright act (at least in the US). So if you grant someone a license, what you’re saying is “You can do these things that I’ve specified in the license, and I will not be able to sue you for infringement for doing that”, but it in no way changes the ownership.

If you release code under something like BSD, which is a broad, permissive license with really only one condition, which is the license notice, you don’t have much of that exclusionary right left, but you still have some left. It is not getting rid of ownership at all, it’s just that you’ve granted a license to the world, so there’s not much commercial value left in your copyright ownership.

I’ve seen some of that tension, I think, culturally at least, where more and more companies are relying on open source software, and there’s this sort of expectation that like “It’s your code, you fix it”, and sometimes the project owner is like “Well, it’s not my code, it’s everyone’s code. Use it at your own peril.” I’m sure the legal side can help settle those kinds of debates, but there’s this increasing tension between what people functionally think open source does or what it says about ownership, and then what the law actually says.

Well, really my main reaction to that is a company that’s building a product - it’s fine to use open source stuff, but it’s not a licensing decision to figure out whether that code’s gonna be maintained or not, [laughter] and the open source author has no obligation to do that at all. Just because you have the right to use something doesn’t mean you should… [laughter] People still need to make responsible technical decisions. There have been and are everyday issues with people grabbing code and not really knowing who’s maintaining it, or whether it’s secure or whether it is reliable code.

Don’t get me wrong, the most commonly used open source code out there is great. A lot of it has got great maintenance, very robust and secure, but the fact that something’s open source doesn’t mean it has a community; it just means it could have a community, and when people are making engineering decisions about using components and products, they need to be making a technical decision, too.

[43:57] We’ve had some issues in the past, because there have been security problems with some open source software, which is really down to the fact that a whole bunch of people were using this software without contributing back any resources to maintain it.

Right… Which is their right. That’s one of the rights in there. But I think there is a bit of a misconception - copyleft people and permissive license people both really care about community, and you need to care about if there is a sustainable community there when you use the software; it’s just that the copyleft licenses try to embed some of that in the license. The permissive license people essentially just allow that to become another community or economic dynamic of the users and contributors to the software.

Yeah, fair enough.

That’s a good point to break at. When we come back, we’ll talk about the role of companies and commercial applications in open source.

And we’re back! One of the things we talk about on this show - well, kind of the main theme - is open source and sustainability, and in the topic of sustainability there have been all these sorts of experiments around trying to make the production of open source sustainable through licenses, and trying different kinds of experiments.

I know, Heather, you helped draft the Fair Source License. Recently, the founder of MySQL just came out with the Business Source License, which they’re using for MariaDB. There are also all these dual-license models; some of these go between open source and closed source, and have touched off a lot of debates… What do you think about all these different efforts to mix commercial licenses with open source? Does this remind you at all of the shareware tech movement from the ’80s? Is this different?

Well, I’d say that something is open source or it’s not open source. For instance, fair source is not open source, and nobody would have claimed that it was. The hybrid model - maybe you call it source available, although that’s a pretty awkward term. Fundamentally, what makes something proprietary rather than open source is any kind of license restriction. So something like fair source that says, “You can use it up to X number of users and then you have to pay us”, that is actually a user restriction of a sort. It’s a light one, it’s not like the user restriction that you would get in your basic commercial proprietary license which would say something more like “You can use this for a hundred users. Period. If you go over that, you’re a copyright infringer.” That’s more draconian and that’s the quintessential proprietary license model. But nevertheless, something like fair source is actually license limitation, and so it can’t be open source, because the open source definition - the most important thing about it is “no license restrictions.”

[48:00] Maybe this is obvious, but people who manage software in organizations spend an extraordinary amount of time managing license restrictions. You can go to entire conferences on how to figure out whether you’ve exceeded your thousand-user limit and so forth, and there’s also technology to monitor it and all this kind of thing. Well, open source liberates you from all of that. That is one reason why people love open source - you don’t have to manage license restrictions.

Now, if you’re an author and you wanna release your code, you can choose open source or you can choose something else. If you choose something else, it’s pretty much designer; you get to pick whatever you want. Example - fair source; pick a set of terms that you think are fair, and that will make sure that people can use the software, but that if they’re making a huge amount of productive use out of it, that you get some kind of financial benefit from it.

I’m a lawyer in private practice, so my job is to serve my client’s interest, and if they wanna pick a proprietary model, that’s their right to do it, and I will help them do it. That’s my job. My main goal in doing that is making sure that they’re calling it open source when it’s not, because that would actually be problematic.

Then there are other sort of hybrid models where it’s like, “Well, something is released under a proprietary license, but it transforms to open source after a certain amount of time.” Okay, that’s definitely a hybrid model, but it changes from one to the other very clearly. One thing I would point out is that you don’t necessarily need a license to do that. What you can do is release something in proprietary form and then later release it under an open source license. Now people have written things where that happens automatically after a certain amount of time.

If you take a larger view and say, okay, all you’re really doing there is releasing something under a proprietary license and then later releasing it under open source terms, that’s a time-honored tradition in the technology business, where companies will put a lot of development into code and they will give it sort of on a first-look basis to paying customers, and then they will release it open source to the world for free. I don’t think there’s anything nefarious about that; they’re trying to recoup some of their cost, or get some financial benefit for the development effort they’ve put into it. Of course, I don’t think there’s anything wrong about that, as long as they’re clear about what they’re doing.

There are infinite variations, and when you’re in the proprietary area, not open source, as I mentioned as we were discussing previously, by definition there are infinite variations, because there’s no standardization in proprietary licensing. I’m fine about all these models as long as people are clear about what they’re doing and don’t leave the whole world scratching their heads about what is going on.

[51:47] Right. So there’s this practice - and I won’t name any companies by name - by which a company will put out software under the AGPL; any contributions that come into it will come under a CLA, so that the company retains some rights to that. And essentially what they do is they allow everybody to use the software freely until they’re making a fair amount of money, and then they say “Hey, you know what? You’re actually using this AGPL-ed software in your infrastructure. With other proprietary software, you’re gonna need to buy a license from us.” I can see how the semantics of the license are different between that and fair source, and why one is technically open sourcing the other, but is there a real material difference between the two?

What you’re describing - I’m just saying this because obviously you understand it, but for the benefit of others listening - is kind of a classic dual license model, maybe with a twist of limited enforcement. A company will release something under a copyleft license, and today the most popular one is Affero GPL, because it’s the heaviest copyleft conditions of any standard one at this point. It used to be GPL, but now it’s Affero GPL.

Yeah, this is exactly what MySQL did, right? People would have to modify MySQL in their proprietary…

Yes, they pioneered this model; they used a slight variation of GPL too, but essentially what it means was if you wanted to distribute the software in a proprietary product, you had to go and buy a commercial license to the code. This has been around for quite a while. It enjoyed, I would say, a great deal of popularity in the late ’90s and early 2000s. It is not as popular as it used to be, but it remains a popular business model.

Then, I think also what you’re describing is that if the assumption is that most commercial enterprises couldn’t use the code without violating the open source license, the company would not go after them until they thought they were making enough money to make them interesting as a licensing target. And that, they have the perfect right to do.

I spend a lot of time trying to resolve issues like this in the context of transactions. When a company is being sold to another, lawyers like me spend a lot of time doing due diligence on licenses and so forth. This comes up a lot, so here’s the canonical situation that happens. A company has developed a product and they’ve used some of this dual license code and they’re not complying with the license, because they’re using it in a proprietary product, or whatever. It depends on whether it’s AGPL or GPL, whatever. And then when they go to sell the company, somebody audits their licenses and they say, “Oh, this is a problem. You’re gonna have to get a proprietary license.” That issue usually gets resolved when a company gets acquired. Sometimes before, but often not until they get acquired.

The thing is that those issues are not hugely difficult to resolve, and the reason is twofold. One, clearly there’s a proprietary alternative available. Two, you can usually buy the proprietary license at basically a list price. The list price doesn’t tend to be hugely expensive because there’s essentially a free alternative. So those issues, from a commercial point of view, are not hugely difficult to resolve in most cases. There are some license sources out there - whom I will not name - who really charge a lot of money for alternative commercial licenses, and then it can be a big problem. But in about 90% of cases, that’s not a problem.

[56:13] There is a certain aspect of this dual licensing that it’s kind of introducing a “license bug” into the world. So if you take a library that’s GPL and you put it out in the world, people can use it internally, but as soon as they distribute it, it’s a license bug, basically. If you’re gonna do that and create a license compliance issue that’s obvious for everyone in the world, you have the right to do that, but you really ought to be extremely straightforward about it. If I have clients who are looking at that kind of strategy, what I usually tell them is “You have to do an FAQ, you have to be extremely transparent about your licensing practices. Because otherwise you’re basically putting a bunch of copyright landmines out into the world, and that I don’t think is really a very useful way to do business.

There are some people who really look negatively on dual licensing; actually, I think it’s got a fair amount of acceptance in the free software community because the notion is “Well, you have to make your money somehow.” But for me, working out issues practically with clients every day, it’s really about transparency, and if you are clear about what you’re doing, then in a way all can be forgiven. Because you set the rules, people will abide by the rules. The worst thing you can do is hide the ball about what rules you expect them to follow.

You mentioned that it’s less popular today than before - why do you think that is?

You know, I think it was not a hugely profitable model, because as I say, the prices for software like that tend to not be very great. One of the things I’ve said already is one of the great things about open source is that it’s standardized. What that means is if I wanna use code under an open source license, I just use it. There are no transaction costs at all, meaning negotiating a license. The license is the license, and I take it or I don’t take it. But proprietary licensing is a very expensive way to do business, in the following sense: if you are a huge company, like Adobe or like Microsoft, you just say what your proprietary licensing terms are, and for the most part, your customers take them or leave them. If you’re a mid-sized or small software company, you have to negotiate every single customer agreement, and it’s a license agreement, so it’s a little complicated to negotiate, and you need IP lawyers to do that; it’s a very expensive licensing model, with high transactions costs to sale. So the people who are doing dual licensing, I’m reading between the lines, but I think what they usually found was that it was an expensive business model to implement, and they just weren’t getting the kind of returns that their investors wanted.

By the way, when I say the licensing model was popular, the way that happened was the venture capitalists started to warm up to it, and I think they viewed it pretty favorably for a while, but it fell out of favor probably because it just wasn’t all that viable from a commercial point of view.

[59:54] You had a nice line a little bit ago, “People need to make money somehow”, and that kind of tracks back to this general topic of sustainability that we’ve been talking about. GPL licenses have tried to inject some sustainability by requiring contributions to come back in and modifications to come back in, and things like fair source and the business source license are also trying to bring in that monetary component as well. How do you see licensing in the future of sustainability in open source, and being able to bring sustainability in open source?

I think that we’re really at the point where what is working these days for sustainability are these big community projects. I mean, Linux is a poster child case. Many companies involved, many individuals involved, sufficient funding for the project, mostly from the corporate interest that are taking advantage of it. That’s a very sustainable model. The model of a company running an open source project on its own I think is pretty hard to sustain. Unless the company is making money doing something else, it’s not gonna be sustainable in the long run.

The traditional wisdom on this is that if you’re gonna run an open source project on your own, as a business, you have to be selling razor blades, meaning that you’re selling something you’re making money on - traditionally, that’s the razor blades, and you’re giving the razor away, which is the open source. So if you’re selling hardware, or you’re selling services, or online services and you have open source software that helps implement one of those things, and you release it and get some community interest in it, that might work. But a pure software model doesn’t really work if you’re a business trying to do open source. It’s just not sustainable.
It is also sustainable to get many people in the industry to participate and cooperate in a big open source project, and have it be funded by the members - that’s probably the more popular model now, to have these community organizations like OpenStack and Cloud Foundry and Linux Foundation, where they’re running big projects with a lot of contribution by the members. That’s a sustainable model too, but the notion of a company running an open source project on its own and trying to make money - that’s just not a sustainable model, I think.

Yeah, that’s interesting. When I think about that in the kind of startup case, it’s like, you know, startups are releasing libraries and framework all the time, and contributing to them, and all of those underlie how they’re building their product, but at the end of the day they’re making money on the product, and a lot of the community in open source benefits of making the software underneath better flow into their ability to make money on that end product, at the end of the day.

That’s exactly right. They have to reserve something on which they’re going to leverage their assets to make money and it’s quite possible to do that, but they’re never releasing whatever is their core value for their company.

[01:03:43.05] Now, there is a model which is like a pure services model. I kind of put Red Hat into that category, and some other companies that have come and gone… So you can make money doing maintenance and support and custom development and so forth around an open source project, but the – I mean, Red Hat aside, because it’s a fantastically successful company and I would never say anything to the effect otherwise… That is a hard model to sustain because service business - the traditional wisdom is they’re not very scalable. You have to have a lot of resources to get skilled people to do the work, and it’s expensive to do. I think that’s why there’s basically one Red Hat.

A lot of the companies that tried to make money doing Linux development services, they kind of came and went. They may have been successful in the short run, but I think in the long run it just wasn’t considered the kind of business that would be funded by outsiders. It might be perfectly viable as a personal business, but it’s not really gonna get funding these days.

That’s a good way to wrap things down. Before we close out, I just wanna see if there’s anything else that you think people should know around emerging or interesting legal issues that we haven’t yet touched on today.

For me, things that are interesting include… If you read in the media about open source – it’s pretty amusing to read in the media sometimes about open source, because people come up with a new open source thing every month. Things like “open source yoga”, you know… [laughter] I can’t remember the stuff that I’ve seen because it’s so bizarre… The important thing about open source is that there is a source code, right? And if there’s not, maybe it doesn’t make that much sense.

There are really interesting ideas in open data, open hardware, the intersection of open source software licensing with standards licensing, and so-called open standards. These models are very nascent. People have been trying to figure out how they work, but they’re very challenging to even structure, much less implement. Open Street Maps is a huge project that lots of people are interested in, and that’s basically an open database project with a very complicated and interesting license associated with it.

I think that a lot of what’s interesting for me – I like the newest ideas of course, and those models have not sorted themselves out yet, so there will be lots of interesting things happening in the next decade or two about open hardware, open standards, open data, and I think that’s where the frontier of some of this stuff is.

An exciting future to look forward to!

Yeah.

Thanks for talking to us, Heather. We really enjoyed this conversation.

It’s been great.

Thanks, this was a lot of fun. Thanks very much!