Re: Libiberty license roundup (questions/potential problems)

Re: Libiberty license roundup (questions/potential problems)

[Robert Dewar]

> Ah, so libiberty is always statically linked, and only individual .o 
> files are linked with any particular program, so source files under 
> different licenses aren't unmanagably comingled?  We should add a note 
> somewhere to the effect that it has to remain this way. :-)

A little note here is that GNAT contains built in mechanisms (and an explicit
pragma License) to ensure against invalid mixing of licenses. This is activated
by default by the -gnatg switch used to compile GNAT sources. We have found it
quite useful in avoiding any mistakes (in particular, a file with the exception
clause is not allowed to WITH a file without the clause.

Re: Libiberty license roundup (questions/potential problems)

[Robert Dewar]

> The only reason for using something other than the GPL is if a function
> turns out to be needed in a language support library as well.  Otherwise
> it suffices if the license is GPL or GPL-compatible.


Well of course I understand the abstract principle here, the issue is how
does it apply in this case.

Re: Libiberty license roundup (questions/potential problems)

[Robert Dewar]

I have not seen any substantive argument for using other than the GPL here.
That's what would be useful.

Re: Libiberty license roundup (questions/potential problems)

[Joe Buck]

On Wed, May 28, 2003 at 06:11:27PM -0400, Robert Dewar wrote:
> I have not seen any substantive argument for using other than the GPL here.
> That's what would be useful.

The only reason for using something other than the GPL is if a function
turns out to be needed in a language support library as well.  Otherwise
it suffices if the license is GPL or GPL-compatible.

Re: Libiberty license roundup (questions/potential problems)

[Nathanael Nerode]

I wrote a longer message about this, but then lost it.  :-)

The following is a problem.  Some files say "This file is part of the 
libiberty library.  This library... under the terms of the GNU General 
Public License..."

Others say "This file is part of the libiberty library.  Libiberty... 
under the terms of the GNU Library General Public License..."

If "this library" is read to mean "the libiberty library", then one file 
says "libiberty can be used under the LGPL", while a GPLed file says 
"I'm part of libiberty".  This isn't so good.

I therefore suggest the "This file" or "This program" form of 
boilerplate for all files in libiberty to make the separate licenses quite
clear and distinct.  The line "This file is part of the libiberty 
library" is fine, provided the rest of the lines state 
specifically that they apply only to 'this file', not to the whole of 
'the libiberty library'.

Alternatively, "libiberty" could be properly restricted to files with a 
certain licence (or licenses which can be 'converted' to that one); 
those files could say "Libiberty is..." while the others (pure GPL, 
for instance) would say "This file is..." or  "This file is part of GCC.  
GCC is..." or some such.  But that's more confusing.  :-)

--Nathanael

Re: Libiberty license roundup (questions/potential problems)

[Nathanael Nerode]

DJ said:
>> The fourth are the various files which aren't sure what they're part
>> of; I'd like permission to just fix those all to claim to be part of
>> libiberty, unless there's some reason not to.
>
>The reason is, only the original author can change the copyright terms.

Ah, but this part isn't really part of the copyright terms!

"This file is part of GNU CC.  GNU CC is... ...GNU CC... ...GNU CC..."
can be replaced with
"This program is... ..this program... ...this program..."

without affecting license terms or copyright terms at all, provided it's 
kept consistent.

Here I'm talking about keeping the file under the same license and 
copyright (most of the relevant ones are FSF copyright), but correcting 
the text so they don't claim to be part of various other projects (which 
they obviously aren't, at this point).  I'd be happy if they all said 
simply "This program", or all said "part of gcc", or all said "part of 
libiberty", or even a mix of those three; I'm just trying to root out 
inaccuracy.

I'm most worried about the one which doesn't technically have a license 
for itself ("This file is part of libiberty.  GCC is free software...")
and I'm hoping to avoid this kind of mishmash in the future.

>Some have the exception because they're used in libstdc++, for
>example.  There is no "library as a whole" as far as libiberty is
>concerned; each source file has its own license, and that's pretty
>much the end of the story, since there's little we can do about it.

Ah, so libiberty is always statically linked, and only individual .o 
files are linked with any particular program, so source files under 
different licenses aren't unmanagably comingled?  We should add a note 
somewhere to the effect that it has to remain this way. :-)

--Nathanael

Re: Libiberty license roundup (questions/potential problems)

[DJ Delorie]

> >The reason is, only the original author can change the copyright terms.
> 
> Ah, but this part isn't really part of the copyright terms!

Changing the package that a file belongs to changes the type of
copyright assignment you need to have in order to edit that file.

