License Compatibility for Derivative Works

If there is one issue that causes the most confusion and angst in the open source licensing community it is this: How do open source licenses interact with each other when derivative works are created from multiple contributions?

For example, a GPL-licensed contribution may be offered for an Apache-licensed derivative work. Or an OSL-licensed contribution may be offered for a GPL-licensed derivative work. What license terms apply to the resulting derivative work? Can the contribution even be accepted, consistent with the terms of both the contribution and derivative works licenses?

I discussed in the previous section the simpler problem of incorporating a contribution into a collective work ; that is always allowed under an open source license because of Open Source Principle # 5. And I leave until Chapter 12 the complex issue of how you determine whether something is actually a derivative work. For present purposes, all I ask is whether the open source licenses are compatible for creating derivative works, whatever that technical term of art means.

License Compatibility for Contributions under Reciprocal Licenses

It is easy to understand what happens when you in-license a contribution under a reciprocal license. You can't use it for a derivative work unless both the contribution and the derivative work are licensed under the same reciprocal license. That is the very principle of reciprocity, as represented in the chart below:

		DERIVATIVE WORK
		GPL	MPL	CPL	OSL
CONTRIBUTION	GPL	yes	no	No	no
	MPL	no	yes	No	no
	CPL	no	no	Yes	no
	OSL	no	no	No	yes

This chart suggests that once you start a contribution under the GPL, MPL, CPL, or OSL, that same license is the only one that can be used for subsequent derivative works. In reality, however, the reciprocity provisions in open source licenses are much more subtle than that.

Some licenses, such as the MPL and CPL, complicate the analysis by defining an iterative process by which contributions become part of a package that grows over time. Those contributions are not necessarily separately licensed, and you have to analyze the license carefully to determine whether it is possible to reuse contributions to those packages in other separately developed derivative works other than under the terms of the MPL or CPL license.

For example, the MPL expects contributions (Modifications or files) to be governed by the terms of the MPL. (MPL section 3.1.) But the MPL then allows contributions to be reused as part of a "Larger Work." (MPL section 2.2[a].) The term Larger Work is defined in terms reminiscent of a collective work. (MPL section 1.7.) I read this to mean that MPL-licensed contributions can be used for differently licensed collective works but not for derivative works, which appears to be consistent with the chart above.

The MPL license provides another potential escape from the license incompatibility problem by allowing licensees to distribute derivative works under the licensee's choice of the MPL or an alternative license specified by the Initial Developer in its Exhibit A. The website of the Free Software Foundation ( www.fsf.org ) suggests that if the alternative license is the GPL, then that part of the program has a compatible license. Note, however, that this choice is only available to the Initial Developer, and that it applies only because the alternative license is the GPL, not the MPL. According to the Free Software Foundation, the MPL itself remains incompatible with the GPL.

The OSL states the reciprocity provision succinctly:

[ Licensor grants You a license] to distribute copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute shall be licensed under the Open Software License. ( OSL section 1[c].)

There are no exceptions. Derivative works may only be distributed under the OSL, regardless of the license on the contribution. Of course, the license on that contribution must authorize that:

Licensor warrants that [the contributions] are sublicensed to You under the terms of this License with the permission of the contributor (s) of those copyrights and patent rights. ( OSL section 7.)

Under the CPL, Contributions do not include "separate modules of software distributed in conjunction with the Program under their own license agreement." (CPL section 1.)

"Contribution" means: ... (b) in the case of each subsequent Contributor: i) changes to the Program, and ii) additions to the Program. ( CPL section 1.)

So under the CPL, a derivative work is created not by accepting a separate Contribution and combining it in some way with another work, but by making changes or additions to that other work. Furthermore, the CPL requires that a Contributor be the author and distributor of his or her own Contributions, meaning that the CPL does not allow sublicensed Contributions at all.

The GPL license is widely considered to be the most restrictive in this respect, because of the interaction of the following provisions:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. ( GPL section 2[b].)

You may not impose any further restrictions on the recipients' exercise of the rights granted herein. ( GPL section 6.)

Derivative works of contributions submitted under the GPL must be distributed under the GPL, and you can't add any further restrictions. Once a chain of title is started for a contribution under the GPL, the GPL is the only license that can be used for subsequent derivative works.

License Compatibility for Contributions under Academic Licenses

What does it mean for the GPL to say that you can't add any further restrictions?

The BSD and MIT licenses are read to contain no conditions that could possibly interfere with any other license for derivative works. According to the Free Software Foundation, these licenses can be used for contributions to GPL-licensed derivative works, and I am aware of no open source project, under any license, that ever refuses BSD- and MIT-licensed contributions for creating derivative works. Such software can be used anywhere for any purpose.

The Free Software Foundation asserts that the Apache License, perhaps because of its provisions regarding the Apache trademark, is incompatible with the GPL. (But is a trademark exclusion, which states an essential rule under trademark law, an additional restriction that makes a license incompatible with the GPL?) Most contributors use the Apache license for contributions to Apache software and for nothing else. It is a shame that valuable Apache software is not being used for GPL-licensed derivative works simply because of the resistance to additional restrictions by the authors of the GPL.

The answer is not so simple for the Academic Free License. As I described in Chapter 9, the AFL contains several terms and conditions that are at least different from, if not contrary to, the provisions of other licenses. The AFL permits derivative works to be licensed under any license, but does that mean that AFL-licensed contributions can actually be so used without conflict with those other licenses?

