Practical Open Source Corporate Policies

What is the safest advice an intellectual property attorney can give clients concerned about potential litigation? “Do absolutely nothing.”

The truth is that making or selling any products might get you sued for patent infringement. Advertising might get you sued for trademark infringement. And don’t connect your computers to the Internet, because employees might download copyrighted materials improperly.

By doing absolutely nothing, the attorney can make sure the client never gets sued. Of course, the client would not remain in business for long. In business, unlike on Seinfeld (a show about nothing), doing nothing is not always the best advice.

Good legal counsel should take into account the risks that the business has to endure to provide its products and services. What are the client’s needs, demands and constraints? This is especially true when it comes to an organization’s policies on the use of free or open-source software.

Downstream Constraints

Let us assume you already have an open-source policy. It covers when and how incoming free or open-source software can be used and what can be incorporated in outgoing products, services and support. Let us also assume that legal counsel has reviewed and approved the policy.

Does the policy take into account your business model, corporate culture and the personalities of your programmers? If not, even the strictest policy might not be practical, and not following it might be worse than having no policy at all.

Programmers and businesspeople often have divergent views when it comes to the ownership of intellectual property. Complying with strict corporate policies might rub some programmers the wrong way. They might see it as an unnecessary exercise, like reinventing the wheel.

Smart companies will consider the organization’s culture and position in the industry, as well as the style of its lead technical staff, allowing them to develop a policy toward the in-licensing of software that is a perfect fit for the organization.

Legal liability around the use of open source is a complex issue, where interpretations and rules are constantly shifting. That’s why some legal advisors recommend not using open-source software at all. Others recommend that organizations limit the use of software to that which has no downstream constraints.

A “downstream constraint” is a licensing term that limits what the licensee can do with the software. In other words, any constraints that the programmer puts on the licensee also limits what the licensee can offer to its customers.

Policy and Business Model

If the programmer licenses software under the GPL, the licensee has a downstream constraint that prevents the licensee from limiting downstream copying. A company that does not want to be limited in what it does with its products needs a policy against the inclusion of code that is licensed with downstream constraints.

The organization should stick to software that is licensed under an open-source license with no constraints and software for which the organization has negotiated a license with the copyright holder that allows the business goals to be met.

Your policy should reflect your business model. For example, a company that gets most of its revenue from a large number of per-copy purchases of low-cost software would do well with a more restrictive policy toward the inclusion of open-source code. For this company, one violation of an in-license could lead to large liability and costs associated with product recalls.

However, if a company gets most of its revenue from a few sales of expensive software, a more relaxed policy might be more appropriate. In this case, inadvertent errors such as the inclusion of code for which the source code is not provided, or code for which the copyright notice was mistakenly omitted, can more easily be fixed and the liability per revenue dollar is likely to be lower.

Production Generation

The inclusion of code licensed under the GPL or some other license that does not allow sale and distribution compatible with the organization’s revenue model can be a major concern for software developers with proprietary sales revenue models — that is, source code not provided, per-copy licenses with no sublicensing.

Naturally, those developers would want more restrictive policies than, say, a company with a revenue model that relies more on services, support and the relationship between the company and the customer. In the latter case, the company might not worry too much about being faced with a choice to release source code to be in compliance with the GPL.

The policy also needs to take into account how the company’s programmers and other technical employees generate products. Some programming cultures use tools and code that are freely available. One might expect more openness with code among programmers in the fields of cryptography, image processing and networking, where tried-and-true algorithms are used over and over across many organizations.

Programmers of business process software, however, write code for a specific need known by only a few, and are likely to be less open.

Corporate Culture as Guide

Companies selling highly complex software designed to crunch proprietary data models for mutual fund analysis might be more likely to accept a stricter policy against the use of GPL’ed software. Programmers at a company that develops network protocol software are more likely to want a policy that allows for use of well-coded free or open-source software, even if it means that part of the software would be constrained by a particular free or open-source software license.

So how can you know if the open-source corporate policy you formulate is the right one? By carefully taking into account the nature of the products and services being provided by the organization, the revenue models for providing those products and services, and the culture of the organization’s developers and programmers, you can develop a policy that meets the unique needs of your organization.

In other words, your corporate culture will guide your corporate policy as much as the advice you get from legal counsel.