> I'm most worried about the one which doesn't technically have a
> license for itself ("This file is part of libiberty.  GCC is free
> software...")  and I'm hoping to avoid this kind of mishmash in the
> future.

Those still have authors and copyrights, though.

> Ah, so libiberty is always statically linked, and only individual .o 
> files are linked with any particular program, so source files under 
> different licenses aren't unmanagably comingled?  We should add a note 
> somewhere to the effect that it has to remain this way. :-)

No, not at all.  Parts are linked into libstdc++.so.  Parts are linked
into libbfd.so.  That's why we have such a mess; some files have had
license changes in order to be able to do that, but others haven't.

Libiberty license roundup (questions/potential problems)

[Nathanael Nerode]

Looking at libiberty, it seems to be under a mass of different licences.

There are several problems here.  The first are the (non-autogenerated) files
with no explicit copyright notice or licence.  I would assume that they were
under the terms of the "rest of libiberty", except that it's not clear
what that is.

The second are the two files with copyright and no license listed.

The third are the BSD files with no explicit modification permission.

The fourth are the various files which aren't sure what they're part of; I'd
like permission to just fix those all to claim to be part of libiberty, unless
there's some reason not to.

The fifth is the question of why some are LGPL, some are GPL, some are GPL
with linking exception, and one is LGPL with linking exception.  Effectively
the library as a whole is under GPL in general, it would seem; what purpose
do the other licenses serve?

* Verbatim only
  COPYING.LIB (copy of LGPL 2.1)
  copying-lib.texi (copy of LGPL 2.1)

* GNU FDL 1.2 or later (with TeX permission)
  libiberty.texi

* No license or copyright on individual file
  ChangeLog
  README
  aclocal.m4
  bcopy.c
  config.in (autogenerated)
  config.table
  configure.in
  copysign.c
  ffs.c
  fnmatch.txh
  functions.texi (autogenerated)
  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

* No license, FSF copyright
  vfprintf.c

* No license, University of California copyright
  xatexit.c

* LGPL 2 or later
  (as part of "libiberty library")
  Makefile.in
  argv.c
  asprintf.c
  choose-temp.c
  concat.c
  fdmatch.c
  gather-docs
  getruntime.c
  hashtab.c
  hex.c 
  lbasename.c
  maint-tool
  make-temp-file.c
  mempcpy.c
  mpw.c
  pex-common.h
  pex-djgpp.c
  pex-mpw.c
  pex-msdos.c
  pex-os2.c
  pex-unix.c
  pex-win32.c
  safe-ctype.c
  spaces.c
  stpncpy.c
  vasprintf.c
  xexit.c
  xmalloc.c

  (as part of the "GNU C Library")
  regex.c

  (Boilerplate is for "GNU C Library is free software...", but up top says
  "based on ... in the GNU C Library", not "This file is part of...",
  so a little confused.)
  mkstemps.c
  putenv.c
  setenv.c

