OSS Capital

Interview with Heather Meeker: Founding Partner, OSS Capital
Ben Rometsch
January 19, 2021
Ben Rometsch - Flagsmith
Ben Rometch
Host Interview
Host Interview

The thing you don’t want to do is call something open source when it’s not…

Heather Meeker
Founding Partner
Heather Meeker
Founding Partner

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Overview

In this episode I spoke with Heather Meeker who is a founding partner at OSS Capital. Starting her career as a programmer and switching to law, Heather has been focused on software licensing for the last 25 years. She's worked with some of the most famous open source software companies and projects in the world and has an amazingly balanced view of the space and the role that licensing can/should and does play within the ecosystem. We were able to cover the history of open source, interpretations of different licenses and examples of projects/companies that are getting it right.

As we got deeper into the discussion, I asked Heather if there was a point where the licensing changed to enable the successful open source projects we see today. She had this to say which was an amazing point of view coming from someone with so much experience in the space:

The reason it was successful is that it was a great product. I don’t mean to be flippant but without that, the license wouldn’t have worked. It’s the license that serves the business and not vice versa.

If you are thinking about which license to use for your open source project or what makes the most sense for your business, you should definitely listen to this talk.



Episode Transcript

Heather, thank you for your time. It's great to have you on. For the readers, do you want to give us a brief overview of who you are and why I'm talking to you? 

Thank you for having me on. I'm a lawyer and a venture capitalist, and in both of those roles I focus heavily on open source software. A bit of color about that: I've been a lawyer in Silicon Valley for about 25 years. Before that, I was once a computer programmer, and it was long ago that we called ourselves “computer programmers.” Everything I did professionally in computing is outdated now, but I've had fun learning from my clients over the years. As a lawyer, I am essentially a technology transactions lawyer, meaning that I do licensing and commercial deals. My specialty has always been software licensing, because software is interesting to me. A few years, I got involved in a venture capital fund, Open Source Software Capital, which focuses entirely on early-stage commercial open source companies. One of the reasons I did that was that my law practice had become more and more about advising people on business strategy around open source. That is inextricably bound up with licensing strategy. It was a more natural move than you might expect for a lawyer-type like me. Now those things are dovetailing nicely. I spent a lot of time talking to small companies about how to set their business and licensing strategy. 


I remember the first time I heard the phrase or came into contact with open source software was a CD on the front of a magazine in 1995. It was a copy of Slack for Linux. I remember me and my friends were spending days and days trying to get it up and running. It meant that we could stop programming because we had Sonos terminal at the time at the university. It meant that we could start coding at home instead of having to go and see the university. When did you first hear the phrase? 

It probably was around that time, 1995, 1996. At that time, I had been a lawyer for a brief amount of time and my clients were asking me about the software. They asked, “Can we use this software under this license?” They were referring to various licenses, a lot of them permissive, like MIT licenses and so forth, but also licenses like GPL and LGPL, which nobody in the legal community understood at the time. At that time, I was boots on the ground in terms of clients saying, “Can we do this? Can we use this?” It was free and they wanted to use it. The general attitude of lawyers at that time was like when your mother says, “Don't put that in your mouth, you don't know where it's been.” 

They considered open source dangerous, but the reason they considered it dangerous was it didn't come from a commercial vendor. It could have infringement issues and so forth. Most of the lawyers at that time were saying, “No, you can't use that.” I realized quickly, because I was the one that they were asking every day, that was the wrong answer. It had to be, “Yes, but,” instead of “No.” I thought, I need to figure out what is that condition, “Yes, but if you do this, you can use it.” There was nobody in the law trying to figure that out from that perspective at that time. I looked around and there wasn't any information about it. There's a lot of philosophy about open source. There wasn't much that was for somebody who was making this decision on a practical level day to day on behalf of a private enterprise. 

