Re: Libiberty licensing problems & solutions [DRAFT]

Re: Libiberty licensing problems & solutions [DRAFT]

[Nathanael Nerode]

Joseph Myers said:
>Apart from this, libiberty manual licensing is a mess in other ways

I'm not touching the manual licensing at the moment.  I'm opposed to the 
GFDL, particularly with "Invariant Sections", and so I'm not going to do 
anything to help it.

I may request that the manual be relicensed at some point, but I'm 
trying to separate that from the hopefully non-controversial 
relicensings I'm discussing in my draft letter.

--Nathanael

Re: Libiberty licensing problems & solutions [DRAFT]

[Eli Zaretskii]

> Date: Tue, 3 Jun 2003 15:32:58 -0400
> From: Nathanael Nerode <neroden@twcny.rr.com>
> 
> I'm opposed to the GFDL, particularly with "Invariant Sections"

Can you tell why?

Re: Libiberty licensing problems & solutions [DRAFT]

[Kelley Cook]

>> Date: Tue, 3 Jun 2003 15:32:58 -0400
>> From: Nathanael Nerode <neroden@twcny.rr.com>
>> 
>> I'm opposed to the GFDL, particularly with "Invariant Sections"
> 
> Can you tell why?

Please do not continue this subthread on the gdb, gcc, or binutils lists 
as is it is not on-topic.

