Re: [Bug-gnulib] missing licenses in gnulib

[Robert Millan]

On Thu, Oct 07, 2004 at 02:57:45PM +0200, Bruno Haible wrote:
 
 I don't want it to give it away in public domain; instead I've added
 the GPL copyright notice to [lbrkprop.h] now.

Thanks!  With this and the other commits Paul did, most of my concerns are
solved (all of those that affected the lib directory, in particular).

Did you reach a consensus in how to deal with the lack of license in m4 and
modules directories?

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: [Bug-gnulib] missing licenses in gnulib

[Bruno Haible]

Robert Millan asks:
 Did you reach a consensus in how to deal with the lack of license in m4
 and modules directories?

Under modules/ I put a copyright notice.

For m4/* these is still no consensus: Paul Eggert wants GPL for them, whereas
I favour a GPL with autoconf-like exception clause license...

Bruno

Re: [Bug-gnulib] missing licenses in gnulib

[Robert Millan]

On Wed, Oct 13, 2004 at 08:52:17PM +0200, Bruno Haible wrote:
 Robert Millan asks:
  Did you reach a consensus in how to deal with the lack of license in m4
  and modules directories?
 
 Under modules/ I put a copyright notice.

great!

 For m4/* these is still no consensus: Paul Eggert wants GPL for them, whereas
 I favour a GPL with autoconf-like exception clause license...

I think it makes more sense to actualy add a minimal license first and then
discuss whether a less restrictive one would be better.  Currently it has no
license so it's just illegal to do anything with these files.  OTOH, if you
set them to GPL you can always change it to be less restrictive (as long as
you or the FSF owns the copyright, that is).

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: [Bug-gnulib] missing licenses in gnulib

[Robert Millan]

On Wed, Oct 13, 2004 at 09:16:08PM +0200, Robert Millan wrote:
 On Wed, Oct 13, 2004 at 08:52:17PM +0200, Bruno Haible wrote:
  Robert Millan asks:
   Did you reach a consensus in how to deal with the lack of license in m4
   and modules directories?
  
  Under modules/ I put a copyright notice.
 
 great!

Uhm.  Now that I look at it, doesn't the notice in modules/README contradict
the modules files themselves which contain a license tag indicating GPL/LGPL?
(I verified each of them does that).

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: [Bug-gnulib] missing licenses in gnulib

[Bruno Haible]

Paul Eggert wrote:
 The program that generates lbrkprop.h is GPL'ed, but none of this
 GPL'ed code survives in lbrkprop.h.  lbrkprop.h merely consists of a
 small wrapper (about 15 lines of simple code, which are unprotectible
 by copyright in my opinion) followed by data which are automatically
 derived from the Unicode Data Files.

I disagree. The struct definition, although only 7 lines in size, is
tricky and certainly copyrightable.

 Since pure data are not protected by copyright, and since the wrapper
 is so small as to be uncopyrightable, I think the entire file is in
 the public domain.

I don't want it to give it away in public domain; instead I've added
the GPL copyright notice to it now. Since the module description says
LGPL, it effectively means the file is under LGPL.

 For example, Bison is
 GPLed, but Bison puts a copyright notice (the GPL with a special
 exception) into the source-code files that it generates automatically.
 Users are of course free to modify Bison to emit a different license,
 but if they redistribute the resulting output in violation of the
 Bison terms, they are still in violation of Bison's license.

Why would this be a violation of Bison's license? Because the bison
output contains a significant portion of bison code (not just data
generated from the input files and the DFA)?

Bruno

Re: [Bug-gnulib] missing licenses in gnulib

[Paul Eggert]

Bruno Haible [EMAIL PROTECTED] writes:

 I don't want it to give it away in public domain; instead I've added
 the GPL copyright notice to it now. Since the module description says
 LGPL, it effectively means the file is under LGPL.

Thanks.  That sounds quite reasonable to me.  (Like I said, my opinion
was just a layman's one, and it's clearly a judgment call.)

 Bison is GPLed, but Bison puts a copyright notice (the GPL with a
 special exception) into the source-code files that it generates
 automatically.  Users are of course free to modify Bison to emit a
 different license, but if they redistribute the resulting output in
 violation of the Bison terms, they are still in violation of
 Bison's license.

 Why would this be a violation of Bison's license? Because the bison
 output contains a significant portion of bison code (not just data
 generated from the input files and the DFA)?

Yes, that's it.  Bison's output contains a significant chunk of Bison
code -- about 1300 lines in the traditional case of an LALR(1) parser
written in C -- that are clearly copyrightable.

Re: [Bug-gnulib] missing licenses in gnulib / m4

[Paul Eggert]

Bruno Haible [EMAIL PROTECTED] writes:

 But since *.m4 files are often copied from one module to another,

Isn't this much like saying source code is often copied from one *.c
file to another?  The FSF can do this, even if the code movement
crosses the LGPL/GPL boundary, since the FSF has the copyright.  It
shouldn't be a real problem in practice, if we do a similar thing for
*.m4 files.

 The question here is whether these m4 files are more like Emacs's .el
 files, or more like Autoconf's m4 files.

 They are more like Autoconf's m4 files, IMO.

If we want to migrate some of that code into Autoconf, that would be
fine.  We can change the license then, as the FSF owns the copyright.
In the meantime, the m4 files are useful only for GPLed packages, so
the GPL is appropriate and is the more-conservative choice.

 But we certainly want to have the license clause to be as clear as possible,

If we distribute GPLed modules under the terms of the GPL, that's
pretty clear.  It's somewhat more confusing if some of the module
is GPLed and the rest is distributed under different terms.

 The question does come up: The vim author doesn't want to use *.m4 files
 from GNU because he thinks it would infect vim with GPL. So he makes up
 his own autoconf tests for iconv() and gettext(), which then don't work
 on half of the platforms or in half of the configurations.

The gettext module is LGPLed.  vim-like issues shouldn't arise in a
GPLed module, since the source code is GPLed and people who are
worried about infection won't use it.

I realize that having some .m4 files under the GPL, and others under a
more-permissive license, is confusing.  But this sort of confusion is
inevitable in a mixed-license software group like gnulib.  The GNU
project purposely tries to lean in the GPL direction, and discourages
the use of the LGPL.  Since we already have to deal with the problem
with .c files, we might as well use a similar solution for .m4 files.

Re: [Bug-gnulib] missing licenses in gnulib

[Robert Millan]

On Fri, Oct 01, 2004 at 10:00:25PM +0200, Bruno Haible wrote:
 Robert Millan wrote:
lib/atanl.c
lib/logl.c
 
 If you look into the glibc CVS log of sysdeps/ieee754/ldbl-128/s_atanl.c
 and sysdeps/ieee754/ldbl-128/e_logl.c, you see that the copyright holder
 (Stephen Moshier) has given permission to license them under LGPL.
 
lib/diacrit.c
 
 This comes from Fran?ois Pinard's libit-0.2, which is GPL.
 
lib/alloca.c
 
 A long-time GNU citizen, distributed as part of many GNU packages.
 
lib/lbrkprop.h

For these borrowed files from other GNU or free software projects, I think we
still need an explicit note in the files distributed as part of gnulib.

Could you please add the license header that corresponds to the license terms
of the package from which it was borrowed to these files?  IANAL, but I think
you can legaly do that.

 This is an automatically generated file. It's ridiculous to put a copyright
 license on an automatically generated file if the generating program is
 available under GPL, since anyone could take that generating program,
 modify its printf() statements to emit a different license, and run the
 generating program.

I don't know how does copyright law apply to auto-generated programs.  Maybe
debian-legal can offer advice on this.

tests/test-stpncpy.c
 
 I've put this under GPL now.

Ack.  Thanks!

  The worst problem, however, is in the m4 and modules directories, where
  most of the files are unlicensed.
 
 For the m4 files, I propose to add the standard notice to them:
 
 [...]

Well let's see how the GPL vs LGPL discussion ends up.  I don't really have
a take on this.

 About the modules/ files. I wrote most of them. What kind of copyright
 would you find useful, given that it's only meta-information?

I think when they're copyright-significant GPL would be fine.  However, my
suggestion is that you set the global COPYING file to say GPL unless stated
otherwise.  This way we can avoid trouble with copyright-significant misc
files like READMEs and such.

 Oh right, standards.texi is under GFDL. So this means that Debian will not
 ship the GNU standards in the next release?

There's no official statement on this, but the situation is that they may be
included with sarge (at the maintainer's discretion) but not for later
releases, when the new DFSG that unambigously applies to documentation takes
place (see http://www.debian.org/vote/2004/vote_004).

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: [Bug-gnulib] missing licenses in gnulib

[Paul Eggert]

Robert Millan [EMAIL PROTECTED] writes:

 For these borrowed files from other GNU or free software projects, I think we
 still need an explicit note in the files distributed as part of gnulib.

OK, let's start with atanl.c and logl.c.  I see that glibc has fixed
this problem by adding a proper copyright notice.  Also, I see that
gnulib has departed from the glibc code in some cases where it doesn't
need to (and this arguably could introduce a bug).  So I installed
the following patch to fix both problems.

2004-10-06  Paul Eggert  [EMAIL PROTECTED]

* lib/atanl.c, lib/logl.c:
Add GPL notice, to match glibc's added LGPL notice.
* lib/atanl.c (atanl): Keep the code as similar to glibc as possible.
* lib/logl.c (logl): Keep the code as similar to glibc as possible.
This avoids a potential constant-folding bug.

Index: lib/atanl.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/atanl.c,v
retrieving revision 1.1
diff -p -u -r1.1 atanl.c
--- lib/atanl.c 18 Feb 2003 17:05:23 -  1.1
+++ lib/atanl.c 6 Oct 2004 19:59:05 -
@@ -42,7 +42,22 @@
  *
  */
 
