The Software Freedom Law Center has just released “A Practical Guide to GPL Compliance“. For those not familiar with the SFLC, it is a group that helps to protect free and open source software (or “FOSS”), including advancement of claims against those who infringe open source licenses such as the GPL.
The guide is helpful in navigating through some of the more technical issues regarding GPL compliance, and in addition does offer some advice on best practices generally regarding software development to avoid problems later on. For example, the following is good advice generally on implementing development controls to avoid possible infringement issues:
The companies we contact about GPL violations often respond with: “We didn’t know there was GPL’d stuff in there”. This answer indicates a failure in the software acquisition and procurement process. Integration of third-party proprietary software typically requires a formal arrangement and management/legal oversight before the developers incorporate the software. By contrast, your developers often obtain and integrate FOSS without intervention. The ease of acquisition, however, does not mean the oversight is any less necessary. Just as your legal and/or management team negotiates terms for inclusion of any proprietary software, they should be involved in all decisions to bring FOSS into your product.
Simple, engineering-oriented rules help provide a stable foundation for FOSS integration. Ask your software developers to send an email to a standard place describing each new FOSS component they add to the system, and have them include a brief description of how they will incorporate it into the product. Make sure they use a revision control system, and have store the upstream versions of all software in a “vendor branch” or similar mechanism, whereby they can easily track and find the main version of the software and local changes made.
Such procedures are best instituted at your project’s launch. Once a chaotic and poorly-sourced development process has begun, the challenges of determining and cataloging the presence of GPL’d components is difficult. If you are in that situation, we recommend the Fossology system, which analyzes a source-code base and produces a list of FOSS licenses that may apply to the code. Fossology can help you build a catalog of the sources you have already used to build your product. You can then expand that into a more structured inventory and process.
Similarly, some helpful advice on dealing with other inbound vendors whose work you will be incorporating:
With ever-increasing frequency, software development (particularly for embedded devices) is outsourced to third parties. If you rely on an upstream provider for your software, note that you cannot ignore your GPL compliance requirements simply because someone else packaged the software that you distribute. If you redistribute GPL’d software (which you do, whenever you ship a device with your upstream’s software in it), you are bound by the terms of the GPL. No distribution (including redistribution) is permissible absent adherence to the license terms.
Therefore, you should introduce a due diligence process into your software acquisition plans. This is much like the software-oriented recommendations we make in § 3. Implementing practices to ensure that you are aware of what software is in your devices can only improve your general business processes. You should ask a clear list of questions of all your upstream providers and make sure the answers are complete and accurate. The following are examples of questions you should ask:
- What are all the licenses that cover the software in this device?
- From which upstream vendors, be they companies or individuals, did you receive your software from before distributing it to us?
- What are your GPL compliance procedures?
- If there is GPL’d software in your distribution, we will be redistributors of this GPL’d software. What mechanisms do you have in place to aid us with compliance?
- If we follow your recommended compliance procedures, will you formally indemnify us in case we are nonetheless found to be in violation of the GPL?
This last point is particularly important. Many GPL enforcements are escalated because of petty finger-pointing between the distributor and its upstream. In our experience, agreements regarding GPL compliance issues and procedures are rarely negotiated up front. However, when they are, violations are resolved much more smoothly (at least from the point of view of the redistributor).
Consider the cost of potential violations in your acquisition process. Using FOSS allows software vendors to reduce costs significantly, but be wary of vendors who have done so without regard for the licenses. If your vendor’s costs seem “too good to be true,” you may ultimately bear the burden of the vendor’s inattention to GPL compliance. Ask the right questions, demand an account of your vendors’ compliance procedures, and seek indemnity from them.
Lastly, the guide helps to identify the “costs” of GPL software – there may not necessarily be a license fee, but there will be time and effort involved in complying with terms, as well as risks associated with such compliance, such as cohesion (or lack thereof) with your overall business strategy. For developers, becoming familiar with compliance requirements will allow for better decisions to be made, including more accurate comparative assessments of the overall costs associated with GPL relative to, say, proprietary alternatives. And it is definitely better to figure these sorts of things out sooner in the process, rather than learning about them say, when someone is doing a due diligence review of your organization.