A lively discussion on this topic which does include RMS, has been going 
on the Debian-Legal ListServ (http://lists.debian.org/debian-legal/) for 
months now.

Feel free to peruse their mail archive or Google for "Debian GFDL" for 
details on the debate.

I am speaking purely an outsider.  If anyone thinks that I shouldn't 
have said this, please email me directly.

Kelley Cook

BTW, Sorry about the duplicate message.

<20030603193258.GA32189@doctormoo> <7458-Wed04Jun2003062758+0300-eliz@elta.co.il>

[Kelley Cook]

>> Date: Tue, 3 Jun 2003 15:32:58 -0400
>> From: Nathanael Nerode <neroden@twcny.rr.com>
>> 
>> I'm opposed to the GFDL, particularly with "Invariant Sections"
> 
> Can you tell why?

Please do not continue this subthread on the gdb, gcc, or binutils lists as is it is not on-topic.

A lively discussion on this topic which does include RMS, has been going on the Debian-Legal ListServ (http://lists.debian.org/debian-legal/) for months now.  

Feel free to peruse their mail archive or Google for "Debian GFDL" for details on the debate.

I am speaking purely an outsider.  If anyone thinks that I shouldn't have said this, please email me directly.

Kelley Cook

Re: Libiberty licensing problems & solutions [DRAFT]

[David Carlton]

On Wed, 04 Jun 2003 09:43:32 -0400, Kelley Cook <kcook34@ford.com> said:

>>> Date: Tue, 3 Jun 2003 15:32:58 -0400
>>> From: Nathanael Nerode <neroden@twcny.rr.com>

>>> I'm opposed to the GFDL, particularly with "Invariant Sections"

>> Can you tell why?

> Please do not continue this subthread on the gdb, gcc, or binutils
> lists as is it is not on-topic.

> A lively discussion on this topic which does include RMS, has been
> going on the Debian-Legal ListServ
> (http://lists.debian.org/debian-legal/) for months now.

Thanks for the reference; interesting.  I'm not at all impressed by
the FSF's behavior in this instance. :-(  Of course, it's not like
I've been contributing much to GDB's manual in the first place...

David Carlton
carlton@math.stanford.edu

Re: Libiberty licensing problems & solutions [DRAFT]

[Mike Stump]

On Tuesday, June 3, 2003, at 08:27 PM, Eli Zaretskii wrote:
>> Date: Tue, 3 Jun 2003 15:32:58 -0400
>> From: Nathanael Nerode <neroden@twcny.rr.com>
>>
>> I'm opposed to the GFDL, particularly with "Invariant Sections"
>
> Can you tell why?

It removes a freedom, the freedom to create arbitrary modifications of 
the source for distribution.  This is one of the central concepts of 
free software.

This topic is more appropriate for gnu.misc.discuss.

Re: Libiberty licensing problems & solutions [DRAFT]

[David Carlton]

On 04 Jun 2003 10:25:27 -0700, David Carlton <carlton@math.stanford.edu> said:

> Thanks for the reference; interesting.  I'm not at all impressed by
> the FSF's behavior in this instance. :-(  Of course, it's not like
> I've been contributing much to GDB's manual in the first place...

And, for that matter, I have no idea if the one contribution to the
manual that I made is valid.  I don't have a copy of the assignment
that I initially signed at hand, but more recent assigments that I
have around say things like:

+   The Released Category comprises

+ (a) changes and enhancements to software already (as of the time such
+ change or enhancement is made) freely circulating under stated terms
+ permitting public redistribution, whether in the public domain, or
+ under the FSF's GNU General Public License, or under the FSF's GNU
+ Lesser General Public License (a.k.a. the GNU Library General Public
+ License), or under other such terms; and

Documentation isn't software, and even if it were, the GFDL isn't
mentioned explicitly, and I personally wouldn't consider the GFDL to
be "other such terms" (e.g. it's not GPL-compatible).  So if that's
supposed to cover changes to manuals licensed under the GFDL, then it
seems to me that, at the very least, the FSF should make that more
explicit.

Sigh.

David Carlton
carlton@math.stanford.edu

Re: Libiberty licensing problems & solutions [DRAFT]

[Joseph S. Myers]

On Tue, 3 Jun 2003, Nathanael Nerode wrote:

> PROBLEM 4.
> The following files have no explicit copyright notice or license (and
> are not autogenerated).
> 
>   ChangeLog
>   README

These are straightforward.  <http://www.gnu.org/prep/maintain_9.html>
says:

=========================================================================
   Small supporting files, short manuals (under 300 lines long) and rough
   documentation (README files, INSTALL files, etc) can use a simple
   all-permissive license like this one:

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.
=========================================================================

Put a copyright notice and that licence notice in the files (at the bottom
in the case of ChangeLog files; see
<http://www.gnu.org/prep/maintain_8.html>).  The main work is determining
the copyright dates.  It would be a good idea to do all the ChangeLog
files in GCC at once - for a ChangeLog file you can simply take the dates
of the entries in the file to determine the copyright dates, since
subsequent spelling corrections etc. are unlikely to be significant for
copyright.

>   obstacks.texi

libiberty.texi has a comment:

@c This is generated from the glibc manual using a make-obstacks-texi.sh
@c script of Phil's.  Hope it's accurate.
@include obstacks.texi

I.e., GFDL.  This is a mess to sort out because of Cover Texts and 
Invariant Sections.  The glibc manual has some, the libiberty manual 
doesn't although from <http://www.gnu.org/licenses/fdl-howto.html> it is 
clear that actually the section containing the LGPL must be invariant 
since it isn't modifiable (and the GFDL lacks unmodifiable removable 
sections).

Apart from this, libiberty manual licensing is a mess in other ways.  The
copyright date of 2001 (only) is probably wrong; it ought to use @copying
for the copying information, as is it doesn't get in the HTML manual; a
paragraph about passing through TeX that should only have been part of the
old GNU manual licence is still present; and it claims to include a copy
of the GFDL, but doesn't, though it should (but being shared by multiple
projects it can't use the common fdl.texi file otherwise used by GCC
manuals).  The manual date and edition, referring to a particular GCC
version, should probably also be removed.

[I didn't include the libiberty and fastjar manuals in the conversion of
GCC manuals to use @copying, because of the lack at the time of a toplevel
makeinfo version check.  We now have a toplevel requirement for texinfo
4.2 or later, so those manuals can be converted.]

And since the manual contains text extracted from comments, the dual
licensing of those comments needs blessing by the FSF.

All licensing fixes should also go on the GCC 3.3 branch so that it is
clear under what terms releases can be distributed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Libiberty licensing problems & solutions [DRAFT]

[Nathanael Nerode]

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]