-/* Copyright 2001 by Stephen L. Moshier [EMAIL PROTECTED]  */
+/* Copyright 2001 by Stephen L. Moshier [EMAIL PROTECTED]
+
+   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, or (at your option)
+   any later version.
+
+   This program 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; see the file COPYING.
+   If not, write to the Free Software Foundation,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
 
 #include mathl.h
 
@@ -161,19 +176,25 @@ atanl (long double x)
   int k, sign;
   long double t, u, p, q;
 
-  sign = (x  0) ? -1 : 1;
+  sign = x  0.0;
 
   /* Check for zero or NaN.  */
   if (x != x || x == 0.0)
 return x + x;
 
-  /* Check for infinity.  */
   if (x + x == x)
-return sign * atantbl[83];
+{
+  /* Infinity. */
+  if (sign)
+   return -atantbl[83];
+  else
+   return atantbl[83];
+}
 
-  x *= sign;
+  if (sign)
+  x = -x;
 
-  if (x = 10.25) /* 10.25 */
+  if (x = 10.25)
 {
   k = 83;
   t = -1.0/x;
@@ -196,5 +217,9 @@ atanl (long double x)
   u = t * u * p / q  +  t;
 
   /* arctan x = arctan u  +  arctan t */
-  return sign * (atantbl[k] + u);
+  u = atantbl[k] + u;
+  if (sign)
+return (-u);
+  else
+return u;
 }
