From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6347 invoked by alias); 3 Jun 2003 17:36:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6229 invoked from network); 3 Jun 2003 17:36:37 -0000 Received: from unknown (HELO ms-smtp-01.nyroc.rr.com) (24.92.226.148) by sources.redhat.com with SMTP; 3 Jun 2003 17:36:37 -0000 Received: from doctormoo (syr-24-24-19-190.twcny.rr.com [24.24.19.190]) by ms-smtp-01.nyroc.rr.com (8.12.5/8.12.2) with ESMTP id h53HaaGm013920; Tue, 3 Jun 2003 13:36:36 -0400 (EDT) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 19NFi5-0001JJ-00; Tue, 03 Jun 2003 13:36:33 -0400 Date: Tue, 03 Jun 2003 17:36:00 -0000 To: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Libiberty licensing problems & solutions [DRAFT] Message-ID: <20030603173633.GA5038@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Nathanael Nerode X-SW-Source: 2003-06/txt/msg00032.txt.bz2 This is a draft. Comments from the libiberty-using crowd are encouraged. When this is more final, I intend to send it to the GCC Steering Committee to get approval of the various licensing changes. [THIS IS A DRAFT] Libiberty has a number of technical licensing issues which I hope to resolve. I will explain each issue and its proposed solution. Problems 3 and 4 will take a while to resolve, but I would like to get action on the other 6 problems as quickly as possible, since they should not be too difficult. PROBLEM 1. Certain files (such as argv.c) state: >This file is part of the libiberty library. >Libiberty is free software; you can redistribute it and/or >modify it under the terms of the GNU Library General Public >License as published by the Free Software Foundation; either >version 2 of the License, or (at your option) any later version. Meanwhile, certain other files (lrealpath.c) state: > This file is part of the libiberty library. > > This program is free software; you can redistribute it 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. If both are read literally, this indicates that lrealpath.c is part of the libiberty library, and libiberty is under the LGPL, so lrealpath.c is under the LGPL. This is almost certainly not what is intended. Libiberty is not generally used as a single library under a single licence. It is a collection of routines designed to be used independently, and different routines are under different licenses. Accordingly, stating "Libiberty is free software; you can redistribute it and/or modify it under the terms of " is a bad idea, since this will rarely be true for all the files in libiberty. SOLUTION FOR PROBLEM 1. All files in libiberty should use the following form for their license text: >This file is free software; you can redistribute it and/or >modify it under the terms of ... By using the "This file" form, we uniformly avoid confusion. Additionally, a note should be included in the libiberty README (or somewhere similar) indicating that all of libiberty is free software, but individual files are under different licenses. ALTERNATE SOLUTION FOR PROBLEM 1. Relicense all of libiberty under one license. (The license would have to be LGPL with linking exception, since LGPL is required by some users and the linking exception is required by some users.) It seems very unlikely that this will happen. PROBLEM 2. Files in libiberty are confused about what they're part of. Some (argv.c) say: >This file is part of the libiberty library. Some (regex.c) say: >This file is part of the GNU C library. Some (floatformat.c) say: >This file is part of GDB. Some (sort.c) say: >This file is part of GNU CC. And there are yet more forms. All these files are, in fact, part of libiberty, of course. The following point has been raised regarding this. Many people have open-ended copyright assignments to the FSF for specific projects. Editing files not in those specific projects is outside the scope of their copyright assignments. Libiberty is in an interesting position because it is part of several projects at once. I propose that this situation be clarified. PROPOSED SOLUTION FOR PROBLEM 2. Contributions to libiberty should require a GCC assignment, since the 'master copy' is in the GCC repository and it seems to be worked on most often by GCC people. So each file in libiberty should say: >This file is part of the libiberty library, which is part of GCC. ALTERNATE SOLUTION A FOR PROBLEM 2. Each file in libiberty should say: >This file is part of GCC. ALTERNATE SOLUTION B FOR PROBLEM 2. Libiberty should require its own copyright assignments, separate from GCC, GDB, etc. Each file in libiberty should say: >This file is part of the libiberty library. PROBLEM 3. Assuming problem 2 is resolved, the issue of past contributions remains. Any file which was simply 'imported' from another GNU project is fine. Files which were edited as part of libiberty need to be audited to make sure that the contributions were covered by appropriate copyright assignments at the time. This raises the question of which project certain files were part of in the past; for instance, floatformat.c, while in the libiberty directory, but claiming to be part of GDB. This is mostly a matter of grunt work following the resolution of problem 2, however; I'll be happy to do it. PROBLEM 4. The following files have no explicit copyright notice or license (and are not autogenerated). ChangeLog README aclocal.m4 bcopy.c config.table configure.in copysign.c ffs.c fnmatch.txh getpagesize.c getpwd.c makefile.vms memchr.c mpw-make.sed (probably obsolete?) obstacks.texi pexecute.txh strdup.c tmpnam.c vmsbuild.com vprintf.c waitpid.c I can make an effort to track down their origins and see who needs to be asked about these. I'd like to get rid of any unneeded or obsolete files first, howver, to save time and effort. I would assume that they were under the terms of the "rest of libiberty", except that it's unclear exactly what that is. :-) This is highly parallelizable work. (Everyone pick a file...) PROBLEM 5. The following file is listed as copyright FSF, with no license: vfprintf.c SOLUTION TO PROBLEM 5. The FSF should relicense this, in the form I advise earlier: >This file is free software; you can redistribute it and/or >modify it under the terms of ... DJ recommends GPL with linking exception. PROBLEM 6. The following file is University of California copyright, with no license: xatexit.c SOLUTION TO PROBLEM 6. Replace with a clearly licensed free version from one of the BSDs. PROBLEM 7. The following two files have an unusual, short form of the BSD license, with no explicit modifiction permission: strcasecmp.c strncasecmp.c SOLUTION TO PROBLEM 7. Replace with clearly licensed free versions from one of the BSDs. PROBLEM 8. The following FSF-copyrighted files don't actually assert licences for themselves, due to confusion over what project they're part of: mkstemps.c putenv.c setenv.c make-relative-prefix.c SOLUTION TO PROBLEM 8. The FSF should license these using the form that I recommend above: >This file is free software; you can redistribute it and/or >modify it under the terms of ... (Leave the actual license choices as before.) [THIS IS A DRAFT]