5 Practical Ways for Legal Counsel to Advise Developers on Open Source

As an essential member of an open source compliance program’s advisory board, legal counsel provides numerous services to ensure a company’s products comply with open source copyright and licenses. They provide approval around the use of FOSS in products, for example, advise on licensing conflicts, and advise on IP issues associated with the use of FOSS. (See the previous article, 5 Essential Duties of Legal Counsel in an Open Source Compliance Program.)

But legal counsel also provides practical advice to a company’s software development team that enables developers to make daily decisions related to open source licenses without having to go back to the legal counsel for every single question. These resources may not answer every single question or concern that arises from engineering teams working with FOSS. But they provide a good basis from which developers can operate largely independently with occasional recommendations and guidance from attorneys directly.

5 Practical Ways for Legal Counsel to Advise Developers

1. License Playbooks: An easy to read and digest summary of FOSS licenses intended for software developers.

License Playbooks are summaries of most used or most popular FOSS licenses. They provide easy to understand information about these licenses such as license grants, restrictions, obligations, patent impact and more. License playbooks minimize the number of basic questions sent to legal counsel and provide developers with immediate information about these most-used licenses.

2. License compatibility matrix: An easy method to learn if License-A is compatible with License-B. Such a matrix can be used by software developers as they merge code incoming from different projects under different licenses into a single body of code.

Many of the FOSS licenses, while different, may be compatible such that certain uses or combinations may be allowed. One example is the 3-clause BSD license (also referred to as the “modified BSD license”) is compatible with the GNU GPL. This means that 3-clause BSD source code can be combined with a source code that is licensed under the GNU GPL; the new program resulting from the combination would have to be licensed under the GNU GPL terms however. Other FOSS and proprietary software licenses are not GPL-compatible since they have conflicting terms and conditions. There are good references on the Internet for pointers to compatibility, but it’s often best if internal counsel create a matrix based on the company’s view of compatibility. References such as the Free Software Foundation’s GPL-compatible Free Software List can be helpful.

3. License classification: Some companies opt to classify the most used licenses in their products under a few categories to provide an easy way to understand the differences and the course of action needed when using source code provided under these licenses.

Example categories include:

• Pre-approved Licenses, along with any practical guidance, internal conditions or policies on usage, or other requirements to use without approval in your company’s solutions.

• Licenses Requiring Manager’s Approval

• Licenses Requiring Legal Counsel Approval

• Prohibited Licenses.

Some companies with larger scale FOSS operations will often use an Open Source Review Board as a required review step before approving certain licenses.

4. Software interaction methods: A guide to understand how software components available under different licenses interact, and if the method of interaction is allowed per company compliance policies.

As part of the compliance process, there is usually a step in the process where your legal or  Open Source Review Board conducts an architecture review of the software component in question. The goal of the architecture review is to understand how that specific software component interacts with other software components and the method of interaction which may trigger license clauses in various free software or other open source licenses.

5. Checklists: An easy way to remember what needs to be done at every gate in the development and compliance processes. When it comes to open source compliance, several checklists can be developed and used before approving the open source code being merged into the product’s source code repository.

The following checklist is an example used before developers make source code available on the website (license obligation fulfillment):

• All source code components have a corresponding “compliance ticket” in your bug/issue tracking system.

• All compliance tickets have to be approved by engineering and legal (or appropriate per your pre-approved/required review policy).

• All compliance tickets are clear from any sub-tasks attached to them. (all other issues/questions/requirements have been resolved)

• Notices for all of the software components (e.g. attributions) have been sent to Documentation team and included in product documentation (including written offers, if required).

• Legal has approved the written offer notice (if required) and overall compliance documentation.

• Source code packages have been prepared and tested to compile on a standard development machine.

• Source code provided is complete and corresponds to the binaries in the product and is ready to post to your website.

Many of these elements will also become part of your company’s core compliance training and should be used to educate developers in your company about your policies and process for implementing FOSS into products or solutions. Many companies that have been implementing FOSS at scale will require their developers to complete a FOSS compliance online training course that the legal team will be involved in reviewing and or preparing. FOSS compliance does not have to be difficult and with clear processes, training and practical guides for your developers it can become a simple streamlined part of your product development cycle.

For more on this I recommend Ibrahim Haddad’s full white paper, Practical Advice to Scale Open Source Legal Support.  I’d like to hear how your company is handling compliance and what areas in the industry could use more focus. You can find me on Twitter at @mdolan.

Read more:

Part 1: Why Companies That Use Open Source Need a Compliance Program

Part 2: 5 Essential Duties of Legal Counsel in an Open Source Compliance Program

The Open Compliance Program at the Linux Foundation aims to help organizations achieve compliance faster and cheaper by providing a number of resources that are accessible via http://compliance.linuxfoundation.org.