Index: lib/logl.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/logl.c,v
retrieving revision 1.1
diff -p -u -r1.1 logl.c
--- lib/logl.c  18 Feb 2003 17:05:23 -  1.1
+++ lib/logl.c  6 Oct 2004 19:59:05 -
@@ -46,7 +46,22 @@
 
 #include mathl.h
 
-/* Copyright 2001 by Stephen L. Moshier [EMAIL PROTECTED] */
+/* Copyright 2001 by Stephen L. Moshier [EMAIL PROTECTED]
+
+   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, or (at your option)
+   any later version.
+
+   This program 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; see the file COPYING.
+   If not, write to the Free Software Foundation,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
 
 /* log(1+x) = x - .5 x^2 + x^3 l(x)
-.0078125 = x = +.0078125
@@ -173,7 +188,8 @@ static const long double
 long double
 logl(long double x)
 {
-  long double z, y, w, u, t;
+  long double z, y, w;
+  long double u, t;
   unsigned int m;
   int k, e;
 
@@ -181,15 +197,19 @@ logl(long double x)
 
   /* log(0) = -infinity. */
   if (x == 0.0L)
-return -0.5L / 0.0L;
-
+{
+  return -0.5L / ZERO;
+}
   /* log ( x  0 ) = NaN */
   if (x  0.0L)