I started developing those things myself and trying to learn more and more about it. The rule of being in an organization is that if you know 10% more than the person in the next room, you're the expert. People kept asking me about this stuff and I kept trying to answer the best I could, with little to go on. More people asked me questions and I learned more, and gave more answers, and it kept snowballing. I thought, “This will go away. It will be the flavor of the month.” It never went away. After the internet bust in around 2000, 2001, it took off. That's when I decided that this was going to be my area. This is what I'm going to do with my legal career. 


You didn't have that light bulb moment when you came into contact with it in ‘95 or ‘96 that like, “This is going to change the world.” I didn’t. I thought it was great that someone was giving this operating system away for free, but I remember I discovered the web around the same time. It's within a minute of using Mosaic that you knew the world was never going to be the same. 

I don't think many people realized it. The reason was that at that time, open source was considered a hobbyist thing. People could not have foreseen how widely accepted it would become, much less becoming the entire backbone of the internet, which everybody perceived immediately was going to change the world. It was the internet bust that caused it to skyrocket, because people were casting around desperately to save money. All of these big companies that otherwise never would have considered Linux seriously, all of a sudden they started saying, “We're going to throw our hats in the ring here.” That in itself was the amazing thing to me. It got people to collaborate in a way that they had never collaborated before. That was the sea change. Businesses started saying, “We can collaborate with our worst competitors on this infrastructure stuff.” That was what changed things for me. 


I was working around that time. I was an engineer. I remember hearing how much people or my clients were paying 6, 7 digits for software that you wouldn't dream of paying anything for nowadays. What were the risks for someone who's not legally minded? What was the thing that was frightening people at that time? What's the worst case? 

First, beyond any real risk, people just didn't understand the licenses. People don't like things they don't understand. Not understanding things is risk. Let's lay that aside, because that's irrational. The real risk that they were worried about from a legal point of view was that the software would be infringing, and that can happen one of two ways. One way is that somebody took something they didn't have the right to use and put it in the software. In legal terms, that would be either copyright infringement or trade secret misappropriation, depending on how they did it and how much they copied and so forth. The other risk is quite different, and that's patent infringement. That can happen even if you don't improperly take something else. 

For years and years, people had been buying software from commercial vendors who gave them some comfort in the form of an indemnity. If the software was infringing, that vendor would take care of that problem for them. With open source, you usually don't have that. There are some vendors now who offer indemnities, but at the time there was no such thing at all. People were concerned that if they used software and it was infringing, then they would be flapping out in the wind and there would be no vendor to help them. 

“They asked, “Can we use this software under this license?” They were referring to various licenses, a lot of them permissive like MIT licenses and so forth, but also licenses GPL and LGPL which nobody in the legal community understood at the time. ”


It's where the buck stops if there's a problem. Talk a bit about the history of that. Which side was driving that? Was it the commercial side of the internet driving the changing in feelings and the licensing around that, or was it the other way around?

What changed it was that people decided they needed something inexpensive enough that they were willing to bear the risk. At the same time, commercial vendors, like famously Microsoft, although they had changed their tune by now, they were creating what people call FUD -- Fear, Uncertainty, and Doubt -- about these issues because they were competing with Linux. If I can make an aside, it’s interesting that at the time, Windows was so dominant that the only thing that could have competed with it was not a commercial product. All of a sudden, they had this competition and they were trying to throw shade on it. They caused people to change the way they've thought about it. Interestingly, a lot of lawyers still have these ideas in their mind that come from that time and the FUD that Microsoft created. We even see provisions in documents that came from that time. They were effective in causing people to be concerned about it because they were competing. 


That was several years ago. I remember that time well. 

Lawyers are slow to change. What they do is they go, “I know about this risk. I have to identify it. That's my job.” It's difficult to get them to stop when the risk is no longer significant anymore. 


One of the things I've noticed when I've spoken to lawyers about things like this, maybe not experts but people who work in licensing or technology, is that they still seem to perceive the concepts as a single thing. They seem a bit naive to the fact that there are different types of open source licenses. Why do you think the profession is in certain circumstances like that? Have you experienced that? 

