Although I’ve read many articles about open source licensing, I’m continually surprised by the amount of confusion and disinformation I find related to the GNU General Public License (GPL). This post is written by a lay person for other lay persons. I’m not a lawyer, but I do a fair amount of IP strategy consulting with open source companies and have had the benefit of working with some of the best open source attorneys in the world. So I know enough to be dangerous and have an (more or less) informed point of view. Read the rest of this post with the understanding that I am offering my own views of the GPL, not legal advice.
The GPL’s Two-part Test
Let’s say you’re a software vendor that would like to combine your product with a GPL’d technology. To determine whether the combination will expose your product to the GPL (I’m assuming your product is not also licensed under the GPL), you need to answer two questions:
- Will the combination cause your product to become a derivative work of the GPL’d technology?
- If yes to #1, will you distribute your derivative work to others?
If you answer yes to both of the above questions, then chances are pretty good that your product will be exposed to the GPL. The following two sections of this article examine the contours of derivative works and distribution.
The GPL itself is frustratingly vague about what is/not a derivative work, leaving a lot of room for interpretation. Most of the discussion I’ve heard boils down to a couple of points:
- Program linkage. Some experts argue that the level of technical linkage between the programs matters a lot. The popular view is that statically linked programs create a single binary executable, so they certainly fall into the definition of a derivative work; programs that are dynamically linked allow binaries to execute in separate address spaces, so their status is unclear; programs that interoperate through a command line interface or across a network (say, via a web service) are probably loosely-coupled enough to be viewed as independent works.
- Data exchange. A thesis that’s gaining popularity is the nature of the data exchanged between the programs. To the degree the programs inter-operate in a “standard” way (e.g., a program that passes SQL to a database and gets back a result set), they are independent works. But if the programs exchange “complex internal structures”, they are combined works and subject to the GPL.
Since there’s not a significant body of case law against which to test the above interpretations, it’s difficult to know for sure what combinations do and do not create derivative works. For example, do programs that exchange complex internal structures across a network interface fall within the GPL’s scope? Some IP experts believe that the nature of the data exchange should carry more weight than the way in which the programs are linked when examining the GPL’s “one program or two?” question. Linkage techniques change regularly; data exchanges don’t.
The GPL is pretty clear that, if you distribute a program derived from a GPL-licensed technology, you do so under to the terms of the license. Thus, you can use your derivative works yourself without worrying about the license – this is why end user organizations have no direct license exposure if they create apps based on GPL’d technologies (although they might still have indirect exposure if the GPL’d technology includes code that infringes another license). So the issue of distribution applies only to software vendors contemplating the distribution of their derivative works.
The definition of “distribution”, although also up for debate, has been read pretty narrowly by the legal community. There’s a consistent view that distribution means to physically copy and deliver the derivative work to someone else, regardless of whether or not you’re charging a fee.
Interestingly, distribution is generally not considered to mean delivery across a network, in the style of a SaaS application. Unless the binary code of your derivative work runs directly on a recipient’s computer (i.e., not indirectly in a browser connected to a computer you control), you have not tripped the GPL’s “distribution” lever. This is why SaaS and Web 2.0 vendors that embed GPL’d technologies into their apps are not at risk of GPL exposure, even though many of those apps would clearly be considered derivative works.
If you’re a a software vendor currently using the GPL for your products (or considering its use), you may want to adjust the aperture of the license to make it more liberal or restrictive. Two popular GPL variations are discussed below.
FOSS (or FLOSS) Exception. In some license applications, the GPL is too restrictive. For example, MySQL AB chose the GPL for its eponymous database to promote organic adoption while discouraging ISVs from ripping the product off. MySQL discovered that many open source projects, ones that were using more permissive licenses like Apache or BSD, would not embed the MySQL database because they (correctly) believed doing so would create a license conflict. In response, MySQL AB crafted a GPL license “exception” that allows any open source project to interface to the MySQL database client libraries without incurring the risk of infection from the GPL. This legal carve-out is known as the Free (Libre) Open Source Software exception.
If you’re considering the use of a FOSS/FLOSS exception, you need to be careful not to inadvertently create a back-door through which you can be ripped off. Contact me and I will get you connected to a legal expert.
Affero GPL. As discussed in the Program Distribution section above, vendors that deliver their solutions across a network do not trip the GPL’s “distribution” lever. To close this loophole, Affero, Inc. created a variation of the GPL that expands the scope of distribution to include network services. The Free Software Foundation contemplated building the Affero “feature” into GPLv3 but ultimately punted. A good place to begin learning about the Affero GPL, or AGPL, is Wikipedia.