Heather Meeker, an O’Melveny & Myers partner focusing on legal issues in open source

SAN FRANCISCO — Even for those versed in IP law, the world of open source software licenses can be difficult to parse. But as open source forms more and more of the global tech infrastructure, understanding this area is key.

In a conversation on Law.com’s Unprecedented podcast, Silicon Valley attorney and former programmer Heather Meeker of O’Melveny & Myers explains recent trends in open source license enforcement. She also talks about why dealing with sexual harassment in the open source community is legally challenging, and security issues in open source.

Read an excerpted Q&A below, listen to the full interview here, and subscribe to the podcast on your iOS or Android device. The following transcript has been edited for clarity and length.

Ben Hancock: For those who don’t know a lot about this area, can you explain generally the concept of an open source license and the circumstances that led to the recent legal enforcement statements?

Heather Meeker: The important thing to understand about open source licenses and enforcement is that open source licenses are conditional copyright licenses. So if I’m an author and I own the copyright—the simplest set of facts—and I release that software under an open source license and you use that software in violation of the license, what I can do primarily is bring a copyright claim against you. I can also bring a contract claim; there’s been some recent case law about that. But usually the big-ticket claim is a copyright claim.

There are three or four buckets that are important in open source enforcement. I’d say first and foremost there are the community enforcers. There are a few organizations that have done a lot of work in that area, most notably the Software Freedom Conservancy and Software Freedom Law Center, gpl-violations.org. These are organizations that usually work on behalf of individual authors who come to them for help doing enforcement. And they have a very clearly defined set of goals in doing enforcement; what they want is for people to comply.

On the other end of the spectrum there are what I would call strategic enforcers, which would be companies that own copyrights in software, think you’re misusing them, and maybe you’re competitors or [they] have a reason to disrupt your business or just want money from you. Those kinds of enforcers are actually much rarer, but they do exist.

Then, in the middle, there are individual enforcers, some of whom have been characterized as “trolls” or “copyright profiteers.” And that’s probably the biggest development in enforcement over the past few years. Interestingly, Germany is the jurisdiction of choice for bringing quick copyright claims because it’s got some plaintiff-favorable characteristics. Some people have called Germany “the Eastern District of Texas for soft IP claims.”

You’ve written about Patrick McHardy and his litigation in Germany, and I think the perception was that for some of these enforcement statements that have come out, all that litigation he was bringing in Germany was the genesis of this. Is that right?

Yes. So, you know, open source has gone through several different cycles of fear. Originally, companies were very concerned about using any open source software because they feared there would be big legal problems. Over time though, since say about the year 2000, there’s been a massive adoption of open source. And part of the reason for that is that some of those fears started to get allayed. There was a famous case—SCO [Group] v. IBM—which caused everybody to be very afraid about IP claims relating to Linux. And then as that case … pretty much blew over people started feeling a lot more comfortable about legal claims about open source.

What’s happened with McHardy’s efforts is that now people are again becoming concerned about being exposed to legal claims and having to defend lawsuits. And so in response, the community enforcers have wanted to reassure people that if they have proper compliance in place, they will not be enforced against. And if they happen to make a mistake—which happens a lot … you forget to provide your source code or you provide the wrong version, or some such thing—instead of that being a foot-foul that will cause someone to sue you for a bunch of damages, [the enforcers] will work with you to get you compliant.

Let’s look at a completely different, nontechnological issue: sexual harassment. Obviously 2017 was marked by a cascade of revelations about abuses, in all sectors. What kind of distinct issues does sexual harassment present in the open source context?

I think this is an issue that’s like the next shoe to drop in open source. People who are managing open source projects now need to be sensitized about these issues. They needed to before, but it is inevitable that there are going to be some significant and public problems. There have been problems already but they’ve mostly been under the radar.

When you have any community of people working together, unfortunately there is the possibility of sexual harassment, predation, all kinds of misbehavior. And if you are running a community then you have perhaps a moral responsibility—and perhaps a legal responsibility—to control that and prevent it from happening. Now, most of the harassment claims that we’ve seen so far in the news, many of them have been related to workplaces. And so the natural path of legal liability and legal control is for the employer to set policies and make sure to enforce those policies.

An open source project often doesn’t have an entity controlling it. It’s often got a very consensus-driven leadership, it’s got community members from all over the place. And so the question is, if you’re running an open source project now, what responsibility do you have for community behavior and how do you make sure that people behave properly in the community? So many open source projects are now issuing community behavior guidelines, which have to do with sexual harassment, and all sorts of other issues as well. But it’s going to be interesting to see how these end up playing out. Because the projects may have less legal control over the actions of their participants than, say, an employer would have.

Switching gears again, let’s talk about security and open source. There were reports after the Equifax hack that a piece of open source software by Apache was perhaps the window through which attackers gained access—I don’t think there was ever a clear answer. Is anything changing in this space? Are there new concerns?

First of all, I should say that if there’s a security problem caused by proprietary software, it’s not news. And in the past three to four years there have been I would say about three different incidents that were blamed on open source—rightly or wrongly. Actually, I thought Apache’s response to the Equifax claims was a pretty cogent one. But there is a tendency to try and lay famous security issues at the door of open source software.

There is an ongoing difference of opinion in the community—well, in the world, I guess. Some people think open source is more secure because you can look at it, and with enough eyeballs, all bugs are shallow and that sort of thing. And then there’s the “security by obscurity” approach, which I guess you can tell how I feel about it by me using that term. It’s the proprietary software side saying, “Well, laying the source code open just invites hackers.” I think honestly that’s a little bit of a naive view, because hackers can do a lot with binaries, too.

But I think what’s happened is just that everything’s running on open source now. And so if there are security problems … one, the open source stuff makes news, two, more and more of the software stack is open source now. It is unbelievable how much open source is running the world these days.