* GPL 2 or later 
  (as "this program")
  _doprnt.c
  fnmatch.c
  getopt.c
  getopt1.c
  md5.c
  objalloc.c
  obstack.c
  physmem.c
  ternary.c

  (as part of "GNU CC")
  fibheap.c
  partition.c
  sort.c
  splay-tree.c

  (as part of GDB)
  floatformat.c

  (as part of "libiberty library")
  lrealpath.c

  (as part of "libiberty library", but confused.  Says "You should have
  received a copy of the GNU General Public License along with GNU CC"...)
  strtod.c

  (This one's messed up.  It says "This file is part of libiberty.
  GCC is free software...")
  make-relative-prefix.c

* GPL 2 or later, with special linking exception
  (as part of "libiberty library")
  clock.c
  snprintf.c
  vsnprintf.c
  vsprintf.c

  (as part of "GNU CC")
  cp-demangle.c
  dyn-string.c

* LGPL 2 or later, with special linking exception (!)
  (as part of "libiberty library")
  cplus-dem.c

* public domain
  alloca.c
  atexit.c
  basename.c
  bcmp.c
  bzero.c
  calloc.c
  getcwd.c
  insque.c
  memcmp.c
  memcpy.c
  memmove.c
  memset.c
  rename.c
  sigsetmask.c
  strchr.c
  strerror.c
  strncmp.c
  strrchr.c
  strsignal.c
  strstr.c
  vfork.c
  xmemdup.c
  xstrdup.c
  xstrerror.c

* BSD (U of C)
  (usual long version of BSD license)
  bsearch.c
  random.c
  strtol.c
  strtoul.c

  (unusual, shorter version of the license, missing the "with
    or without modification" clause)
  strcasecmp.c  
  strncasecmp.c

Re: Libiberty license roundup (questions/potential problems)

[DJ Delorie]

> Looking at libiberty, it seems to be under a mass of different
> licences.

Yup.  It will probably stay that way, too, because changing copyright
terms is *very* difficult.

> The fourth are the various files which aren't sure what they're part
> of; I'd like permission to just fix those all to claim to be part of
> libiberty, unless there's some reason not to.

The reason is, only the original author can change the copyright terms.

> The fifth is the question of why some are LGPL, some are GPL, some
> are GPL with linking exception, and one is LGPL with linking
> exception.  Effectively the library as a whole is under GPL in
> general, it would seem; what purpose do the other licenses serve?

Some have the exception because they're used in libstdc++, for
example.  There is no "library as a whole" as far as libiberty is
concerned; each source file has its own license, and that's pretty
much the end of the story, since there's little we can do about it.

Re: Libiberty license roundup (questions/potential problems)

[Mike Stump]

On Friday, May 23, 2003, at 03:59 PM, Nathanael Nerode wrote:
> Looking at libiberty, it seems to be under a mass of different 
> licences.

Yup.

> There are several problems here.  The first are the 
> (non-autogenerated) files
> with no explicit copyright notice or licence.  I would assume that 
> they were
> under the terms of the "rest of libiberty", except that it's not clear
> what that is.

Someone would need to go back to the Cygnus devo tree and find out who 
and when they were checked in originally, and what files around that 
time the person was checking in and what status those files had.  Steve 
checked in some of the files, and wrote some, quite a bit of those were 
PD.  He also lifted some from BSD land.

In general, we should split the source internally into two, those that 
are BSD/PD/GPL with libgcc exception, and another directory with 
LGPL/GPL code.  I think that we should have two libraries, one for each 
of these directory hierarchies.

Clarifying the result of this research into explicit terms in the files 
I think would be good.

Clarifying that the files are part of libiberty I think would be good.

> * No license, University of California copyright
>   xatexit.c

I think this is supposed to be under a BSD style copyright.

> * No license, FSF copyright
>   vfprintf.c

This was written by us for us.  I think it should be GPL with exception.


Another way to clean it up, would be to check FreeBSD/NetBSD for 
corresponding versions of the routines, and replace the one in 
libiberty.

Re: Libiberty license roundup (questions/potential problems)

[Andrew Cagney]

> * No license, FSF copyright
>   vfprintf.c
> 
> This was written by us for us.  I think it should be GPL with exception.

GPL.

Andrew

Re: Libiberty license roundup (questions/potential problems)

[DJ Delorie]

> > * No license, FSF copyright
> >   vfprintf.c
> > 
> > This was written by us for us.  I think it should be GPL with exception.
> 
> GPL.

We've already had a few cases where we've had to convert GPL to GPL
with exception.  It might be prudent of us to, if we're fiddling with
copyrights anyway, to start with GPL+e this time.  Especially with the
trivial functions, where there is little to be gained by enforcing the
GPL and a lot to be gained by making it easy for people to justify
using GNU software.

Re: Libiberty license roundup (questions/potential problems)

[Andrew Cagney]

>> > * No license, FSF copyright
>> >   vfprintf.c
>> > 
>> > This was written by us for us.  I think it should be GPL with exception.
> 
>> 
>> GPL.
> 
> 
> We've already had a few cases where we've had to convert GPL to GPL
> with exception.  It might be prudent of us to, if we're fiddling with
> copyrights anyway, to start with GPL+e this time.  Especially with the
> trivial functions, where there is little to be gained by enforcing the
> GPL and a lot to be gained by making it easy for people to justify
> using GNU software.

It is always easier to weaken a license.  I think it is easierr to start 
with something safe.

Andrew

Re: Libiberty license roundup (questions/potential problems)

[Joe Buck]

On Wed, May 28, 2003 at 03:27:10PM -0400, Andrew Cagney wrote:
> It is always easier to weaken a license.  I think it is easierr to start 
> with something safe.

Unless you have to ask RMS to weaken the license; he sometimes thinks about
it for months.  Better to get the license right the first time.

Re: Libiberty license roundup (questions/potential problems)

[David O'Brien]

On Fri, May 23, 2003 at 06:59:05PM -0400, Nathanael Nerode wrote:
> The third are the BSD files with no explicit modification permission.
...
>   (unusual, shorter version of the license, missing the "with
>     or without modification" clause)
>   strcasecmp.c  
>   strncasecmp.c

I can pull updated versions of these out of the BSD SCCS repo that has
more explicit copyrights.

-- 
-- David  (obrien@FreeBSD.org)

Re: Libiberty license roundup (questions/potential problems)

[DJ Delorie]

> >   strcasecmp.c  
> >   strncasecmp.c
> 
> I can pull updated versions of these out of the BSD SCCS repo that has
> more explicit copyrights.

Could you post a patch?  Just in case something else changed, too.