X
Business

GPLv3 myth#2: You can't mix GPL software with other software

It's a widely held belief that you can't mix GPL code and code covered by other open source licenses. While there are restrictions, it is actually possible in both GPLv2 and GPLv3. New language in the GPLv3 final draft, though, makes this much clearer, and the FSF has said explicitly that GPLv3 is compatible with version 2.0 of the Apache license. In this article we consult with noted open source attorney Lawrence Rosen, plus Jim Jagielski and Justin Erenkrantz from the Apache Foundation, to figure out exactly how this is supposed to work for developers.
Written by Ed Burnette, Contributor

Now that the “Final Draft” of the GNU General Public License version 3 (GPLv3) is out I thought it would be a good time to take a look at some of the least well understood provisions in the license. In part 1, we explored the notion of selling GPL software. This part looks at mixing GPL (v3 and v2) software with software covered by other licenses.

Disclaimer: This information was culled from a variety of sources, including the GPLv3 web site, interviews with experts involved in the process, and analysis from various industry watchers. However this isn’t intended as legal advice.

Myth 2: You can't mix GPL software with other software.

False. According to experts in open source licenses this is possible, especially with the wording in the latest GPLv3 draft.

First, the easy cases. Both versions of GPL have a clause that allows "aggregations" of GPL covered software with non-GPL software. GPLv3 draft 4 puts it this way in section 5 (GPLv2 says something similar in section 2 of that license):

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

Take, for example, Red Hat Enterprise Linux. RHEL contains both free and non-free programs. It contains programs covered by GPL, EPL, Apache, BSD, and every other conceivable license. The last paragraph in section 5 says this is OK even though they're conveyed as a single aggregate.

In his "Comments on GPLv3" essay, open source attorney Lawrence Rosen writes that he believes this clause can even be used to combine GPL licensed code "modules" with code from other licenses even in the same program, though I think that's a bit of a stretch. When I told Larry that he responded:

Stretch away. If you mean the term "module" is a "smallest unit of compiled object code," then perhaps it is not copyrightable at all. But in the general sense I meant that word as applied to larger, commercially and computationally significant copyrightable works, such as "a database module" or a "file system module," that contain significant copyrightable expressive content. If those independently-written copyrighted modules are used in a collective work (a larger computer system), and both licenses permit verbatim copies to be aggregated in that way, then I consider that a permitted collective work. There is nothing derivative about it (unless, perhaps, the resulting larger work is intended as a replacement database or file system module for the originals, but that's a factual issue relating to derivative works analysis).

I don't agree with this argument because the combination would be possible not just with Apache licensed code, but with code covered by any license, even proprietary, closed source code. I don't think RMS (Richard Stallman) would agree either. To this, Larry replied:

He doesn't. But he wrote GPLv3 and he must now live by the words in his license.

In any case, for more granular combinations, such as taking a C or Java source file using GPL and a source file from a non-GPL license and using them both in a larger program, we don't have to rely on Rosen's interpretation. GPLv3 (and to a lesser extent GPLv2) allows this in a limited fashion with certain licenses. GPLv3 adds the "section 7 exception" to attempt to make this clear.

The FSF has stated explicitly that Apache 2.0 is compatible with GPLv3. I asked Apache if they could confirm. "Yes," wrote Justin Erenkrantz of the Apache Foundation, "and we're very excited about this!" He says section 7 is the key to the claim of compatibility between GPLv3 and the Apache License v2. It reads, in part (from GPLv3 draft 4):

"Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

The bottom line is that anyone can now use Apache code inside a program that, overall, is licensed under GPLv3. Note that the reverse is not true. We discussed a hypothetical example where you wanted to add some code from Apache Harmony to Sun's Java 7 / OpenJDK (assuming OpenJDK adopts GPLv3 and it's largely the same as the final draft). Justin writes:

The hypothetical collective combined work will be controlled under the terms of the GPLv3 - the code from Apache isn't relicensed per se (as the ALv2 still applies to our code). The statement about compatibility from the FSF is that the GPLv3 can incorporate code that is licensed under the ALv2 and still have the larger combined work redistributed under the terms of the GPLv3.

Jim Jagielski agrees. "Since GPLv3 is more 'restrictive' than the Apache license," he writes, "the combined work would be under GPLv3." Just to be clear, I asked again to make sure that the GPL license would not "leak out" and cause non-GPL code to somehow be "accidentally released" as GPL. Justin replied:

No, you are correct - you wouldn't have the right to relicense it in the sense of removing our ALv2 license and slapping on your own license. However, the legal reasoning here is that the entire collective work (i.e. both the ALv2 and GPLv3-licensed code) can be distributed just by following the terms of the GPLv3 (& Sec. 7). Viewed in this manner, the GPLv3 is a superset of terms contained in the ALv2 - so by adhering to the GPLv3 (again, including the relevant Sect. 7 terms), you are also complying with the necessary terms of the ALv2 as well.

The good news is that this works with any license deemed "compatible" with GPL, not just Apache. For GPLv2, there is a list at the GNU web site. Presumably the list will be updated for GPLv3 once it's finalized.

As attorney Lawrence Rosen notes in his essay, this is a complicated issue and different people can have different interpretations. "You should still consult with your own attorneys to ensure that you clearly understand the legal distinctions," he writes. Larry still favors his own Open Software License (OSLv3), and writes that while GPLv3 is a step in the right direction, it's not the 'one license to rule them all'. That's OK, he says:

I believe GPLv3 is a good license that many of us can live with, but it will never be the only license that serves the free and open source community. Owners of software have other good licenses to choose from that will meet their own philosophical and business goals. The Apache, Eclipse, Mozilla and Perl foundations and many other projects will continue to build upon their own visions of free and open source software using their own licenses. To the extent that GPLv3 embraces participation in that larger community, I’m quite satisfied with it, even though it won’t necessarily be the license I’ll recommend.

If you have any questions on GPL license compatibility there are legal discussion forums on both the GNU and Apache sites. Or you can post comments here and I'll forward them to the folks that I've consulted to see if they have any further clarifications.

Editorial standards