FOSS license compliance for companies

[ Editor's note: This is the third and final part of our series on FOSS license compliance. Part one introduced the topic and described what developers can do to protect their rights. Part two looked at compliance engineering—how to determine if a violation has occurred. ]

Getting started

Free and Open Source Software (FOSS) allows all stakeholders to use, study, share and improve code for commercial or non-commercial reasons. However, engagement can still appear daunting to companies. They are monetizing other people's creations, and, with the high economic value of FOSS, making a mistake is less easily forgiven than it might be in non-commercial circumstances.

Fortunately, there is a substantial body of documentation available to help commercial stakeholders learn how FOSS licenses work, how to communicate effectively to resolve issues, and how to understand what expectations might exist beyond simple legal requirements. There are also several organizations acting as neutral educators dedicated to licensing, development, and governance issues.

Complying with FOSS licenses

FOSS licenses use copyright law as a legal framework for applying their terms and conditions. In using copyright law the licenses are similar to proprietary software. However, FOSS licenses differ in the types of terms and have a different conceptual framework from proprietary licenses. Therefore FOSS licensing must be examined in its own context and without prior assumptions to ensure compliance.

There are four basic types of FOSS license: permissive, weak Copyleft, strong Copyleft and network protective. These can be placed on a sliding scale from licenses that do not have a perpetual grant to use, study, share and improve code through to licenses that perpetuate these freedoms through both traditional distribution and on the Internet. The fewest terms tend to be in permissive licenses and the most terms tend to be in strong Copyleft or network protective licenses. David Wheeler has created a graphic to visualize the relationship between various popular FOSS licenses using this scale.

Key examples of FOSS license terms can be found by reading the GNU GPLv2. This is the most popular license in the ecosystem, contains strong Copyleft provisions, and requires (among other things) attribution, access to source code, and for a copy of the license to be included with any code distributed in binary or source form. Many other FOSS licenses are broadly similar though they differ on details.

The different ways FOSS licenses express their various grants and terms has consequences for license use and compliance. These are legal documents and wording differences can make them incompatible with each other. It also means that there is no single approach to shipping code that satisfies all possible licensing requirements, which is an important consideration given that forgetting a license term can result in legal action.

A good process for FOSS compliance will deal with multiple licenses and terms by determining what code is included in a product and then checking which licenses apply. It will include provisions for understanding whether the various licenses are compatible with each other and for making sure they are not mixed incorrectly through code combination or linking. It will also include a review of included license terms and include a check for adherence in the product before distribution. To allow issues undetected in the process to be solved without undue escalation, it is also sensible to provide a contact address for people to report concerns.

Communicating to resolve problems

Being a good citizen in the FOSS community means pro-actively solving problems and maintaining a positive relationship with the projects producing source code used in products. These concerns center around the principle of share-alike, and rely on an understanding of how various parties are expected to act in this field.

The key expectations in FOSS are that everyone will follow the licenses and will contribute code improvements back to source (or "upstream") projects. The former is a legal requirement and the latter is a social expectation. Fulfilling both can greatly assist in maximizing a company's return from FOSS. Failing to do so can have negative consequences, ranging from legal action over licensing issues through to negative press because of a lack of cooperation with the community.

Dealing with these expectations requires community-oriented communication and quite a different approach to that used in traditional proprietary markets. Whereas proprietary code is about monetizing licenses, FOSS is about how shared technology is developed. FOSS licensing mistakes and other problems are usually resolved in an equitable manner. Parties in this field are rarely, if ever, interested in exploiting the value of the code to penalize infringing parties unduly.

Some best practice techniques have emerged around the gpl-violations.org project for resolving legal issues. The first step when receiving notice of a possible violation is to confirm to the reporter that the matter is being investigated. Then the discussion is moved to a private space where information can be shared without disruptive interjections. The party with the potential issue, now fully informed by the reporter, checks the problem against their internal compliance process. The final stage of communication is to update the reporter and issue a correction if a license violation has been identified.

Communicating with projects is equally straightforward. Current best practice is to establish a relationship between a designated company representative and a designated project spokesperson. This allows companies to keep projects informed of expected code use and contributions, and makes it possible to investigate any issues before public escalation. Regardless of whether an issue is about legal requirements or code contribution to the ecosystem, having a chance explain the corporate position clearly to the project helps defuse problems in a mutually acceptable manner.

Getting information

There is quite a lot information available to address the most popular licensing choices or combinations in the FOSS ecosystem. Most of this material centers around the GNU GPL because of its popularity in developer circles and because the majority of commercial activity is focused on the Linux kernel. Given this, an essential reading list for FOSS compliance includes:

• How to use GPL licenses for your own software
• A legal issues primer for Open Source and Free Software projects
• Practical guide to GPL compliance
• Useful GPLv2 compliance tips for vendors
• Quick guide to GPLv3
• GPLv3 summary for managers
• A list of popular FOSS licenses and their compatibility with GPLv2 or v3
• Reporting and fixing violations

Additionally, people focused on code development will find "The Touchier Points of Determining the License of an Open Source Project" and "Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers" useful. People dealing with multiple versions of GPL code will find the compatibility matrix published by FSF helpful. People seeking to allocate exposure in supplier/purchaser relationships will benefit from examining the recently released Risk Grid [PDF] and its accompanying explanatory article.

More specialized information is also available, ranging from license agreements that reduce exposure to software patents through to manuals showing how gpl-violations.org discovers license violations in embedded products [PDF]. When it comes to finding such niche information the most productive approach is to establish relationships with knowledge providers in this field.

Finding knowledge providers

There are numerous parties offering opinions in FOSS. Finding reliable providers for commercial interaction requires a focus on parties with an established reputation and an understanding of ICT business imperatives.

Two relatively recent initiatives with substantial reach and non-partisan membership are the European Legal Network, which has over 200 members across 27 countries and 4 continents, and the International Free and Open Source Software Law Review, which provides a neutral platform for detailed and industry relevant discussions.

It is worth building relationships with organizations like FSFE's Freedom Task Force, FSF's Free Software Licensing and Compliance Lab, Linux Foundation, gpl-violations.org, Software Freedom Law Center, Open Bar, ifrOSS and FOSSBazaar. They all provide various services related to direct licensing assistance, explanatory documentation, case law examples, and fostering professional cooperation between FOSS stakeholders.

Conclusion

FOSS offers tremendous value in the development of shared platforms. Harnessing this requires the establishment of on-going relationships between diverse stakeholders, and for a combination of adherence to license terms and respect towards code creators' wishes.

---

(Log in to post comments)