It's improved somewhat over time. If you take the clock back several years ago, most lawyers, even technology lawyers, didn't understand the categories like permissive and copyleft or even what copyleft meant. All they knew is that it was bad and they were scared of it. Most tech lawyers now understand that permissive licensing is not generally going to be that risky. They still mostly don't understand how copyleft works. To be fair, copyleft is complicated from a legal point of view, and in some cases from a compliance point of view as well. People are scared about what they don't understand, and people have only so much time to invest in understanding something. What that says is copyleft is a complicated idea that there's a big understanding tax for it. The question is, “Is it worth it?” That's a legitimate debate because to explain a new licensing idea to somebody is hard and it makes them reluctant to adopt things and recommend things. The profession has gotten much better about permissive software, but I don't think there are many people who are willing to say, “Tell me about whether you're developing this dynamically loaded kernel module,” and advise you on how you need to license it. Those people are still rare. 


How much of these licenses have been tested in court? 

Open source licenses, I don't think there's any meaningful doubt that they are enforceable because we've had a few cases about it. Ironically the biggest case ever in the US was about the Artistic License, which is not a terribly common license. It's more or less a permissive license. There's a general rule in law that the answers you get in a common law system like ours are never the answers you want, and then you have to extrapolate back. I don't think anybody doubts that open source licensing is enforceable. When you get to questions like, “What does this particular phrase mean?” or some important things like, “What's a derivative work?” There's nothing. It's all industry practice. When you are working as lawyer in this area, it's as important to know the industry practice as well the case law, because the case law is not going to give you answers. Maybe someday we'll get some more case law on questions like interpretation of GPL. I wouldn't be surprised if we don't, because the industry practice now is so strong that that's what most people rely on. 


Why do you think few cases have gone to court? 

Nobody has an interest in bringing them. The people who are doing enforcement or the authors who released their code under GPL, if they were to bring a case asking a court to make a judgment about something like, “Can you dynamically link something to GPL code? Does it have to be GPL?” That's the $64,000 question. They might lose that issue. The reason they might lose it is that it's a complicated question and judges and juries are notoriously unwilling to understand technical concepts. It's highly risky to bring that lawsuit. People are legitimately concerned that if the result were wrong, that would be bad for the industry, because it would disrupt all the industry practice that has taken place. 

On the defendant's side, nobody wants to argue a GPL interpretation claim. The expectation, which is accurate, is that such a claim would be long, expensive and unpredictable. Neither side has the incentive to push the issue. That's why we haven't had a case. It's not like it couldn't happen, it's just that you would normally expect people to have pushed the issue, except there are these incentives going on either side. The people who will tell you what GPL means, like the Free Software Foundation, has a long FAQ about GPL, they've already won because industry practice follows what they do -- setting aside people who are noncompliant. 


Do you think that the longer the status quo is maintained, the less likely they ever see a court? 

That answer is a real-politick answer legally, because there's a general thought process that judges don't want to disrupt entire industries based on an abstract legal principle. It's not that they never do it, but they are not immune to the idea of what will happen as a result of their actions. In a case like GPL interpretation, there are going to be many people filing amicus briefs, people not involved in the litigation saying, “You should rule this way.” Judges would be likely to know what those effects would be. That’s right, although it's not right because of some legal doctrine. It's right because this is the way the world works. 


In terms of how things have changed now, when we started up being open source, it was an obvious thing, there wasn't even a decision already. I'm curious to know, for commercial open source, was there a specific point, or new license, or change to a license that helped usher in this era of companies like GitLab, Mongo, or people like that? 

It has happened gradually over time. I have been seeing more and more of that over the last several years. There was a watershed moment in 2018, 2019, where you saw a lot of exits of open source companies. Before that time, it was gradual. There were some pioneers, and I would mention first MySQL because they pioneered, although I understand they didn't exactly invent, the dual licensing model, where they say, “Here's our software. It uses GPL plus an exception. If you want to buy a further exception, which you can use this in proprietary software, we will sell you that exception.” They were doing that early on. Interestingly, that model was popular in database, and Oracle bought a lot of the companies that were already doing that. 

