In writing code, a programmer may find that he wants to fuse elements from two or more programs into a new program. The two programs are under different licenses. The question arises: is it possible to take this code, under different licenses, and combine them in one work without violating the terms of either of the two licenses?
Warning
While two licenses may appear to be compatible, programmers must ensure that they are, in fact, compatible. Apparently innocuous terms in one or both licenses may make them incompatible with each other. Distribution or modification of programs, including incompatibly licensed code, will result in copyright infringement.
Those undertaking this analysis should note that with some exceptions (such as the GPL and the SCSL Licenses) the licenses described in this book are frequently templates for individual licenses, and their language may not be exactly the same as that described here. Simply because something is described as a "BSD-style" license, for example, does not mean that it is written just like the BSD License or contains exactly the same terms. In every case, a user considering combining works licensed under different licenses should read the licenses at issue very carefully.
It is much easier to describe those licenses that are incompatible than to assert with any assurance that two licenses are compatible. There are several scenarios in which the answers are obvious. If either one of the works is licensed under a proprietary license, the code cannot be combined with work under another license (except through cross-licensing, described later). As a general matter, under a classic proprietary license, the user has no rights to the work other than to use a single copy of it. Ordinarily, she may not even examine the code, much less modify or distribute part of it as a section of another work. Two works under proprietary licenses, even if they are the same license, cannot be modified or distributed together without violating the license(s).
Another example susceptible to quick analysis is the GPL License. GPL-licensed code is incompatible with code licensed under most licenses. As noted in Chapter 3, the second sentence of Section 6 of the GPL reads as follows:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
By combining GPL-licensed code with code under any but the most unrestrictive licenses, the creator of the putative "new program" is imposing a restriction (compliance with the terms of that license) that is not present in the GPL License and which accordingly violates the GPL. (The LGPL is not restrictive but is compatible with the GPL by design.) As noted previously in this chapter, one of the fundamental building blocks of any contract—and all licenses are a form of a contract—is consideration, i.e., the imposition of some obligation on each party. In the open source and free software licenses discussed in this book, the typical transaction involves the licensor agreeing (becoming obligated) to permit certain uses of the licensed work in exchange for the licensee agreeing and becoming obligated to comply with certain restrictions. Accordingly, any license worthy of the name will impose some obligation: if that obligation does not precisely parallel an obligation in the GPL, that obligation is a "further restriction" as far as the GPL is concerned and cannot be imposed on licensees of the GPL code.[8]
This brings us to another realm of quick analysis. Some works are not subject to any license at all. Their creator has either consigned them to the public domain—for example, by attaching a Public Domain Dedication to the work, as described in Chapter 4—or the work has lost its copyright protection and entered the public domain by the lapse of time.[9] Because such public domain works impose no obligations on their users, code that is in the public domain may be combined with code licensed under any license, so long as that license's terms are complied with. Accordingly, a programmer may incorporate public domain code with GPL licensed code, and modify and distribute the resulting work without fear, so long as he complies with the GPL.
After these three straightforward examples, the question of the mutual compatibility of licenses becomes substantially more complicated. In the following situations, programmers (or preferably their attorneys) should examine each of the applicable licenses cautiously.
In general, the "research style" licenses described in Chapter 2 are compatible with each other. Accordingly, a program licensed under the BSD License may be combined with a program licensed under the MIT License, and both released under the licensee's proprietary license so long as each license's restrictions are complied with. In this example, the BSD License would require that its list of conditions be included in the software distribution and that all advertising materials note that the software includes work made by the University of California at Berkeley; the MIT License would require that its copyright and permission notices be distributed with the resulting software, and the proprietary license governing the combined work would contain whatever additional restriction that licensee chose to impose.
" Research style" licenses are also generally compatible with licenses that do not bar the imposition of additional restrictions on the code to be licensed. For example, the Q Public License permits the distribution of modified forms of the licensed work in the form of the original work plus patches. If a user wishes to draw code for a patch from an MIT-licensed program, he is free to do so and to distribute that patch in a manner consistent with both licenses, so long as he complies with the other terms of the Q Public License and encloses the permission and copyright notices required by the MIT License.
Beyond these general observations, it is difficult, if not impossible, to provide precise guidance about what licenses may or may not be compatible with each other. As already noted, many licenses described in this book are really templates and are subject to significant variations in their terms in practice. Programmers who are considering combining code governed by two or more different licenses should proceed cautiously.
Fortunately, there is another solution, generally available, which is both easier and more reliable than comparing the arcane terms of two separate licenses. This is the phenomenon of cross-licensing.
As the creator of a work, the original licensor retains all of the rights associated with that copyright, subject only to the sale or licensing of those rights to others. The open source and free software licenses described in this book do not require that the creator of a work surrender all of his rights to another. Rather, in each case, the license reflects only a specific, one-time, grant of certain specified rights based on the compliance of the licensee with specified conditions. The licensor does not agree only to license the work under those terms or to those licensees.
Accordingly, such a licensor retains the power and the discretion to license his work under terms other than those contained in the original license. This is cross-licensing. ABC Corp. licenses its program, Mudd, under the pre-1999 BSD License. Several years later, John Smith wishes to incorporate some of the Mudd code into his ongoing free software project, the GPL-licensed Pond, which is based on code from an earlier GPL-licensed program, River, created by Audrey Strauss. Smith understands that the GPL and the pre-1999 BSD Licenses are incompatible. He can resolve this dilemma if either ABC or Strauss is willing to cross-license their programs—i.e., make the program (or a version of it) available under a license other than that which the program was originally provided under. In this case, Smith could go to ABC and ask them to license a version of Mudd under a GPL License so that he can use it in a GPL licensed new version of Pond. Smith could also go to Strauss and ask her to license a version of her River program under the pre-1999 BSD (or other compatible) license so that he can incorporate it in a BSD licensed version of Pond.
While it may seem somewhat presumptious to approach an author of a work, who likely has given at least some thought to the license applicable to the work, to reconsider that decision, open source and software programmers are generally open to the idea of cross-licensing. Given the ethic in the open source and free software communities to favor free distribution of work and to avoid duplication of effort, most programmers would be inclined to give such requests a favorable hearing, at the very least. This possibility is explicitly laid out in some licenses, including the GPL. Section 10 of the GPL, for example, provides as follows:
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
If this option succeeds, all the difficulties and potential uncertainty associated with different licenses pass away. Whatever license is mutually agreeable to everyone involved will control and the coding can go on without fear of future legal problems. Some open source groups will not cross-license works copyrighted by them. The Apache Software Foundation, for example, does not cross-license its works.
There are also some situations in which cross-licensing is simply not a practical alternative. Some project structures, such as the "bazaar" structure described in the next chapter, permit input into projects by hundreds and possibly thousands of programmers. The Linux (or GNU/Linux) operating system is the quintessential example. Linux is licensed under the GPL and includes the works of thousands of people who made contributions to the project with the belief (assuming that they took the time to develop one) that the resulting work would be licensed under the GPL. In such cases, there is no one person capable of relicensing the work of all these people under a different license, not even Linus Torvalds. Because of the rigidity of the monopoly granted by copyright laws, each one of those contributors could argue, legally, that their contribution can only be used in ways consistent with the terms upon which they agreed to participate in the project. Cross-licensing such projects, while not impossible, is impractical in all but the most unusual situations.
Most open source and free software projects, however, do not present such logistical difficulties. They are maintained by a small number of people, frequently just one person, whose permission to distribute that work under another license can often be gained for no more than the cost of asking.
[8] The LGPL operates in exactly the same way, excluding, obviously, the less restrictive limitations imposed on "hitchhiker" programs that use, and may be distributed with, the LGPL-licensed library.
Get Understanding Open Source and Free Software Licensing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
