: 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
compliance engineering—how to determine if a violation has occurred. ]
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
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.
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
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.
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.
to post comments)