public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Arnaud Charlet <charlet@adacore.com>
Cc: Joe Buck <Joe.Buck@synopsys.COM>,  "gcc\@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Compiling programs licensed under the GPL version 2 with GCC 4.4
Date: Sun, 26 Jul 2009 10:19:00 -0000	[thread overview]
Message-ID: <87eis3px0v.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20090726095605.GA67379@adacore.com> (Arnaud Charlet's message of 	"Sun, 26 Jul 2009 11:56:05 +0200")

* Arnaud Charlet:

>> > If the latter (the license includes something like "either version 2
>> > of the License, or (at your option) any later version"), then
>> > nothing prevents you from distributing the program under GPLv3+
>> > instead of GPLv2+.
>> 
>> Right, but we've got some stuff which is GPLv2-only, such as Git,
>> OpenOffice, OpenJDK, etc.
>
> I guess you should check with FSF lawyers in this case.

Kalle already did that, back in April, and hasn't received any reply.
I haven't received any reply for my request about QPL compilers like
Objective Caml, either.

I would rather ask a lawyer of my own, but this doesn't solve the
issue that we generally want to follow the FSF's wishes and not
stretch things as far as possible under copyright law.

> I suspect that other clauses would apply. For example, assuming that
> the GCC 4.4 run-time is part of the OS (which is likely the case you
> described as far as I understand), then the GPLv2 OS exception
> clause would apply.

It doesn't for someone who ships a complete operating system.  Here's
the relevant quote from the GPL, version 2:

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

The FSF claims that it is not permitted to link against arbitrary
libraries when you distribute a program is part of an operating
system.  Free software vendors receive advice according these lines,
and the GPL FAQ at <http://www.gnu.org/philosophy/license-list.html>
also reflects that.  For instance, it says about the QPL:

| Since the QPL is incompatible with the GNU GPL, you cannot take a
| GPL-covered program and QPL-covered program and link them together,
| no matter how.

This still haunts us today with OpenSSL, which is licensed under a
BSD-style license with an advertizing.  It's one reason why we stick
with FSF GNAT in Debian, the GPLed run-time library in AdaCore's
distribution would cause too many licensing headaches.

On the other hand, there is a curious lack of enforcement.  Most
proprietary operating system vendors (including Microsoft and Juniper,
apparently) get a free pass in this area.  They just link GPL-only GNU
software with their proprietary system libraries and ship the result,
often in the same download or on the same media.  This makes me feel
rather bitter.  Why do proprietary vendors receive this additional
freedom, but not free software vendors?

If the FSF keeps refusing to enter any discussion on this matter (I'm
not even talking about agreeing on a solution yet!), our options for
dealing with the GCC 4.4 relicensing fallout at Debian are pretty
limited.  It's also likely that any unilateral action will undermine
the effect of some of the FSF's licensing policies.

  reply	other threads:[~2009-07-26 10:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-25 20:53 Florian Weimer
2009-07-26  1:57 ` Joe Buck
2009-07-26  6:47   ` Florian Weimer
2009-07-26  9:38     ` Arnaud Charlet
2009-07-26  9:51       ` Florian Weimer
2009-07-26  9:56         ` Arnaud Charlet
2009-07-26 10:19           ` Florian Weimer [this message]
2009-07-26 21:51     ` Joe Buck
2009-07-27  6:10       ` Florian Weimer
2009-07-27  7:08         ` Paolo Bonzini
2009-07-27  9:35           ` Florian Weimer
2009-07-27  9:41             ` Alfred M. Szmidt
2009-07-27 10:07             ` Robert Dewar
2009-07-27 10:10               ` Paolo Bonzini
2009-07-27 10:28               ` Manuel López-Ibáñez
2009-07-27 11:05                 ` Alfred M. Szmidt
2009-07-27 12:19                   ` Manuel López-Ibáñez
2009-07-27 10:38               ` Dave Korn
2009-07-27 12:12                 ` Robert Dewar
2009-07-27 11:02               ` Florian Weimer
2009-07-27 12:10                 ` Robert Dewar
2009-07-27 14:29                   ` Frank Ch. Eigler
2009-07-28  0:34                     ` Russ Allbery
2009-07-28  0:57                       ` Joe Buck
2009-07-26  7:12   ` Vincent Lefevre
2009-07-27 21:47 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eis3px0v.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=Joe.Buck@synopsys.COM \
    --cc=charlet@adacore.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).