From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1699 invoked by alias); 26 Jul 2009 10:19:11 -0000 Received: (qmail 1690 invoked by uid 22791); 26 Jul 2009 10:19:10 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.enyo.de (HELO mail.enyo.de) (212.9.189.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 26 Jul 2009 10:19:04 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MV0oi-0005e4-TZ; Sun, 26 Jul 2009 12:18:57 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MV0oi-0003rI-HT; Sun, 26 Jul 2009 12:18:56 +0200 From: Florian Weimer To: Arnaud Charlet Cc: Joe Buck , "gcc\@gcc.gnu.org" Subject: Re: Compiling programs licensed under the GPL version 2 with GCC 4.4 References: <87y6qcfprf.fsf@mid.deneb.enyo.de> <20090726015725.GA29580@synopsys.com> <87y6qc0wmc.fsf@mid.deneb.enyo.de> <20090726093814.GD57052@adacore.com> <87prbnpyap.fsf@mid.deneb.enyo.de> <20090726095605.GA67379@adacore.com> Date: Sun, 26 Jul 2009 10:19:00 -0000 In-Reply-To: <20090726095605.GA67379@adacore.com> (Arnaud Charlet's message of "Sun, 26 Jul 2009 11:56:05 +0200") Message-ID: <87eis3px0v.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00536.txt.bz2 * 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 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.