WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.
WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.
GPL compliance and LGPL compliance mostly involve the same issues. As we discussed in § 14.1, questions of modified versions of software are highly fact-dependent and cannot be easily addressed in any overview document. The LGPL adds some additional complexity to the analysis. Namely, the various LGPL versions permit proprietary licensing of certain types of modified versions. These issues are discussed in greater detail in Chapter 10 and 11. However, as a rule of thumb, once you have determined (in accordance with LGPLv3) what part of the work is the “Application” and what portions of the source are “Minimal Corresponding Source”, then you can usually proceed to follow the GPL compliance rules that discussed above, replacing our discussion of “Corresponding Source” with “Minimal Corresponding Source”.
LGPL also requires that you provide a mechanism to combine the Application with a modified version of the library, and outlines some options for this. Also, the license of the whole work must permit “reverse engineering for debugging such modifications” to the library. Therefore, you should take care that the EULA used for the Application does not contradict this permission.
Thus, under the terms of LGPL, you must refrain from license terms on works based on the licensed work that prohibit replacement of the licensed components of the larger non-LGPL’d work, or prohibit decompilation or reverse engineering in order to enhance or fix bugs in the LGPL’d components.
LGPLv3 is not surprisingly easier to understand and examine from a compliance lens, since the FSF was influenced in LGPLv3’s drafting by questions and comments on LGPLv2.1 over a period of years. Admittedly, LGPLv2.1 is still in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you may encounter. The best advice there is careful study of Chapter 10.
However, to repeat a key point here made within that chapter: Note though that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the worst case you simply need to comply as if the software was licensed under GPLv2. The only reason you must consider the question of whether you have a “work that uses the library” or a “work based on the library” is when you wish to take advantage of the “weak copyleft” effect of the Lesser GPL. If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the entire work anyway), you may find this an easier option.
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 § 14. 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:
This last point is particularly important. Many GPL enforcement actions 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 Free Software 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.
In particular, any time your vendor incorporates copylefted software, you must exercise your own rights as a user to request CCS for all the copylefted programs that your suppliers provided to you. Furthermore, you must ensure that CCS is correct and adequate yourself. Good vendors should help you do this, and make it easy. If those vendors cannot, pick a different vendor before proceeding with the product.
Often, larger companies often encounter copyleft licensing during a Mergers and Acquisitions (M&A) process. Ultimately, a merger or acquisition causes all of the other company’s problems to become yours. Therefore, for most concerns, the acquirer “simply” must apply the compliance analysis and methodologies discussed earlier across the acquired company’s entire product line. Of course, this is not so simple, as such effort may be substantial, but a well-defined process for compliance investigation means the required work, while voluminous, is likely rote.
A few sections of GPL require careful attention and legal analysis to determine the risk of acquisitions. Those handling M&A issues should pay particular attention to the requirements of GPLv2 §7 and GPLv3 §10–12 — focusing on how they relate to the acquired assets may be of particular importance.
For example, GPLv3§10 clarifies that in business acquisitions, whether by sale of assets or transfers of control, the acquiring party is downstream from the party acquired. This results in new automatic downstream licenses from upstream copyright holders, licenses to all modifications made by the acquired business, and rights to source code provisioning for the now-downstream purchaser. However, despite this aid given by explicit language in GPLv3, acquirers must still confirm compliance by the acquired (even if GPLv3§10 does assert the the acquirers rights under GPL, that does not help if the acquired is out of compliance altogether). Furthermore, for fear of later reprisal by the acquirer if a GPL violation is later discovered in the acquired’s product line, the acquired may need to seek a waiver and release of from additional damages beyond a requirement to comply fully (and a promise of rights restoration) if a GPL violation by the acquired is later uncovered during completion of the acquisition or thereafter.
Finally, other advice available regarding handling of GPL compliance in an M&A situation tends to ignore the most important issue: most essential copylefted software is not wholly copyrighted by the entities involved in the M&A transaction. Therefore, copyleft obligations likely reach out to the customers of all entities involved, as well as to the original copyright holders of the copylefted work. As such, notwithstanding the two paragraphs in GPLv3§10, the entities involved in M&A should read the copyleft licenses through the lens of third parties whose software freedom rights under those licenses are of equal importance to then entities inside the transaction.
GPLv3 requires you to provide “Installation Information” when v3 software is distributed in a “User Product.” During the drafting of v3, the debate over this requirement was contentious. However, the provision as it appears in the final license is reasonable and easy to understand.
If you put GPLv3’d software into a User Product (as defined by the license) and you have the ability to install modified versions onto that device, you must provide information that makes it possible for the user to install functioning, modified versions of the software. Note that if no one, including you, can install a modified version, this provision does not apply. For example, if the software is burned onto an non-field-upgradable ROM chip, and the only way that chip can be upgraded is by producing a new one via a hardware factory process, then it is acceptable that the users cannot electronically upgrade the software themselves.
Furthermore, you are permitted to refuse support service, warranties, and software updates to a user who has installed a modified version. You may even forbid network access to devices that behave out of specification due to such modifications. Indeed, this permission fits clearly with usual industry practice. While it is impossible to provide a device that is completely unmodifiable1, users are generally on notice that they risk voiding their warranties and losing their update and support services when they make modifications.2
GPLv3 is in many ways better for distributors who seek some degree of device lock-down. Technical processes are always found for subverting any lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike with GPLv2, the license gives you clear provisions that you can rely on when you are forced to cut off support, service or warranty for a customer who has chosen to modify.
There are admittedly portions of the GPL enforcement community that function somewhat like the computer security and network penetration testing hacker community. By analogy, most COGEO’s consider themselves white hats, while some might appropriately call proprietary relicensing by the name “black hats”. And, to finalize the analogy, there are indeed few grey hat GPL enforcers.
Grey hat GPL enforcers usually have done some community-oriented GPL enforcement themselves, typically working as a volunteer for a COGEO, but make their living as a “hired gun” consultant to find GPL violations and offer to “fix them” for companies. Other such operators hold copyrights in some key piece of copylefted software and enforce as a mechanism to find out who is most likely to fund improvements on the software.
A few companies report that they have formed beneficial consulting or employment relationships with developers they first encountered through enforcement. In some such cases, companies have worked with such consultants to alter the mode of use of the project’s code in the company’s products. More often in these cases, the communication channels opened in the course of the inquiry served other consulting purposes later.
Feelings and opinions about this behavior are mixed within the larger copyleft community. Some see it as a reasonable business model and others renounce it as corrupt behavior. Regardless, a GPL violator should always immediately determine the motivations of the enforcer via documented, verifiable facts. For example, COGEOs such as the FSF and Conservancy have made substantial public commitments to enforce in a way that is uniform, transparent, and publicly documented. Furthermore, since these specific organizations are public charities in the USA, they are accountable to the IRS (and the public at large) in their annual Form 990 filings. Everyone may examine their revenue models and scrutinize their work.
However, entities and individuals who do GPL enforcement centered primarily around a profit motive are likely the most dangerous enforcement entities for one simple reason: an agreement to comply fully with the GPL for past and future products — always the paramount goal to COGEOs — may not suffice as adequate resolution for a proprietary relicensing company or grey hat GPL enforcer. Therefore, violators must consider carefully who has made the enforcement inquiry and ask when and where the enforcer made public commitments and reports regarding their enforcement work and perhaps even ask the enforcer to directly mimic CEOGEO’s detailed public disclosures and follow the standard requests for resolution found in this document.
1Consider that the iPhone, a device designed primarily to restrict users’ freedom to modify it, was unlocked and modified within 48 hours of its release.
2A popular t-shirt in the software freedom community reads: “I void warranties.”. Our community is well-known for modifying products with full knowledge of the consequences. GPLv3’s “Installation Instructions” section merely confirms that reality, and makes sure GPL rights can be fully exercised, even if users exercise those rights at their own peril.