-return (x - x) / (x - x);
-
+{
+  return (x - x) / ZERO;
+}
   /* log (infinity or NaN) */
   if (x + x == x || x != x)
-return x + x;
+{
+  return x + x;
+}
 
   /* Extract exponent and reduce domain to 0.703125 = u  1.40625  */
   x = frexpl(x, e);
@@ -202,13 +222,13 @@ logl(long double x)
   /* On this interval the table is not used due to cancellation error.  */
   if ((x = 1.0078125L)  (x = 0.9921875L))
 {
+  z = x - 1.0L;
   k = 64;
   t = 1.0L;
-  z = x - 1.0L;
 }
 

Re: [Bug-gnulib] missing licenses in gnulib / m4

[Bruno Haible]

Paul Eggert wrote:
  The purpose of the special exception clause is so that also non-GPLed
  packages can use autoconfiguration.

 Yes.  However, that purpose doesn't apply to GPLed modules, as they
 can't be linked with non-GPLed packages.

But since *.m4 files are often copied from one module to another, I prefer
to give even the *.m4 files of GPLed modules a more liberal license.

  We want to encourage the use of configure scripts and of portable
  programs.

 That is an important goal, but (putting my RMS hat on :-) it is a
 secondary one for the GNU project.  The main goal is freedom, not
 popularity.

And ease-of-use for the Unix users? If non-GPLed packages fit into
the ./configure; make; make install scheme that GNU has invented,
the win is universal for all users.

 The question here is whether these m4 files are more like Emacs's .el
 files, or more like Autoconf's m4 files.

They are more like Autoconf's m4 files, IMO.

  I see this special exception clause mostly as a clarification: Since
  *.m4 files are never linked into executables or libraries, they could
  also be used in non-LGPLed packages. But if the license doesn't
  explicitly say so, the authors of such packages will be afraid to use it.

 But for GPLed modules, this is intentional.  We don't want people to
 use GPLed modules in non-GPLed applications.

But we certainly want to have the license clause to be as clear as possible,
no? (Since we are not lawyers who could earn money from a license dispute...)

The question does come up: The vim author doesn't want to use *.m4 files
from GNU because he thinks it would infect vim with GPL. So he makes up
his own autoconf tests for iconv() and gettext(), which then don't work
on half of the platforms or in half of the configurations.

Bruno

Re: [Bug-gnulib] missing licenses in gnulib

[Paul Eggert]

To fix diacrit.h and diacrit.c I installed the obvious patch:

2004-10-06  Paul Eggert  [EMAIL PROTECTED]

* diacrit.c, diacrit.h: Add GPL notice.

Index: diacrit.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/diacrit.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -p -u -r1.4 -r1.5
--- diacrit.c   9 Aug 2004 21:11:34 -   1.4
+++ diacrit.c   6 Oct 2004 20:08:44 -   1.5
@@ -3,6 +3,21 @@
François Pinard [EMAIL PROTECTED], 1988.
 
All this file is a temporary hack, waiting for locales in GNU.
+
+   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, or (at your option)
+   any later version.
+
+   This program 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; see the file COPYING.
+   If not, write to the Free Software Foundation,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
 */
 
 #ifdef HAVE_CONFIG_H
Index: diacrit.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/diacrit.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -p -u -r1.4 -r1.5
--- diacrit.h   9 Aug 2004 21:11:34 -   1.4
+++ diacrit.h   6 Oct 2004 20:08:56 -   1.5
@@ -3,6 +3,21 @@
François Pinard [EMAIL PROTECTED], 1988.
 
