The cost of compliance may not just be a copyleft issue now we understand how to work with the GPL.
Even before Christoph Hellwig (backed by the Software Freedom Conservancy) started his suit to enforce his copyright claims against VMWare, there was a great deal of fear of the GPL in particular and copyleft licensing in general among corporate lawyers, and hence among their executive clients.
It arises from concern that software developers may inadvertantly impact corporate valuations and invite shareholder action by their routine development work. Lawyers are aware that the reciprocal terms of the GPL have been upheld in the courts of multiple jurisdictions. While there are many nuances, those terms summarise as “if any part of the code used to create the software you distriubute is licensed to you under the GPL, then every part of it must be made available under the GPL.” Since the GPL licenses copyright conditional on every recipient being free to request full corresponding source and then modify and/or distribute it, this could mean losing control of every part of your corporate product. Those are real concerns.
For a hardware vendor embedding open source code, a GPL violation would mean the loss of the copyright license and might require a whole warehouse of devices to be reflashed or destroyed. At a minimum it would probably mean stopping shipment while the matter was resolved.
For a software vendor, a strategy relying on trade secrets and vendor lock-in for monetisation could be severely disrupted by a GPL violation. Since funds loaned by VCs are not only scaled according to revenue but also use the degree of customer lock-in to determine the valuation multiplier, this could prove a disaster. While a company with massive proprietary lock-in might be valued by a VC at ten times its revenue, a pure service business on public code might only be valued at twice its revenue. No wonder VMWare fought back so energetically.
Of course, in VMWare’s case the alleged violation of the GPL was a strategic decision rather than an accident. But for the rest of us, the advice of corporate counsel to non-savvy CEOs leads to extreme risk aversion regarding the GPL. A whole industry has sprung up around this, dubbed by some the “compliance-industrial complex”. On the one hand companies like Black Duck and Palamida supply consulting and tools to root out GPLed code. On the other, entities like the Linux Foundation and Software Freedom Conservancy publish GPL compliance how-to guides.
This all adds to development expense and avoidance of the GPL as a license. But that action may not actually be helping the VP of Engineering. While concern over reciprocal terms has validity, it’s not the only license requirement deserving compliance. Even simple, so-called “permissive” licenses require compliance — just not regarding reciprocity. They commonly include attribution requirements that can become a major compliance challenge for the product team.
For example, the BSD license says in clause 2:
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
As soon as you use any part of a BSD-licensed source, you have to include details of its copyright holder with your program. As the number of sources used increases, so does the challenge of ensuring all the vary attribution requirements of the licenses they use are met. Due to the subtle variations of text of BDS/MIT/ISC licenses and their ilk each attribution replicates the text; the list often covers many, many pages. Maintaining it is a major headache for product engineering.
In the common case of the Apache License, things are even more complicated. It requires maintenance of a NOTICE file containing attribution lists, but also demands the insertion of “file changed” indicators in the code and even applies default licensing terms (including patent licensing) on upstream contributions if there’s no other contributor agreement. All of these requirements need tracking.
Just assuming that denouncing the GPL solves all your problems is thus a serious error. That’s why I prefer not to use the term “permissive” for non-copyleft licenses. All open source licenses are permissive as they grant you the freedom to use, improve and share copyrighted materials. That freedom is contingent on compliance with the license terms, though, and calling a license “permissive” masks that reality.
Some of your business functions may may emphasise the importance of reciprocity requirements in licenses (and for good reasons), but product engineering teams have to respect all requirements of both proprietary and open source ingredients. That compliance burden is not necessarily minimised by avoiding the GPL. Indeed, the wealth of resources and how-to guides for GPL compliance may make it the least problem.
Just because the “compliance-industrial complex” wants you to fear reciprocity, that doesn’t mean you should. Each case needs understanding on its own merits. Who knows — in your case, embracing the GPL may well be the least-cost option.
(Made possible by Patreon patrons. Perhaps you should become one?)
Dr. Roy Schestowitz (罗伊) ✅
All Jonkman Microblog content and data are available under the Creative Commons Attribution 3.0 license.