That was the first wave of people saying, “How do we make a business out of this?” I'm laying aside doing support and professional development, which has always existed as a business model for open source, but that's not a scalable model. That's a people model. That dual licensing model was a way to leverage the intellectual property in the software and try to make a business out of it. That was an original thing. You mentioned Mongo. Mongo was also a dual licensing model. Mongo is interesting because of how successful they were with it. They were originally under Affero GPL. They were the killer application for that license. 


Explain that a bit more. What was it about those partnerships or associates that made that business successful? 

The reason it was successful is that it was a great product. I don't mean to be flippant but without that, the license wouldn't have worked. It's the license that serves the business and not vice versa. They chose this license that was new and was the strongest copyleft license that was in common use and approved by the Open Source Initiative at the time. They were one of the first adopters of it in order to serve their dual licensing model, because the stronger the copyleft license, the more people are likely to want to buy an exception to it. They went out the door with that. Probably they were one of the earliest adopters of that license, ironically, because the license wasn't written to serve business interests. Their product was great and people wanted to use it. I recall that after Affero GPL was published, which was 2007, maybe early 2008, I would get requests from client engineers to use software under Affero GPL. The only thing that anyone would use under it was MongoDB. They were willing to take the risks associated with the license to use the product because it was an innovative product. 


They were leveraging that product strength.

That was the original dual licensing model approach. That morphed into the open core approach, which is a variation on it, but an important variation where instead of saying, “Here's some software under Affero GPL, and if you want to use it under other circumstances, you can buy an exception from us.” That's dual licensing. You had the companies that said, “Some of our software are under an open source license,” and that would be a permissive license, “We're going to sell you add-ons around it.” That model has completely eclipsed dual licensing now and is the most popular model. There are lots of companies doing that and lots of them are successful. That’s been the arc of progress of the commercial open source software business model over time. It went from dual licensing to open core. You've got companies like GitHub, WordPress, and other companies that are selling online services to people and not really selling software to people. That's a different approach to commercial open source. There are other approaches too, but those are probably the biggest and the easiest ones to understand. 


Why do you think it took such a long time for open core to come about? Was there a legal breakthrough around that, or was it more people trying different ideas? 

It was gradual. What people did first is the dual licensing model. They said, “If you buy our exception, we'll give you an 'enterprise' version that has these extra features.” That effectively was open core, but nobody was calling it that. For a while, this is early 2000s to 2010, you had a lot of companies having two versions of their product, the community version and the enterprise version. That was open core but people called it dual licensing at the time. It continued to evolve. It was clearer over time what people were doing and that was a trend. They were doing the same thing but there weren't clear names for it. 


How have things changed coming up to towards the present day? There's been a lot of talk, and a lot of the founders and engineers that I've spoken to have mentioned this with regards to large cloud providers like Amazon trying to get protections around. Elastic is the primary example of Amazon taking something and then making way more money due to their scale of operation. Where are we now in that regard? 

I have worked on many of those companies. Many of the companies you're talking about are my clients. They have this so-called strip-mining concern. When you read about it in the press, it's always a little company versus Amazon. It’s a little more complicated than that. Some of the open source companies are not what we would call little companies and it's not only Amazon. It’s just that this was the perception. There is no open source license that will effectively prohibit a cloud provider from offering your open source software and charging money for it. They were intended to allow that. What happened was that the big cloud providers have customers who are getting all sorts of software from them. 

For those customers, it’s easy to tick the box and add one more thing, then the cloud providers had a lot of resources to deploy the software. The licenses didn't require the cloud providers to share their changes. Over time, the customers were getting diverted away from the software developers, and the perception at least is that Amazon was not sharing changes back. I would predict that that's going to change, not because of a legal requirement but because the cloud providers are going to be more willing to share over time. We'll see what happens there. There was a big opportunity cost for these smaller companies that they were leaving a lot on the table. It was a competitive concern. 