Among the provisions of the AFL that are additional to those in the GPL are terms relating to the scope of the patent grant; the requirements regarding attribution rights; the warranty of provenance; provisions relating to jurisdiction, venue , governing law, and attorneys ' fees; and, perhaps most contentious, the patent termination provision in AFL section 10.

Consider the effect on downstream licensees and sublicen-sees of a contribution originally licensed under the AFL with its patent termination provision. That provision protects the original Licensor, A , from patent infringement lawsuits by his or her licensees. Assume A 's contribution is used by another author, D , to create a derivative work. Obviously D is a licen-see of A, and D cannot sue A for patent infringement without terminating the license. That much is straightforward under AFL section 10.

But the AFL is sublicensable, and so what happens when the derivative work is licensed by D to a downstream customer, X , under some different license that doesn't provide notice of the patent defense provision. That other license could be the GPL, one of the other open source licenses described in this book, or even a proprietary license. The AFL imposes no restrictions on that kind of downstream sublicensing. A 's contribution is effectively sublicensed to X .

Can X sue the author of A for patent infringement without risking termination of his license for D ? Does X even have any way to know of the terms of A 's license? Does section 10 of the AFL extend through sublicensing to protect the author of A even against patent infringement lawsuits by downstream sublicensees like X ? Similar questions could be framed about other potentially uncomfortable terms from A 's license, such as the AFL's attorneys' fees provision or the scope of its patent grant. Do such terms bind ”via sublicensing ”the recipients of derivative works of AFL-licensed contributions?

I find it hard to believe that any court would bind any downstream sublicensee of an open source contribution to any terms and conditions of a license of which he was not informed and didn't manifestly accept. That is certainly a basic tenet of contract law and a fair result in the context of mass-marketed open source software offered for free over the Internet. So to the extent that an AFL-licensed component was sublicensed by D as part of a derivative work, customer X at the end of the chain cannot be bound to the AFL but only to the license with D that he or she accepted.

This situation is not unfair to A . Remember that A could have avoided this result by distributing his or her contribution under a license that forbids sublicensing. Instead, A intended to contribute software under a license that was completely permissive about derivative works. A 's software can even be used in proprietary derivative works. License terms do not pass through via sublicensing unless A insists upon it in the software license, and the AFL does no such thing.

So it is unclear to me how an academic license such as the AFL can be incompatible with any other open source licenses. The AFL doesn't impose any conditions except upon the li-censee of that software, and that licensee is permitted to sublicense the contribution under any license whatsoever.

Of course, these notions of fairness and the requirement that a licensee be informed of conditions to which he or she is bound apply only under contract law, not for a bare license under copyright law. I don't know how a court would decide such sublicensing issues for bare licenses.

The MPL license deals with license compatibility for derivative works by requiring a specific Contributor Grant. As long as the Contributor submits his or her Modification under the terms of that Contributor Grant, the MPL doesn't care about other licenses. It is up to the Contributor to ensure that whatever he or she contributes is Licensable by Contributor. (MPL section 2.2.)

"Licenseable" means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently acquired , any and all of the rights conveyed herein. ( MPL section 1.8.1.)

The CPL permits only Contributions that are original to the Contributor. Sublicensed Contributions aren't accepted. (CPL section 1.)

The OSL does not expressly prohibit the imposition of "further restrictions," nor does it deal separately with contributors. But it does contain the following warranty of provenance that has the effect of promising compatibility of licensing for all contributions incorporated into the derivative work:

Licensor warrants that the copyright in and to the Original Work and to the patent rights granted herein by Licensor are owned by the Licensor or are sublicensed to You under the terms of this License with the permission of the contributor(s) of those copyrights and patent rights. ( OSL / AFL section 7.)

A licensor promises that he or she has permission (i.e., licenses) to distribute those contributions in an Original Work under the OSL. The OSL handles the license incompatibility problem by placing on the creator of a derivative work an obligation to ensure that whatever contributions he or she accepts are authorized for inclusion in that derivative work to be licensed under the OSL.

		DERIVATIVE WORK
		GPL	MPL	CPL	OSL	Academic
CONTRIBUTION	BSD	yes	no [1]	no [2]	yes	yes [3]
	MIT	yes	no [1]	no [2]	yes	yes [3]
	Apache	yes [4]	no [1]	no [2]	yes	yes [3]
	AFL	yes [4]	no [1]	no [2]	yes	yes [3]

^[1] MPL section 2.2 is a Contributor Grant that expresses the terms under which contributions can be accepted for MPL-licensed derivative works.

^[2] CPL section 1 defines Contributor and Contribution. "Separate modules of software" are not Contributions.

^[3] The Apache Software Foundation now requires a Contributor Agreement. (See www.apache.org .) Other projects using academic licenses may also require contributor agreements or specific contribution licenses.

^[4] The Free Software Foundation says the Apache and AFL licenses are not compatible with the GPL. (See www.fsf.org .) I disagree with them, and so I wrote YES in these boxes.

The interrelationships between the contributions and derivative works are summarized in the preceding chart. But there are so many caveats in the footnotes that this chart should not be used in a mechanical fashion. Review the contributor and derivative works licenses carefully to ensure that the terms and conditions of both licenses are honored.

In summary, the creation of derivative works from contributions under academic licenses depends more on the license of the derivative work than on the terms of the academic license. Some licenses won't permit the incorporation of works licensed under an academic license regardless of what the academic license itself permits.