Advice on relicensing from the SFLC

From: "John W. Linville" <linville-AT-tuxdriver.com> To: ksummit-2007-discuss-AT-thunk.org Subject: [Ksummit-2007-discuss] SFLC: preserving non-GPL license notices in GPL project files Date: Wed, 5 Sep 2007 09:17:33 -0400 Message-ID: <20070905131733.GB3170@tuxdriver.com>

After the past week's kerfuffle w/ the BSD folks regarding the copyright notices in ath5k, the SFLC thought it was important to provide some educational outreach to the Linux kernel development community. Since I have been working with them over the past year or so on a couple of matters, they have asked me to pass-on this information. Hth! John --- PRESERVING NON-GPL LICENSE NOTICES IN GPL PROJECT FILES GUIDELINES FOR DEVELOPERS Many free software projects grant broad copyright permissions to recipients of their programs. In many cases, these permissions are broad enough to allow the code to be incorporated into larger works that are licensed under the GNU GPL. When incorporating such code into GPL'd projects, however, care must be taken to preserve all appropriate copyright, permission, and disclaimer of warranty notices. Failure to do so can result in infringement of the copyright on the incorporated code. The Software Freedom Law Center has formulated these guidelines to advise developers working on GPL'd projects on how best to incorporate code under permissive, non-GPL terms into GPL'd projects without inadvertently infringing the copyright on the added code. Why Notice Preservation Is Important While any GPL project must be distributed as a whole under the GPL, parts of it may have been contributed as independent work under terms more permissive than GPL. Preserving the permissive license text on these parts sometimes allows downstream users to separate out the independent programs and work with them under the terms of the permissive license. In addition, many of these permissive licenses explicitly require full preservation of the copyright notice, permission statement, and disclaimer of warranty. HOW TO PRESERVE NOTICES Nearly all free software licenses, including GPLv2 and GPLv3, only require that such notices appear once in an entire work (for example, in a single file at the top-level directory of the project, called COPYRIGHT). Traditionally, however, free software developers prefer to attach a notice to each each file in a project, thereby tracking authorship and copyright permissions on the individual files of large programs. This document is intended for projects that have already decided to keep a "file-by-file method" of copyright inventory for their projects rather than a "single COPYRIGHT file" method, since the former is the most common method in use today [1]. Situation 0: Including Unmodified Files With Permissive Permissions If you do not plan to modify the permissive-termed files in question, you have the the simplest case. Simply leave the files with all copyright notices and license notices intact. If you are taking them from an external project that also uses the file-by-file method, you have no work to do but to bring the files into your project and carefully read the terms to ensure they really are permissive notices that permit incorporation into GPL works. If the external project uses the COPYRIGHT file method, you should pull out the names of all the copyright holders from that file and place them, along with any permission notices, disclaimers of warranty and other such information from the COPYRIGHT file into the actual source files. In other words, you are "expanding" their single COPYRIGHT file method into your file-by-file method. This may mean a lot of copyright holders should be included, but you should always err on the side of including everyone who may have a copyright claim. When finished, your new files should look something like this: /* Copyright YEARS_LIST, Permissive Project Contributor1 <contrib1@example.net> ** Copyright YEARS_LIST, Permissive Project Contributor2 <contrib2@example.net> ** ... ** ** Permission to use, copy, modify, and/or distribute this software for ** any purpose with or without fee is hereby granted, provided that the ** above copyright notice and this permission notice appear in all copies. ** THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL ** WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED ** WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR ** BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES ** OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, ** WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ** ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS ** SOFTWARE. */ Situation 1: Including Files, Originally With Permissive Permissions, But Adding Your Own Your GPL'd Modifications Terms and notices become more complicated when you make new substantial contributions to a file you are incorporating into the GPL'd program. Any new substantial contributions at that point are typically governed by the GPL. (It may, in some cases, be possible to contribute new code under the more permissive terms of the non-GPL license, and we discuss that in Situation 2.) In this simpler case, you apply the GPL to your modifications. While the permissive nature of the other project's license allows you legally to incorporate their work into yours, you still must comply with the term that states: "the above copyright notice and this permission notice appear in all copies". Conventionally, when you begin making new modifications and you are using a file-by-file copyright inventory, you place your new copyright notice and permission notice above the existing one, and make it clear that you've modified the work. Here's an example: /* * Copyright (c) 2007 GPL Project Developer Who Made Changes <gpl@example.org> * * This file is free software: you may copy, redistribute and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation, either version 2 of the License, or (at your * option) any later version. * * This file is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. * * This file incorporates work covered by the following copyright and * permission notice: * * Copyright YEARS_LIST, Permissive Contributor1 <contrib1@example.net> * Copyright YEARS_LIST, Permissive Contributor2 <contrib2@example.net> * Permission to use, copy, modify, and/or distribute this software * for any purpose with or without fee is hereby granted, provided * that the above copyright notice and this permission notice appear * in all copies. * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL * WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE * AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ (Of course, you may remove "or (at your option) any later version" if you want to release only under GPLv2. Or, you may change the "2" to a "3" if your project is under GPLv3.) A very important issue here is the full preservation of the full copyright notice, permission notice, and disclaimer of warranty as they appeared in the original code. Some common practice has cropped up whereby the GPL notice is placed somewhere mixed in with the other more permissive notice. That practice causes confusion and lack of clarity both about the provenance of the code and the exact permissions that were granted by various copyright holders on it. When different copyright holders are releasing their software under different terms, be sure to make it clear who has given which terms. Making a clear separation and using indenting (as done in the example above) is therefore recommended. Once the notices in the file are organized this way, new authors can now make a choice about whether they wish to contribute under the more permissive terms, or the GPL. If they wish their contributions to be made available under the permissive terms, they can add their copyright notices to the lower group. If they wish to contribute under GPL, they can add their copyright notices at the top. It should be duly noted, however, that in a single file, it's extremely difficult and perhaps completely infeasible to show which parts are under the more permissive terms. If the goal is to make more code available under the permissive terms only, the method described in "Situation 2" should be employed. Situation 2: Keeping Modified Files With Permissive Permissions Inside Larger GPL'd Works Sometimes, for the sake of continued collaboration with projects that prefer more permissive terms, GPL'd project maintainers wish to section off code that will always remain under the more permissive terms. This is particularly of interest to developers who wish to allow some parts of their work to remain available to other projects under the more permissive terms. The most common example is a project that is primarily under GPL but includes some code that can be shared with a project under the very permissive ISC license (sometimes called the 2-clause BSD license). Typically, when contributions are made to a GPL'd project, they are done under the terms of the GPL. If maintainers have some files that must always remain under more permissive terms, the stewards of the codebase should take great care to obtain explicit assent from each contributor to the file in question. The contributor should indicate agreement that the changes available under the permissive terms, not GPL. Careful attention to legal detail must be made here. When working in a large GPL'd codebase, it is very easy to change the work in a way that causes the GPL to cover files previously covered only by more permissive terms. This is particularly true when cross-file patchsets are accepted from developers. GPL'd projects that try to keep some of their code under more permissive licenses should collect an email or other direct statement from each patcher of the file indicating that the patcher wishes his changes to remain under the more permissive license. Whenever possible, the stewards of the codebase should consult with a lawyer to be sure that the file is sufficiently independent from the core of the GPL'd program to constitute a separate, non-derivative work. FOOTNOTE [1] The file-by-file copyright and license notice method is steeped in 20 years of tradition in the software freedom community. However, it is in some ways ill-advised, because of the heavy burden of individual file change tracking that must be done to insure that the notices stay correct. Project leaders are generally advised to begin reconsidering this approach, as it is quite error-prone and can often lead to inadvertent (albeit typically minor) copyright infringement or improper attribution. -- John W. Linville linville@tuxdriver.com