After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 463247 - gnumeric contains GPL version 2 only files
gnumeric contains GPL version 2 only files
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on: 463248
Blocks:
 
 
Reported: 2007-08-03 20:31 UTC by Hans de Goede
Modified: 2012-07-16 18:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
list of files missing the "or any later version" language (1.32 KB, text/plain)
2007-08-03 20:32 UTC, Hans de Goede
Details

Description Hans de Goede 2007-08-03 20:31:35 UTC
HI,

First let me start by introducing myself, I'm a linux enthousiast / developer and a Fedora contributer. I maintain the gnumeric package for Fedora.

Currently we are doing a licensing audit of all our packages (what a pain) because of the coming of GPL version 3. GPL version 3 causes problems, because a GPL program may only use (L)GPL libs under the same version of the GPL as the program itself. So once the C-library becomes GPL version 3 (if it will ever) all GPL v2 or higher programs automatically become GPL3 too and GPL version 2 only programs can not be distributed.

This brings me to the reason for writing this mail, I've checked gnumeric-1.6.3 and several files contain copyright headers without the "or (at your option) any later version" language.

I've attached a list (script generated), the first few files I've manually verified, after the blank line there could be false positives.

I hope that this can be remedied, as this could be a problem in the future.
Comment 1 Hans de Goede 2007-08-03 20:32:35 UTC
Created attachment 93058 [details]
list of files missing the "or any later version" language
Comment 2 Morten Welinder 2007-08-03 20:55:52 UTC
You might want to run that script for a recent version, e.g., 1.7.11

That being said, I am not optimistic.

I haven't looked at gpl3, but are you really sure libc is an issue?
Under gpl2, the following language was present:

| However, as a
| special exception, the source code distributed need not include
| anything that is normally distributed (in either source or binary
| form) with the major components (compiler, kernel, and so on) of the
| operating system on which the executable runs, unless that component
| itself accompanies the executable.

