Today, software is deployed in a variety of ways: on-premises, SaaS, mobile apps, embedded systems, or a combination of all of them. Open source license compliance rules that make sense for one deployment model may not for another.

While there are certainly some universal rules of license compliance (like avoiding conflicts with GPL), it’s often wise to customize your policies to fit specific deployment methods.

In this blog post, I’ll discuss factors that should guide compliance policies for various types of deployments, including SaaS, mobile apps, and embedded systems. I’ll also cover strategies for implementing these policies in a way that works for engineering teams.

This article is based on a webinar I recently conducted with FOSSA: Customizing Your Open Source Compliance Policy. If you’re interested in this topic, I’d point you in the direction of the on-demand recording for a more in-depth discussion.

Editor’s Note: 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, Open Source for Business, and is a General Partner at OSS Capital.

Watch On-Demand: Customizing Your Open Source Compliance Policy, Feature Heather Meeker

Compliance Policies for SaaS

When I talk about creating compliance rules for SaaS, I’m referring to software that’s primarily deployed over the internet (and allows for that sort of web-based interaction) — but isn’t actually delivered to users.

Compliance rules for SaaS can be different from rules for software that is distributed, like an on-premises deployment. That’s because most open source license conditions, like notice requirements, attribution requirements, and source code sharing requirements, are triggered by distribution.

An on-premises product is distributed. That means you’re going to have to adhere to all of the conditions of the open source licenses. In SaaS deployments, most of the software never triggers any of those requirements.

However, even in a SaaS offering, there can be some code that gets executed client-side — usually HTML, CSS, and Javascript. Also, many SaaS systems have mobile apps associated with them, and those are always distributed.

But when we create policies for SaaS, we are mostly thinking about the kind of deployment where the software never gets pushed out to the user. For that reason — and because most open source licenses don’t really have any requirements for SaaS — you can afford to be a little bit more liberal with your policies than with distributed products.

With GPL, LGPL, and similar copyleft licenses like the Mozilla Public License and Eclipse Public License, even if you change the licensed code and use it just for SaaS on the back end, you will not have to do any source code sharing. And then for GPL and LGPL, you won’t have to worry about how the code is integrated, which is one of the qualities that controls how you comply with those licenses. GPL and LGPL are the only commonly used licenses that have stringent rules about how you can integrate their code with proprietary code.

However, there is a nuance to creating SaaS policies that everyone should understand: Most SaaS products end up getting distributed one way or another. I’ve had many clients in my legal practice say to me, “We will never distribute this software, it’s only SaaS.” And, then, the next day they come to me and say that they have a big deal in the offing, with just one hiccup: the customer needs its own on-premises instance. That can be for any number of reasons, including regulatory and security reasons, or even foreign trade consideration that requires local copies.

So, you can set a more liberal policy for SaaS because most licenses have conditions based on distribution. But be careful about painting yourself into a corner. I don’t recommend that you create SaaS policies that are too liberal because you want to future-proof what you're doing. If your SaaS rules are too liberal, you can incur a lot of engineering costs if you suddenly do need to do distribution. For example, if you combine GPL and proprietary code in the same program, you would need to separate them before you distribute. These engineering changes can be costly. Therefore, I recommend that even SaaS compliance policies avoid mixing GPL or LGPL code with proprietary code in a way that would make a compliant distribution impossible.

Compliance Policies for Mobile Apps

Mobile apps are always distributed. They’re in the highest-risk category of products because, by definition, they have to be distributed to the mobile device.

Also, in proprietary mobile apps, it can be hard to comply with licenses like GPL and LGPL. In particular, LGPL is a license for a library. And, if you use the library in a proprietary application, that’s fine. But it’s much easier to comply with LGPL if you use the library as a dynamically linked library.

In some mobile app platforms, it’s impossible or impractical to use dynamic linking for libraries. So, in mobile apps, you should avoid using GPL- or LGPL-licensed software unless you intend to make your entire mobile app available under GPL. In general, it's probably best to avoid all copyleft code in mobile apps. It’s extra work to make source code offers when distributing via a store like the Apple Store or Google Play. Some people even think that the terms of service for these stores conflict with all copyleft licenses. While I don’t agree with that, it’s usually not difficult to build mobile apps without copyleft code.

Compliance Policies for Embedded Systems

Embedded software is one of the most difficult areas for compliance. First of all, it’s almost always distributed, because it’s on a physical device that you distribute to users. The physical device almost always changes title, and that means distribution.