All this file is a temporary hack, waiting for locales in GNU.
+
+   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, or (at your option)
+   any later version.
+
+   This program 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; see the file COPYING.
+   If not, write to the Free Software Foundation,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
 */
 
 extern const char diacrit_base[]; /* characters without diacritics */

Re: [Bug-gnulib] missing licenses in gnulib

[Paul Eggert]

Robert Millan [EMAIL PROTECTED] writes:

 I don't know how does copyright law apply to auto-generated programs.  Maybe
 debian-legal can offer advice on this.

The answer is it depends, so let me give a few more details about
the file in question, so that debian-legal knows what we're talking
about.  While I'm at it I'll also give you my informed layperson's
opinion.

You can get the contents of the file here:
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/gnulib/gnulib/lib/lbrkprop.h?rev=HEADcontent-type=text/plain

These contents are derived automatically from the Unicode Data Files,
which are available from the Unicode Consortium under the Unicode Copyright
http://www.unicode.org/copyright.html.

The program that generates lbrkprop.h is GPL'ed, but none of this
GPL'ed code survives in lbrkprop.h.  lbrkprop.h merely consists of a
small wrapper (about 15 lines of simple code, which are unprotectible
by copyright in my opinion) followed by data which are automatically
derived from the Unicode Data Files.

Since pure data are not protected by copyright, and since the wrapper
is so small as to be uncopyrightable, I think the entire file is in
the public domain.

So, I think your concerns would be allayed by a brief notice to this
effect.  Something like this, perhaps?

/* Generated automatically by gen-lbrkprop for Unicode 3.1.0.  */
/* This file is in the public domain; it is software derived from
   the Unicode Data Files under the terms of the Unicode Copyright.  */


Bruno Haible writes:

 It's ridiculous to put a copyright license on an automatically
 generated file if the generating program is available under GPL,
 since anyone could take that generating program, modify its printf()
 statements to emit a different license, and run the generating
 program.

It's not always ridiculous to do such a thing.  For example, Bison is
GPLed, but Bison puts a copyright notice (the GPL with a special
exception) into the source-code files that it generates automatically.
Users are of course free to modify Bison to emit a different license,
but if they redistribute the resulting output in violation of the
Bison terms, they are still in violation of Bison's license.

So I'm afraid that we have to evaluate these things on a case-by-case
basis.

Re: [Bug-gnulib] missing licenses in gnulib

[Robert Millan]

On Sat, Oct 02, 2004 at 09:05:51AM +0200, Jim Meyering wrote:
 
 dirfd.h is just dirent boilerplate code plus two trivial #if blocks.
 Not worth worrying about, imho.  The guts are in dirfd.m4.
 getpagesize.h was factored out of GPL'd code.
 I've added a copyright notice to each of those.

Looks fine.  Thanks Jim!

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: [Bug-gnulib] missing licenses in gnulib / m4

[Bruno Haible]

Paul Eggert wrote:
  For the m4 files, I propose to add the standard notice to them:
 
  dnl Copyright (C) YEARS Free Software Foundation, Inc.
  dnl This file is free software, distributed under the terms of the GNU
  dnl General Public License.  As a special exception to the GNU General
  dnl Public License, this file may be distributed as part of a program
  dnl that contains a configuration script generated by Autoconf, under
  dnl the same distribution terms as the rest of that program.

 For GPL'ed modules, I'd rather just use the GPL, as it's simpler and
 clearer.  I don't see the point of having a special exception for the
 m4 files if the underlying code is GPLed.

 For LGPL'ed modules the situation is a bit murkier, and the above
 notice would be fine with me.

Some m4 files are shared between GPLed and LGPLed packages, and it is
frequent to copy m4 macros from one file to another (much more frequent
than copying source code between .c files). For this reason, I think
it would be best if all *.m4 files have the same copying conditions.

The purpose of the special exception clause is so that also non-GPLed
packages can use autoconfiguration. We want to encourage the use of
configure scripts and of portable programs.

