Blue Oak Council

This sample company open source policy shows how to use the council’s license list.

For more solutions, see the solutions list.

If you need legal advice or specific language for yourself or your company, don’t copy this example blindly. Hire a lawyer. A good one will ask you good questions, to understand your situation. Depending on your answers, they may decide this example meets your needs.

Open Source Policy

This policy is intended to enable our technical, business, and legal decision makers to leverage open source software while protecting our intellectual property assets and mitigating risk.

Skip To: Policy Roadmap FAQ

Policy

Choose the right software for the job.

We use open source software when it is the best tool, taking into account open source and proprietary alternatives, cost, quality and ease of support.

Use the Roadmap.

The Roadmap below identifies use cases, licenses, and necessary approvals. Determine your use case, and the license, then use the Roadmap to tell what approvals you need. If your use case or license is not on the Roadmap, you need approval of Legal.

Keep track.

Someday soon, someone will ask you for a list of all the open source you are using and the licenses that cover it. These requests can be crucial for our business, such as a condition for funding our company or sale of our company. You also need to know this information to comply with the open source licenses. Therefore, keeping track is not optional; it is part of your job. We use [self-reporting, Black Duck, Flexera, FOSSA] to track our use of open source software. You, not Legal, are responsible for keeping track.

You must follow this policy.

This policy is not optional. It must be followed by all engineering teams that work for us. If you disagree with this policy, or want to change any of this policy, talk to Legal.

You must comply with licenses.

If we decide to use open source software, we must comply with the licenses for it. It is important to our company to be a good citizen in the open source community, and fair to the developers who developed the software and chose the open source license. Each open source license has its own conditions for use, and they will depend on the use case. This policy does not tell you how to comply with each license. If you have questions about that, ask Legal. Your job is to follow this policy, including keeping track of what open source software you use. Those in the company who are responsible for implementing compliance (like delivering license notices and source code) will rely on the information you provide and the decisions you make, and may ask you for assistance, which you should provide.

Roadmap

Your Engineering Lead needs to approve all use of open source software. Legal approvals are required as follows:

Go

You do not need Legal approval to use code licensed under these licenses, for any use case.

Caution

You must obtain Legal approval to distribute code licensed under these licenses. You do not need Legal approval to make internal use of code licensed under these licenses.

Stop

You must obtain Legal approval to use any code licensed under these licenses:

FAQ

Here are some pointers on how to use the Roadmap. If you have another question, please contact Legal.

How do I identify the license?

Most projects identify the license on:

  1. on the project’s website and associated online documentation;
  2. in a text file contained in the distribution called LICENSE or COPYING; or
  3. in notices at the top of individual source files (sometimes called headers).

What if there is no license?

No license means no rights. You must not use the software. However, the software is critical, it might be possible to contact the owner and buy a license. Legal must be involved in that process.

What if there is more than one license?

You need to decide, based on your knowledge of what the software does and how it will be used, whether that means:

  1. we get to choose the license under which we will use the code;
  2. different parts of the project are under different licenses; or
  3. the licensing is messed up and we need to contact the project to sort it out.

What if the license is not on the Roadmap?

You must get Legal approval for any license not on the Roadmap.

What is a “use case”?

A use case means how we will use the software in our business. Uses cases can include:

And, along with any of the above:

What is Distribution?

Distribution means including open source code in:

What is Internal Use?

Internal use means using the open source code as a development tool or as part of building and running any of our products or services. Please note that code libraries in a development tool that will included in a distributed product at run-time (such as those included in SDKs or APIs) are not considered internal use and must be analyzed as distribution.

What is a Standalone Process?

It is a single executable process, and it is a concept relevant to compliance with GPL and LGPL. If you are uncertain about it, ask Legal.

What is dynamic linking?

It is a method, in some programming languages (like C++), for building products from binary objects, and it is a concept relevant to compliance with LGPL. If you have questions, ask Legal.

The contact in the Legal department for this policy is [Contact Name].

This policy is based on one created by Heather Meeker, who also reviewed this version.

Blue Oak Council makes all example language available under the Creative Commons CC0 1.0 Universal Public Domain Dedication.