Libiberty licensing problems & solutions [DRAFT]

Nathanael Nerode
2003-06-03T17:36:38Z

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 <SPECIFIC LICENSE>" 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 <WHATEVER>...

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 <WHATEVER>...

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 <WHATEVER>...

(Leave the actual license choices as before.)

[THIS IS A DRAFT]