In fact, if you look at the compliance actions that take place, they are almost always in consumer electronics or other embedded software, and almost always for copyleft licenses. For copyleft licenses, what triggers the requirement to share source code is when somebody who buys the product asks for the source code. You then have the obligation to provide it.

Plus, it’s easy for enforcers to get access to consumer goods to test and see if you’re doing compliance correctly. Also, there tends to be more focus on consumer electronics because those products affect so many people; the rate of enforcement in B2B is lower.

When you put these together, if you’re selling consumer electronics or embedded systems, those are the situations where you’ll have the most complicated compliance challenges.

One of the factors that makes compliance difficult in embedded systems is that almost all open source licenses have what I would call license notice requirements, meaning you have to deliver a copy of the license. But some electronics literally don’t have a screen where you can display it.

The old joke on this topic is the theoretical Linux Toaster: On the Linux Toaster, where are you going to put your notices? You could put them on a CD, but that would be the most expensive and difficult approach. You could put them on a website, but that isn’t actually what most of the licenses allow as a method for notice.

So, when you back that into a policy for embedded software, you have to be very careful to get your notices rights and be ready for your compliance to be easily vetted by the public.

Getting Engineering Buy-In on Implementing Policies

There are some areas of law where having a policy in itself is useful. That doesn’t usually work with open source. The policy is only as good as the people actually following it.

I recommend in-house legal teams consider these four strategies to get engineering on board with compliance policies.

Make It Livable

If you’re in a legal role trying to get engineers to follow an open source compliance policy, your main priority should be making the policy workable for them. Engineers are dealing with incredible pressure to get products out the door, and if a policy becomes a bottleneck, they will ignore it because they’re going to focus on their main job requirement. Your job is to make compliance as clear and easy as possible for them.

Use a Compliance Tool

In an organization of any significant size, you absolutely need automated tools to do compliance. A very, very small company might be able to do compliance on a spreadsheet, but companies outgrow that quickly. That manual approach will also likely create errors and cause bottlenecks, or it will end up in the organization ignoring compliance.

The compliance tools you use have to allow the engineers to interact in the way they’re accustomed to interacting. The bad news here for some lawyers is that engineers don’t like to send emails. Lawyers love to send emails — they love the auditability of email threads. But when developers interact, they usually want to interact in structured ways that allow them to identify issues and communicate in ways that move toward resolving that issue. The tools you use for open source compliance have to allow engineers to interact in that way, and you as a lawyer also need to learn to interact that way.

For instance, one of the big tools to manage development is Jira. It’s a ticketing system, and you need to learn to use it. And you probably need to learn GitHub, too. Lawyers can be resistant to such tools because it’s a different paradigm, but, in a lot of ways, it’s a more sensible paradigm. So instead of resisting this, take the opportunity to learn a new skill.

Don’t Be Too Restrictive

The policy can’t be too restrictive. Most of my clients take a middle-of-the-road risk approach to compliance risk, and I think that’s about right. But I've had some clients who have taken very conservative approaches, and it breaks down because their engineers don’t follow the policies. But policies are living documents, and you can always adjust if you need to. Just make sure you have not soured your company on the idea of compliance by putting too many roadblocks in their way.

Make It Clear

An open source compliance policy should cover about 90-95% of use cases for open source software. At a maximum, 5-10% of usage should be escalated to someone other than engineering, like legal.

The decision to use software is primarily an engineering decision, not primarily a legal decision. Our role as lawyers is to make sure engineers aren’t getting into trouble, but mostly the decision to use software is based on technical and business needs. So, it makes sense to allow engineering to make almost all the decisions. Lawyers need to give them guidance and the tools to make decisions. If you let them know they’ll never have to talk to legal if they follow the compliance policies, that will help. But if they want an exception to the policy, they will need to seek approval.

Finally, when an engineer presents you with a question, you should respond to them quickly, because they are under extreme time pressure to get things done, just like lawyers.

Additional Resources: OSS License Compliance

As mentioned at the beginning of this blog post, I recently conducted a webinar with FOSSA: “Customizing Your Open Source Compliance Policy.” You can view the on-demand recording at this link.

Additionally, here are a few more license compliance-related resources that may be of interest:

Editor’s Note: FOSSA’s open source license compliance management product includes out-of-box policy templates that were developed with input from experts like Heather. Please reach out to our team if you’d like more details on using FOSSA and our policy feature.

And, if you found this blog useful and are interested in open source license compliance, we encourage you to check out Heather’s website and FOSSDA. FOSSDA (Free and Open Source Stories Digital Archive) is a new project Heather launched to document the history of open source software.