A lot of the companies that you're talking about, they had private investors who said, “Why are we giving this away? Why are we letting these big companies trade on our software for free?” That's a hard question to answer because open source is about letting people trade on your software for free. Some of them essentially decided, “We need to change the mix. We're going to take more of our software out of the open source bucket and put it in another bucket,” which does not allow the cloud providers to do that. Most of the companies you're thinking of, maybe not all of them, they're open core companies to begin with. When they started making these changes, they were still open core companies. They had just changed the mix of how they provide their software. 

The open source parts are still free to use, but they have started to be a little more conservative about giving away some of the upsell elements. What people read about and often don't understand is that what they do is they take some of the open source software and they put it under a license that is a new category, which people are calling source-available. It means that you get access to the source code, but it's not free to use for everything you want to use it for. In particular, many of these companies started using licenses that essentially when you boil it down say, “You can't use this to provide a competing SaaS.” They have put more and more of their software into that source-available category. Most of them still maintain open source elements, but they now have more and more source-available elements. 

“The reason it was successful is that it was a great product. I don't mean to be flippant but without that, the license wouldn't have worked. It's the license that serves the business and not vice versa.”


Do you see that as a trend of people moving away from the religious definition of that phrase? One of the things that I found interesting is if an oil company starts putting out press releases, there's a phrase for that, the greenwashing. I’m not going to disparage any software companies, but it's interesting to me that there are people going, “It’s not properly open source.” It feels like several years ago, there was quite a pure understanding of it. I understand that people are doing that because they need to build a business and they need to build business models around it. Do you feel like at some point, there will be a line that gets crossed by people where it’s like, “You can't be on GitHub,” because of what is this thing? 

I don't think so. If I start a company and I say, “Here's my open source and this is my core. I have some other stuff that I sell,” am I an open source developer or not? I don't think there's any answer to that question unless you take the view that open source has to be non-commercial. There are some people who take that view. A lot of great open source software has been developed by private companies, for-profit companies, unless you want to get rid of Kubernetes, it is open source stuff. There's a philosophical question about, “Should open source be a thing you do in business, or should it be for the good of the world?” I'm a lawyer so I won't answer that question. This is not even my job. No one wants lawyers to answer moral questions! 


Do you think we need a new phrase, a second phrase? 

I don't. First of all, it's hard to find new phrases. I speak from experience. I developed a project to write some of these source-available licenses, and trying to find a phrase for the category was difficult so I just picked a brand. People have to be careful about how they talk about it. The one thing I always tell all my clients and portfolio companies is if something is not under an open source license, you should not be calling it open source. The reason people do that is understandable. Most developers now don't have any religion about open source. They just want to know, “Do I get access to the source code? Do I get to do what I want with it?” The important thing that's happened over the last several years is that people expect transparency. They didn't expect it before that time. When people say open source, if they're being casual about it, what they mean is the source is available to use, but that's not what it means. 

Open source has a definition, and it has to have no license restrictions. Companies who are developing in this area need to be careful about the phrases they're using. The thing you don't want to do is call something open source when it's not, and then have what you're doing as a company be about a philosophical debate and not about what you're doing as a company. My hope for my clients and companies I work with is not to have their product releases get derailed by that philosophical debate. They have already lost that debate. They're private companies. They have to be careful and it is confusing because people use that term in a casual way, in a way that's much broader than its formal definition. I encourage people never to use that phrase to describe anything that's not under a classic open source license, like an OSI approved license. 


In as few words as possible, what would define that line? 

The most interesting example is the free software definition. It has something called freedom zero, and I'm going to paraphrase it because I don't remember exactly, but it’s the freedom to use the software for any purpose. Those source-available licenses all violate freedom zero so they're not open source. 


My point is that I feel like the phrase is becoming more and more abused and people think of it as one amorphous cloud of a license. One of the things that I never realized, having been an engineer for twenty years, was how many different licenses there are, how elegantly different they are in solving different problems rather than it being this one thing. It feels like every year, they seem to move a bit more in that direction. 