I see this special exception clause mostly as a clarification: Since
*.m4 files are never linked into executables or libraries, they could
also be used in non-LGPLed packages. But if the license doesn't explicitly
say so, the authors of such packages will be afraid to use it.

Bruno

Re: [Bug-gnulib] missing licenses in gnulib / m4

[Paul Eggert]

Bruno Haible [EMAIL PROTECTED] writes:

 Some m4 files are shared between GPLed and LGPLed packages,

Yes, and for these files the more-permissive license makes sense.

 and it is frequent to copy m4 macros from one file to another (much
 more frequent than copying source code between .c files).

The m4 files tend to be less-well-engineered than the source files,
and so it's more common to copy m4 code rather than share it.  But in
principle, the stuff that is shared is either so large that it should
be split off into a separate m4 file (with a more permissive license,
if it needs to be shared among GPLed and LGPLed code) or so small
that it's not really copyrightable.  So I don't think this undermines
the overall principle that GPLed modules should have GPLed m4 files.

 The purpose of the special exception clause is so that also non-GPLed
 packages can use autoconfiguration.

Yes.  However, that purpose doesn't apply to GPLed modules, as they
can't be linked with non-GPLed packages.

 We want to encourage the use of configure scripts and of portable
 programs.

That is an important goal, but (putting my RMS hat on :-) it is a
secondary one for the GNU project.  The main goal is freedom, not
popularity.  For example, the GNU project wants to encourage the use
of GNU Emacs Lisp too; but Emacs's .el files are GPLed nonetheless.
This is because, for .el files, the secondary goal of popularity
doesn't outweigh the primary goal of keeping derivative works free.

The question here is whether these m4 files are more like Emacs's .el
files, or more like Autoconf's m4 files.  It is not a trivial
question: I don't see an easy decision either way.  Being more
conservative, I'd prefer to use the GPL if there's reasonable doubt,
as we can always change it to a more-permissive license later.

Another possibility is that we could ask RMS for his opinion.

 I see this special exception clause mostly as a clarification: Since
 *.m4 files are never linked into executables or libraries, they could
 also be used in non-LGPLed packages. But if the license doesn't explicitly
 say so, the authors of such packages will be afraid to use it.

But for GPLed modules, this is intentional.  We don't want people to
use GPLed modules in non-GPLed applications.

Re: [Bug-gnulib] missing licenses in gnulib / m4

[Francesco Poli]

On Tue, 5 Oct 2004 19:26:48 +0200 Bruno Haible wrote:

 Some m4 files are shared between GPLed and LGPLed packages, and it is
 frequent to copy m4 macros from one file to another (much more
 frequent than copying source code between .c files). For this reason,
 I think it would be best if all *.m4 files have the same copying
 conditions.
 
 The purpose of the special exception clause is so that also
 non-GPLed packages can use autoconfiguration. We want to encourage the
 use of configure scripts and of portable programs.

In order to encourage the wide reuse of m4 macros even in proprietary
programs, you could consider releasing them under the Expat (a.k.a. MIT)
license: http://www.jclark.com/xml/copying.txt
It's a very short and simple non-copyleft free GPL-compatible license.


-- 
  Today is the tomorrow you worried about yesterday.
..
Francesco PoliGnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpwKIVGstHBD.pgp
Description: PGP signature

Re: [Bug-gnulib] missing licenses in gnulib

[Bruno Haible]

