Heather Meeker is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, and is a Partner in the Mergers and Acquisitions group at O'Melveny & Myers LLP and a Founding Portfolio Partner at OSS Capital.

FOSSA recently had the opportunity to host Heather for a webinar on open source license notices and how automation can help organizations consistently and efficiently manage policies. Here are some of the highlights of that conversation.

Watch On-Demand: Demystifying License Notices with Automation

License Notices and Automation

How can automation help meet notice creation challenges?

Heather Meeker: You should always use automation if you can, even if you’re at a small company. License notices are usually an information problem, not a legal problem. Once you establish processes for compliance and for actually delivering the notices, then you’ve effectively removed most of your burden of dependence on lawyers. It’s just execution at that point.

This information problem expands quickly as your business grows. Even if you can handle your notices today with your 20 open source components, one day soon you will not be able to handle it manually anymore, for any number of reasons:

  • Multiple SKUs
  • Regular updates
  • Products getting bigger
  • More third-party components
  • Acquisition of new teams and software

You need automation! If you’re not automating now, you're just in an interim stage before you use automation. It’s just a question of what tool you're going to pick.

If you want to see how much work it is to create a notice file without automation, take a look at my video: “How to Create an Open Source License Notice (in Excruciating Detail).” I hope that convinces you that it is a process you probably do not want to use for long.

What are the most important elements of a strong automation tool?

Meeker: Does the tool do the level of checking you need? There is a wide variety of tools out there. Some look for license notices and copyright notices but don’t find cut-and-paste errors or really check against ground truth at all.

On the other hand, a more sophisticated tool like FOSSA will actually not only automate the audit as part of your existing engineering and legal workflows, but also help you figure out if someone has made a cut-and-paste mistake somewhere.

The second thing is usability. I can’t tell you how many times my clients have gone out, gotten a tool, and found it so difficult that they stopped using it. That’s a waste of money and time. When you go down that route, what you’re communicating to your engineers is that you don’t care about their time or their priorities. Keep in mind that, for engineers, compliance is kind of like paperwork. Having a bad experience with compliance tools can actually lead to even less compliance in your organization.

Ask yourself (and your stakeholders!): Does this tool do what I need it to do, and is it user-friendly enough to get the people I rely on to also do what I need them to do?

Distribution

Does hosting software on AWS constitute a distribution and trigger for open source licenses? What about moving from one server to another within a data center?

Meeker: In a way, there’s no answer to this question. There’s no certain legal answer because there’s just not enough law on this topic. To make a long story short, the copyright act doesn’t actually define distribution. I don’t want to make anybody lose sleep at night, but it’s true. And most open source licenses have obligations that kick in on distribution. It is a right in the copyright act, it’s just not defined — you have to piece together legislative history to define it.

With that caveat in mind — that it’s impossible to definitively say the legal truth — the answer is no. It’s usually not a distribution. We come to that conclusion in a number of steps. It has to do with the fact that you probably control that virtual space, and the determination is more about who controls that virtual space than who owns the computer that it’s running on. I’m not saying there aren’t other arguments against that position, but that’s basically how it’s shaken out in the industry. It cannot be the case that every use of AWS is a distribution by the user, because the world doesn’t work that way.

What about the concept of redistribution? This is often one that’s very confusing, given the variety of how code and software move around the world. For example, does it apply to SaaS?

Meeker: SaaS, in the ways most people use it, is generally not considered distribution, and I’ll explain why. SaaS is when you have software that you’re running on your own computer, and you’re allowing somebody remotely to interact with it. That person does not have a copy of the software.

Now, that user does interact with some software, and we call that client-side software. For example, let’s say you’re filling in your phone number on a web form, and you get a notice that the number you’ve input is invalid. What’s happening there is that software is actually executing within your machine’s browser to verify the data entry. That client-side software is all distributed, but it’s a very small portion of the software that is being deployed in SaaS. The back-end components are not distributed.

With that said, I always tell clients that it’s a bad idea to rely on the fact that you’re not distributing today because someday you will be. Consider this: One day, your sales rep comes in and says they have this multi-million-dollar deal in the works, but you’ll need to allow the customer to run their own instance of your SaaS on their system because they’re in a highly regulated industry. That’s distribution. You don’t want to be the lawyer who has to say, “Gee, I’m really sorry we can’t do this multi-million-dollar deal because we have completely abdicated open source compliance. We thought it was OK because we weren’t distributing it.”

I have rarely had a client who didn’t get to that distribution point in their business, so you shouldn’t decide it doesn’t matter. But, until you reach that point, you don’t have to do all the notice delivery for what’s on the back end of SaaS. You will have to do notices for anything on the client side.

Bill of Materials

Do you have recommendations on how to get buy-in from your organization on the importance of tracking your bill of materials internally?

Meeker: What I always say is license compliance is only part of the job. If you have license compliance issues, you have other issues, too. And the top one is security. The best way to get buy-in throughout your organization is to communicate that tracking your bill of materials is part of a larger effort to make your products excellent.

For context, lawyers like me do things the same way programmers do. We don’t write anything from scratch. We pull an indemnity provision from here, a warranty about privacy from there, and so forth, as we put together our agreements. Just imagine what would happen if you never checked to see which provisions you were using. And, say, there’s a new privacy law like we have in California — all your agreements would be broken.

It’s the same kind of process for tracking your software bill of materials. It’s absolutely essential to know what you’re using; that should be relatively easy to recognize. What’s harder is to convince the engineering team that you are respecting their time and their skills by making the process livable for them.

Also, your company may have an open source compliance policy or process in addition to the tools that you’re using. I always tell clients that a good policy should handle 95% of the cases, and it should mean that legal does not have to get involved in most of the decisions. Because, in truth, most of those decisions are engineering decisions. Legal shouldn’t be a bottleneck. Once you make that happen within your organization, you’ll find a lot less tension and resistance to compliance processes.

Open Source Licenses

A few open source licenses out there have oddball clauses that are vague but, perhaps, harmless. Examples are JSON, which says do good not evil, and WTFPL, which allows users to do whatever they’d like. What is your practical take on all these oddball terms and weird licenses?

Meeker: I regularly tell clients both JSON and WTFPL are OK to use. For the WTF license, we may not know exactly what the terms mean, but we can confidently say that whoever chooses that license doesn’t give a hoot about compliance. So it can’t be high-risk. That’s just a practical response.

The JSON license citing “good not evil” is also interesting. I have told clients for a long time that, if they can’t prove that they’re not evil, they have bigger problems than software licensing. That’s a little bit of a flippant answer, but, again, there’s been no enforcement of that license, so it ends up being not a practical problem.

There is a movement that aims to be a lot more specific about the definition of good and evil: the ethical licensing movement. I would not recommend users adopt software under those licenses without a lot of careful thought, because they are potentially opening themselves up to an extremely embarrassing public compliance lawsuit. But WTFPL and JSON have historically been on everyone’s green list for a long time.

Watch On-Demand: Demystifying License Notices with Automation

Note: We on the FOSSA Editorial Team are not lawyers, so if you are seeking legal advice, we suggest you speak directly to a legal team that specializes in open source licensing.