I'll suggest to you one thing that you probably knew as an engineer, but maybe weren't thinking about in a formal way. If software is open source, you do not have to do any tracking whatsoever of how you use it. There are no compliance obligations for use. I’m maybe overstating it a little, but the point is that you don't have to engage in all the nonsense that you have to do for proprietary software like counting users and servers, and what country you're using it in. That is an incredibly important freedom. Whereas when you have any use, condition, obligation or restriction, you have to keep track of how you're using the software in your organization. Organizations and people have a hard time doing that. They have an easier time telling when they're distributing software because there's one action they can point to. Doing the things you need to do when you distribute, like doing notices and source code offers, that's a lot of work, but it's easy to identify the trigger point. The problem with something that's not truly open source is it has this trigger point. It's a hard trigger point to track within an organization. The general thought is once you ingest software into an organization, most people can't keep track of how they are using it.


We've had clients in my old job who Oracle came and did an audit, £3.5 million didn't turn up, which was an interesting board meeting. You mentioned that you felt like the large cloud providers are going to be less concerned around these issues with regards to them running these services with different branding. Why do you think that? 

It's possible that we are in an arc of progress similar to what happened in the early 2000s. In the early 2000s, people were looking at Linux and saying, “This is interesting. It looks promising, but it has this license we don't understand. We're afraid of having to share our changes with other people.” They went on and they found, “If we share our changes with other people, that works well as long as this is not the core of our business. As long as it's the infrastructure that supports our business and not the core of our business.” Companies learned during that time that collaboration was okay, at least under certain circumstances. That applied to most of them. It notably didn't apply to Microsoft because operating systems were their business. It applied to a lot of the other companies who are using operating systems and benefited from a collaboratively built operating system infrastructure. 

The reason that they got comfortable with that was GPL required them to share changes. That was a legal hammer. At this point, people collaborate on those things not because they're compelled to legally, but because they figured out that it's a good idea. The cloud providers are not required to share any improvements to stuff they use in the cloud. They might figure out, like other companies figured out during that time, that it's best for them to do that. It's possible that we'll find a way through this that does not involve the legal compulsion that GPL was, but involves a social change around the way business is done. 


I never thought about it like that. I guess Kubernetes would be a great example of that. 

You've got a lot of companies that contribute a phenomenal amount to open source development and they don't have to, but they perceive it as a good idea. That's a good example because that's not Google's business. They’re doing search and other things, but infrastructure is helpful to them and they have completely internalized that ethic. Everybody coming out of engineering school has internalized that ethic. It's not unreasonable to think that people will collaborate when they don't have to. If you have some software that's under an open source license and somebody like Amazon can use it for free and not share their changes, they could do that, or they could collaborate with people. You're even starting to see all of the cloud providers start to collaborate. The issue will solve itself over time, but we'll have to see whether that's right or not. 


Putting aside desktop software or mobile applications, do you think there’s any room for commercial databases anymore? 

It's got to be tough to be in the commercial database space these days. Open source has been successful in that area. I'd put databases in the category now that operating systems were several years ago. Infrastructure software is such a good use case for open source. I don't see proprietary software being successful in the long run for infrastructure. At the application level, we will always have proprietary software, but the markets are smaller. There's less benefit from collaboration across industries, but for infrastructure, open source is the way to go. What we're seeing happening is that infrastructure is creeping up the stack. It used to be operating systems and virtualization. Now database is the next big category. It will keep creeping up and up. You'll see coding tools. We already saw the browser and Java. It will keep going, but there will always be some top level where people are innovating and they need to capture the revenue for that innovation or they won't be able to fund it. 


If I was starting a SaaS business now and I was wanting to open source my product, where would you suggest looking in terms of trying to find out what the best license for your project is? 

