public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Ángel González" <keisial@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: Georg-Johann Lay <gjl@gcc.gnu.org>,
	Florian Weimer <fw@deneb.enyo.de>,
	 Byron Blue <byron@maqsonar.com>,
	gcc-help@gcc.gnu.org
Subject: Re: Simple question
Date: Sun, 26 Aug 2012 09:13:00 -0000	[thread overview]
Message-ID: <50393CB7.5040607@gmail.com> (raw)
In-Reply-To: <CAKOQZ8wA=SpgSVUYnwDobj_WsqVEutUphM8OfeCXMKg6dKmmDg@mail.gmail.com>

On 25/08/12 22:37, Ian Lance Taylor wrote:
> On Sat, Aug 25, 2012 at 1:16 PM, Georg-Johann Lay <gjl@gcc.gnu.org> wrote:
>> Ian Lance Taylor schrieb:
>>
>>> Georg-Johann Lay wrote:
>>>> Ian Lance Taylor schrieb:
>>>>
>>>> Some weeks ago a customer came up with concerns about libgcc, GPL,
>>>> the runtime exception and libgcc code.
>>>>
>>>> The objection against libgcc was that it uses parts that are GPL
>>>> but do *not* come with the runtime exception.
>>>>
>>>> For example, ./libgcc/libgcc2.c includes tm.h which includes files
>>>> from the ARM backend like ./gcc/config/arm/arm.h given the compiler
>>>> is configured for ARM.   arm.h does not come with the library
>>>> exception because it is part of the compiler proper.
>>>>
>>>> The question is now: How is this handled?
>>>>
>>>> Is there a definite statement from the FSF on this case?
>>>> If yes, please point me to it.
>>>> If no, it would be highly appreciated to add a note to the
>>>> FSF or GPL web sites and FAQ.
>>>
>>> I linked to the FSF FAQ earlier, and I think it is clear:
>>>
>>> http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF
>>
>> hmm. That text is about bison and hairy code.
>> It doesn't even mention "runtime library exception" or #include
> That link poses the question "Can I use GPL-covered tools such as GCC
> to compile [non free programs]?" and answers the question "Yes."
>
> Details like the runtime library exception and #include simply aren't
> relevant.  The issues with the runtime library exception only arise in
> very unusual and, to the best of my knowledge, purely theoretical
> cases.  No ordinary user of GCC will ever encounter them.  The issue
> with #include simply doesn't matter.

That's probably because the Runtime library exception requires an explicit
notice on affected files. Had the FSF additionally "licensed" that any
non-GPL
code compiled with an official release of gcc is subject to that
exception and
is not bound to the GPL due to the compilation.

Most lawyers will get confused if needing to track which files get
automatically
linked by gcc and if they have proper exception.

Should be clear from the first FAQ answer, though:
 http://www.gnu.org/licenses/gcc-exception-3.1-faq.html



Another view about the #include could be that the exception at 

libgcc/libgcc2.c covers all included headers, too. But that may be 
arguable.





>> Of course it is possible to ask the FSF or the GCC steering
>> committee each and every time, but such questions pop up again and
>> again and it might help GCC or other free software if the FAQ was
>> more specific and more explicit on that.  The FAQ could explicitly
>> work out some common use cases like include GPL code in non-GPL
>> code, or the above mentioned inclusion of code without runtime
>> exception from code with runtime exception.
> What questions pop up again and again?  Where do they pop up?  I have
> not seen them.
I have seen many people ask the CanIUseGPLToolsForNF question. Funny thing
is that I don't think they call <big corporation> to check if it's ok to
use their
<software> for <confidential business>.
Not that I have seen explicit exceptions for that on propietary EULAs,
either
(why should they?). Still, many people have doubts about the free software
being viric, when they just want to work with it in user mode.

That makes me think there's a problem in the way many people understood
licenses like GPL. That enters a different realm, though.

Regards

  reply	other threads:[~2012-08-25 21:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 13:58 Byron Blue
2012-08-22 14:03 ` Ángel González
2012-08-22 14:35 ` Ian Lance Taylor
2012-08-22 15:21 ` David Brown
2012-08-22 16:39 ` Bob Plantz
2012-08-25 15:57 ` Florian Weimer
2012-08-25 16:05   ` Georg-Johann Lay
2012-08-25 17:30   ` Ian Lance Taylor
2012-08-25 17:55     ` Bob Plantz
2012-08-25 18:20     ` Georg-Johann Lay
2012-08-25 20:37       ` Ian Lance Taylor
2012-08-25 21:01         ` Georg-Johann Lay
2012-08-25 21:23           ` Ian Lance Taylor
2012-08-26  9:13             ` Ángel González [this message]
2012-08-26  9:55               ` Jonathan Wakely
  -- strict thread matches above, loose matches on Subject: below --
2004-04-16 19:26 simple question lrtaylor
2004-04-16 19:19 Ramin NIkaeen
2004-04-16 16:40 lrtaylor
2004-04-15 21:43 Ramin NIkaeen
2004-04-15 21:47 ` Andreas Tobler
2004-04-15 21:47 ` Gabriel Dos Reis
2004-04-15 21:48 ` Paolo Carlini
2004-04-16  9:06 ` Houda Benabderrazik
2002-11-27 10:11 cowen
2000-08-08 10:46 RPathiyal
2000-08-08 18:18 ` Alexandre Oliva

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=50393CB7.5040607@gmail.com \
    --to=keisial@gmail.com \
    --cc=byron@maqsonar.com \
    --cc=fw@deneb.enyo.de \
    --cc=gcc-help@gcc.gnu.org \
    --cc=gjl@gcc.gnu.org \
    --cc=iant@google.com \
    /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).