Karl Berry wrote:
 I suggest, based on the advice in maintain.texi:

  Copyright (C) 2004 Free Software Foundation, Inc.
  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.

 Perhaps it is ok to just put this in a modules/README file and say all
 the modules/* files are covered by it.

OK, I added a modules/README. But why do you put in any medium after
the are permitted? in any medium obviously pertains to
Copying and distribution, which makes it sound as if without royalty
pertains to Copying and distribution as well - and this would be a non-free
license. I would prefer to write

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

Bruno

Re: [Bug-gnulib] missing licenses in gnulib

[Jim Meyering]

Bruno Haible [EMAIL PROTECTED] wrote:
 Robert Millan wrote:
...
   lib/dirfd.h
   lib/getpagesize.h

 coreutils - Jim Meyering.

dirfd.h is just dirent boilerplate code plus two trivial #if blocks.
Not worth worrying about, imho.  The guts are in dirfd.m4.
getpagesize.h was factored out of GPL'd code.
I've added a copyright notice to each of those.

 The worst problem, however, is in the m4 and modules directories, where
 most of the files are unlicensed.

 For the m4 files, I propose to add the standard notice to them:

 dnl Copyright (C) YEARS Free Software Foundation, Inc.
 dnl This file is free software, distributed under the terms of the GNU
 dnl General Public License.  As a special exception to the GNU General
 dnl Public License, this file may be distributed as part of a program
 dnl that contains a configuration script generated by Autoconf, under
 dnl the same distribution terms as the rest of that program.

 Jim and Paul, is this OK with your gnulib/m4/*.m4 files?

That's fine with me.

Re: [Bug-gnulib] missing licenses in gnulib

[Paul Eggert]

Bruno Haible [EMAIL PROTECTED] writes:

 For the m4 files, I propose to add the standard notice to them:

 dnl Copyright (C) YEARS Free Software Foundation, Inc.
 dnl This file is free software, distributed under the terms of the GNU
 dnl General Public License.  As a special exception to the GNU General
 dnl Public License, this file may be distributed as part of a program
 dnl that contains a configuration script generated by Autoconf, under
 dnl the same distribution terms as the rest of that program.

For GPL'ed modules, I'd rather just use the GPL, as it's simpler and
clearer.  I don't see the point of having a special exception for the
m4 files if the underlying code is GPLed.

For LGPL'ed modules the situation is a bit murkier, and the above
notice would be fine with me.

Re: [Bug-gnulib] missing licenses in gnulib

[Bruno Haible]

Robert Millan wrote:
   lib/atanl.c
   lib/logl.c

If you look into the glibc CVS log of sysdeps/ieee754/ldbl-128/s_atanl.c
and sysdeps/ieee754/ldbl-128/e_logl.c, you see that the copyright holder
(Stephen Moshier) has given permission to license them under LGPL.

   lib/diacrit.c

This comes from François Pinard's libit-0.2, which is GPL.

   lib/dirfd.h
   lib/getpagesize.h

coreutils - Jim Meyering.

   lib/alloca.c

A long-time GNU citizen, distributed as part of many GNU packages.

   lib/lbrkprop.h

This is an automatically generated file. It's ridiculous to put a copyright
license on an automatically generated file if the generating program is
available under GPL, since anyone could take that generating program,
modify its printf() statements to emit a different license, and run the
generating program.

   tests/test-stpncpy.c

I've put this under GPL now.

 The worst problem, however, is in the m4 and modules directories, where
 most of the files are unlicensed.

For the m4 files, I propose to add the standard notice to them:

dnl Copyright (C) YEARS Free Software Foundation, Inc.
dnl This file is free software, distributed under the terms of the GNU
dnl General Public License.  As a special exception to the GNU General
dnl Public License, this file may be distributed as part of a program
dnl that contains a configuration script generated by Autoconf, under
dnl the same distribution terms as the rest of that program.

Jim and Paul, is this OK with your gnulib/m4/*.m4 files?

About the modules/ files. I wrote most of them. What kind of copyright
would you find useful, given that it's only meta-information?

 There's also the problem with non-free documentation in doc directory (3
 files), but I'm aware that for the FSF freedom isn't important for
 documentation so I'm ommiting the list here.

Oh right, standards.texi is under GFDL. So this means that Debian will not
ship the GNU standards in the next release?

Bruno

Re: [Bug-gnulib] missing licenses in gnulib

[Karl Berry]

About the modules/ files. I wrote most of them. What kind of copyright
would you find useful, given that it's only meta-information?

I suggest, based on the advice in maintain.texi:

 Copyright (C) 2004 Free Software Foundation, Inc.
 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.

Perhaps it is ok to just put this in a modules/README file and say all
the modules/* files are covered by it.