And libc is clearly such a component.
Comment 3 Hans de Goede 2007-08-03 21:00:42 UTC
(In reply to comment #2)
> You might want to run that script for a recent version, e.g., 1.7.11
> 

I have looked in svn at a few random files and they all still had the v2 only language

> That being said, I am not optimistic.
> 
> I haven't looked at gpl3, but are you really sure libc is an issue?
> Under gpl2, the following language was present:
> 
> | However, as a
> | special exception, the source code distributed need not include
> | anything that is normally distributed (in either source or binary
> | form) with the major components (compiler, kernel, and so on) of the
> | operating system on which the executable runs, unless that component
> | itself accompanies the executable.
> 
> And libc is clearly such a component.
> 

Notice the "unless that component itself accompanies the executable." Which is the case when they are both on the same Linux distro dvd.

---

Most of the affected files seem to only be written by one person (atleast no one else has added himself to the copyright header), they all contain:

Copyright (C) 2000-2004 Jody Goldberg (jody@gnome.org)

With the years varying, Jody is still active, so finding him to ask for permission to add the "or (at your option) any later version" language is easy.
Comment 4 Morten Welinder 2007-08-03 23:12:24 UTC
Have you actually checked with lawyers if this is a problem?

You would be distributing a binary that, I believe, is not a derived product
on libc.  In order to actually run, it needs a libc, but I don't think there
is anything that absolutely demands that it be gnu libc -- that is a decision
of the user who run Gnumeric.  The gpl concerns itself with distribution,
not with running a program, so even if libc and Gnumeric get mixed at runtime,
I don't see any issue -- the resulting mix is not distributed by anyone.

> Most of the affected files seem to only be written by one person (atleast no
> one else has added himself to the copyright header),

There are lots of cases where someone has not added himself to the
copyright lines.  And it probably isn't easy to track which ones.
Jody and I are the easy cases.
Comment 5 Andreas J. Guelzow 2007-08-03 23:34:47 UTC
I don't think that this is an accident. I am pretty sure that when looking at the license for the individual files you will find a strong correlation with the initial authors of those files.
Comment 6 Hans de Goede 2007-08-05 18:48:40 UTC
(In reply to comment #4)
> Have you actually checked with lawyers if this is a problem?
> 

Not perosnally, but the person coordinating the license audit at Fedora has repeated contacts with both RedHat's and the FSF's lawyers.

> You would be distributing a binary that, I believe, is not a derived product
> on libc.  In order to actually run, it needs a libc, but I don't think there
> is anything that absolutely demands that it be gnu libc -- that is a decision
> of the user who run Gnumeric.  The gpl concerns itself with distribution,
> not with running a program, so even if libc and Gnumeric get mixed at runtime,
> I don't see any issue -- the resulting mix is not distributed by anyone.
> 

Once compiled against glibc it needs glibc, also the problem is that the GPL says that if you distribute something under the GPL you must also distribute / make available all needed components (read libraries) under the GPL, except when these components are part of the OS. Unfortunately the except when these components are part of the OS exception is not valid when the components which could be concidered part of the OS are distributed together with the application.

This is why all proprietary unix vendors have never shipped gnu stuff with there OS, even though the first thing most of there user do is install a bunch of GNU stuff.

This is not about deriving, its about the GPL demanding that all needed components (wether you derive from them or not) are shipped under the same condition, this also means that a GPL app may only link to GPL compatible licensed libraries.

For more on this see the FSF GPL compatibility matrix, I know this is hard to wrap your mind around, it took me a while too. Here is the matrix:
http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility

> > Most of the affected files seem to only be written by one person (atleast no
> > one else has added himself to the copyright header),
> 
> There are lots of cases where someone has not added himself to the
> copyright lines.  And it probably isn't easy to track which ones.
> Jody and I are the easy cases.
> 

Well, IANAL, but AFAIK if this gets to court, its the headers that count. Also if someone did a small patch / bugfix, that doesn't give him (shared) copyright over the file, that only happens when he makes substantial changes and in that case he should have added himself to the header.

(In reply to comment #5)
> I don't think that this is an accident. I am pretty sure that when looking at
> the license for the individual files you will find a strong correlation with
> the initial authors of those files.
> 

Yes, the ones I checked all have Jody in the header, so first lets hear Jody on this, if he is not willing to give permission to at the "or any later version" language, then there is little sense in discussing this further.
Comment 7 Jody Goldberg 2007-08-25 02:07:34 UTC
The lack of 'or any later version' was intentional on my part, as the GPL3 varied through it's gestation.  However, while I still prefer v2, the released v3 is not unacceptable.  Your arguments for why v2 components linked against a v3 libc are problematic for distros are convincing.  I'm willing to relicense with language on the order of 'v2 or v3'.  A carte blanche 'or any future version' is not in the cards, hopefully there will not be a slew of bug fixes to GPL3.
Comment 8 Hans de Goede 2007-08-25 06:17:12 UTC
(In reply to comment #7)
> The lack of 'or any later version' was intentional on my part, as the GPL3
> varied through it's gestation.  However, while I still prefer v2, the released
> v3 is not unacceptable.  Your arguments for why v2 components linked against a
> v3 libc are problematic for distros are convincing.  I'm willing to relicense
> with language on the order of 'v2 or v3'.  A carte blanche 'or any future
> version' is not in the cards, hopefully there will not be a slew of bug fixes
> to GPL3.
> 

Thanks,

Thats good news "either version 2 or (at your option) version 3" will work fine for Fedora. I assume you will fix the headers in svn, and that the new header language will make his way in to the next gnumeric that way?

Don't forget to ask permission to make this change in case of files were other contributers have added themselves to the copyright header too.
Comment 9 Morten Welinder 2012-02-29 15:16:36 UTC
We have Novell permission for gplv2+gplv3 too, see bug 670727.
Comment 10 Morten Welinder 2012-03-19 20:54:06 UTC
See bug 463248 for the corresponding goffice issue.
Comment 11 Morten Welinder 2012-03-19 20:57:22 UTC
We have blanket permission from

Morten Welinder  <terra@gnome.org>
Novell
J.H.M. Dassen (Ray) <jdassen@debian.org>
Emmanuel Pacaud <emmanuel.pacaud@lapp.in2p3.fr>
Jon Kåre Hellan <hellan@acm.org>
Ivan Wong
Eduardo Lima <eduardo.lima@indt.org.br>
Andreas J. Guelzow <aguelzow@pyrshep.ca>
Dominic Lachowicz <domlachowicz@gmail.com>
Hal Ashburner <hal@ashburner.info> <hal_ashburner@yahoo.co.uk>
Valek "Frob" Filippov.
Comment 12 Morten Welinder 2012-03-19 20:59:02 UTC
Make that "blanket permission for using gplv2+gplv3" to be precise.
Comment 13 Jean Bréfort 2012-03-19 21:07:15 UTC
I fully agree for relicensing all my contributions to gplv2+gplv3 (or later, btw).
Comment 14 Jody Goldberg 2012-03-20 11:26:51 UTC
I agree to provide blanket permission to relicense all of my gnumeric contributions using gplv2+gplv3
Comment 15 Morten Welinder 2012-03-20 16:55:13 UTC
We have gplv2+v3 permission from Jukka-Pekka Iivonen.
Comment 16 Morten Welinder 2012-03-22 23:27:37 UTC
zbigniew.chyla@gmail.com [formerly cyba@gnome.pl]:

> I agree to both GPLv2/GPLv3 and "GPLv2 or later" for all my code in Gnumeric.
Comment 17 Hib Eris 2012-03-23 13:43:03 UTC
I agree to provide blanket permission to re-license all of my libgsf/goffice/gnumeric contributions using gplv2 or later.
Comment 18 Morten Welinder 2012-03-23 14:00:02 UTC
Nick Lamb:

> any of my code or other work done by me (e.g. for Excel import/
> export) can be licensed under the GNU GPLv2 or any later version and
> there is no-one else (e.g. employer) who had copyright over any work I
> contributed to Gnumeric in the past.
Comment 19 Morten Welinder 2012-03-24 12:03:02 UTC
We have gplv2/v3 permission from luciano.wolf
(ext-luciano.wolf@nokia.com)
Comment 20 Morten Welinder 2012-03-26 01:17:28 UTC
Dr.Graef@t-online.de (Albert Graef):

> Yes, sure! For the record: I agree to license all code contained in Gnumeric
> and copyrighted by me under the GPL version 3 or later.
Comment 21 Morten Welinder 2012-03-28 00:29:51 UTC
We're done.  GPLv2+GPLv3.  (That was a lot of work, btw.)

To anyone keeping score, I'd like to point out that Gnumeric operates on
a time scale where other projects generally manage to start, blossom, and
get abandoned.


This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 22 Julian Sikorski 2012-07-16 16:56:33 UTC
I don't wanna nitpick, but:

$ licensecheck -r gnumeric-1.11.5 | grep LGPL
gnumeric-1.11.5/plugins/gda/plugin-gda.c: LGPL (v2 or later) (with incorrect FSF address) 
gnumeric-1.11.5/plugins/fn-financial/sc-fin.c: LGPL (v2.1,) 
gnumeric-1.11.5/plugins/plan-perfect/charset.c: LGPL (v2 or later) 
gnumeric-1.11.5/src/widgets/gnumeric-lazy-list.h: LGPL (v2 or later)
Comment 23 Morten Welinder 2012-07-16 18:55:00 UTC
True, but GPL2+ may be substituted for LGPL (even a specific version).
So what's the problem?
Comment 24 Julian Sikorski 2012-07-16 18:56:34 UTC
IANAL, just wanted to clarify that's it's not an oversight. Glad to hear everything is OK.