It is rare these days that I recommend that a client use any copyleft license. The reason is that when you're developing a business, what you mostly want from your open source is wide and quick adoption. The permissive licenses are much more effective for that. When you put software out under copyleft licenses, people will have rules about whether they can use the software in their organization, and it will at least slow down adoption. I would normally say to a client, “Pick what you want to share and use a completely permissive license because that'll get you the most balance out of it,” but then you have to start thinking about what you're going to sell. 

At the beginning stages of a company, maybe you're not selling anything. Maybe you're building your brand and establishing a community. Eventually, you're going to have to have something that you aren't giving away because you're going to have to sell something. In early stages, permissive licenses are effective tools. The only ones I would ever choose were BSD, MIT, Apache. The reason for that is not necessarily because they're the best written, because they're not. It's because everybody is familiar with them, and familiarity is good because it drives adoption. 


Do you think there's room left for new revolutions, new models and ideas? Do you think we've figured it all out? 

I would love to see a lot more stuff that's public domain. In places other than the US, it's unclear whether you can have public domain software. In the US, it's clear. At least people operate as if it's a clear rule. If you think about this, suppose I write some software and it's a great sort algorithm or something core, and I want people to use it. Do I need them to put a copy of a license on it in order to redistribute it? That's what you're asking people to do with BSD, MIT, Apache. The answer a lot of times is no, you want people to use it. I suggest to some of my clients and some of our companies, if you don't care about what people are using this stuff for, dedicate it to the public domain because that makes it easier for people. 

Do you need your little copyright notice license on it? Maybe it's important to you but if it's not, don't burden its use forever with that requirement. I would love to see more of that, and it would be great if some of the law could be adjusted so that it's clear that people can give up their copyrights. Now it's a quagmire. You have a product with thousands of third-party components in it. That's a situation nobody ever anticipated who was writing copyright law. You have to put a notice on it for every little piece. That's an enormous information problem, which ends up funding copyright notice tooling providers. 


That's one of the things I do. If I go on holiday and hire a car and I'm waiting for my family to do something, I'll always try and find the copyright notices in the central console. Sometimes they're there, sometimes you can't find them. It’s hilarious. You then find this 3,000-page long list of random libraries that half of them you'd never heard of. 

You’ve got to wonder, “Did that help the author?” Maybe it's important but if it's not, why burden the world with that? It is funny to see them in user manuals and all these crazy places. The reason for that is that most of these licenses were written pre-internet, and you can't do something sensible like throw them on a website. They have to be in the product somewhere. People spend a lot of time spinning their wheels about doing notices in ways that are useless to the recipient of the product, and a cost for the product manufacturer. 


That's been fascinating, Heather. Thank you so much for your time. I appreciate it. It's interesting how you finished because I hadn’t thought of public domain for many years. I'm curious now to know why it's unusual. 

In Europe in particular, copyright is considered a human right so people can't give it up. That's my understanding. I'm no expert. In US, it's more considered an economic right. It's an example of how the different legal systems can have different results, maybe unintentionally. 


Thank you again for your time. For those of you that are reading, it’s OSS.Capital if you're interested in speaking to Heather further.

Thank you. It was delightful to talk to you.

Heather Meeker

Heather Meeker is OSS Capital’s founding core portfolio partner for portfolio-wide commercial OSS licensing and legal best practices, special projects and key strategic initiatives. As an internationally-known expert in software licensing, for over 20 years Heather has been a thought leader and trusted advisor on the use of open source software in business, and has helped scores of emerging companies structure licensing and business models.

As a lawyer in private practice, Heather has been recognized with many awards for her work in law and technology, and advised clients from startups to global enterprises on software licenses and software copyright. She is a prolific writer and speaker on software licensing, and is the author of Open Source for Business, a go-to handbook for open source licensing in commerce.

Before her law career, Heather was a programmer of business applications and systems and a professional musician.

Available for talk, coaching and workshops on:


Learn more about CI/CD, AB Testing and all that great stuff

We'll keep you up to date with the latest Flagsmith news.
Must be a valid email
Illustration Letter