Advice on relicensing from the SFLC

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