Open Source Software Policy

Open Source Software can be a very good thing; why reinvent something? But its use can make the legal departments of many companies uncomfortable.

Unfortunately, I’ve seen a common pantomime play out: a complex or heavyweight policy is established and the organization’s software developers either don’t understand it or choose to ignore it. (The whole “it’s easier to ask for forgiveness …”)

About 10 years ago, at a former employer, we came up with a policy that we used and has been adopted by many other organizations we worked with.

The core concept is based on the idea that the license (BSD, MIT, GPL,..) is much more significant than the individual element of open source software. (While this might be obvious, I’ve had many lawyer discussions that spent too much time discussing the nuances and code details about how the open source would be incorporated).

Policy

(NOTE: I am not a lawyer. If the policy below is interesting to you, please consult an actual attorney before adopting it. Even if you follow the framework, the content of the lists noted below will vary in organizations.)

So, we drafted three lists:

• white list
• black list
• gray list

A developer, when considering the use of an element of open source software, should first check the license that governs the software (frequently in a LICENSE file). The developer then proceeds as dictated by the list that contains the license.

White List

If an item is on the white list, it is deemed safe to use and the developer can incorporate the open source software.

Examples of possible white listed licenses are MIT and BSD.

Black List

If an item is on the black list, it is probably not safe to use. While you may discuss the details with your legal counsel, it is probably better to simply look for an alternative.

A common example of a black listed license is the AGPL. But even this can have some complexity, as software such as MongoDB is AGPL, but the drivers for accessing it are Apache 2. So your organization may be comfortable using MongoDB to store data, but uncomfortable modifying it.

Make friends with your lawyers and discuss it. :)

Gray List

If an item is on the gray list, it is not clear if it is okay to use. In such cases, a developer should ask for permission, from the appropriate group in their organization.

A common example of a gray list item might be Apache 2. It has patent provisions that can complicate its use. In some cases the software’s authors are competitors and your legal counsel may prefer not to use the software. In other cases, there isn’t any concern.

Practical Considerations

I’ve found that developers can live with this policy and not feel unduly burdened. Similarly, lawyers can get comfortable with it as well. There may be some debate on the different list’s content, but that shouldn’t be too hard (nor expensive) to resolve.

It is also okay to include individual pieces of software in the various lists; this would override the license type aspect of the policy.

For example, ReactJS can be tricky. While it is licensed under BSD, there are additional patent terms that govern the software’s use but aren’t included in the license file. (They can be found in the PATENT file.) Therefore, I’ve seen ReactJS on gray lists where BSD itself is on the white list.

As with most things, iterate. Periodically review what OSS is being used and the members of the white, gray and black lists. I think it is better to continually evaluate the policy than “file it away.”