public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Georg-Johann Lay <gjl@gcc.gnu.org>
To: Ian Lance Taylor <iant@google.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	Byron Blue <byron@maqsonar.com>,
	 gcc-help@gcc.gnu.org
Subject: Re: Simple question
Date: Sat, 25 Aug 2012 18:20:00 -0000	[thread overview]
Message-ID: <50390B17.5050104@gcc.gnu.org> (raw)
In-Reply-To: <CAKOQZ8zb9PT=yi6T4M7W=kPeLPQBXUQF3ySMkHU440CRDtUAxA@mail.gmail.com>

Ian Lance Taylor schrieb:
> On Sat, Aug 25, 2012 at 12:33 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * Byron Blue:
>>
>>> This is the question:
>>>  GCC uses the GNU license scheme. This operating system would be
>>> embedding in our industrial computers and I do not (of course) want
>>> the source code for our operating system to be open source - available
>>> to our competitors. The GNU site is not quite clear in this area and
>>> being new I would not want to "break the rules". Could I ask you for a
>>> bit of clarification on this issue?
>> Unless you take special precautions, GCC copies parts of itself into
>> compiled executables.
> 
> This is false as stated.  It is true that GCC provides runtime
> libraries, and that in some cases the linker (not part of GCC) will
> combine portions of those runtime libraries with the compiled code to
> produce the final executable.
> 
>> The compiled executables must therefore be
>> licensed in a way that is compatible with the GPL.
> 
> This is completely false.
> 
>> However, there is
>> an exception for many parts which can be copied in this way.
> 
> Here you seem to be talking about the runtime libraries.  All parts of
> the runtime libraries have the exception, not "many parts."

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.

All I could find is a remark on a different but related issue,
namely including GPLed headers in non-GPL software.

Richard Stallman wrote 2003-01-09 in [1]:

> [...] I've talked with our lawyer about one specific issue that
> you raised: that of using simple material from header files.
> 
> Someone recently made the claim that including a header file
> always makes a derivative work. 
> 
> That's not the FSF's view. Our view is that just using structure
> definitions, typedefs, enumeration constants, macros with simple
> bodies, etc., is NOT enough to make a derivative work. It would take
> a substantial amount of code (coming from inline functions or macros
> with substantial bodies) to do that.

My assumption is that the policy on including GPL headers without
the runtime exception in GPL sources with the runtime exception is
to be treated similarly.

However, I am not a lawyer and what I think is completely irrelevant.

It there some *official* page that gives explanations on the questions
above?


[1] http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html

  parent reply	other threads:[~2012-08-25 17:30 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 [this message]
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
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 ` Gabriel Dos Reis
2004-04-15 21:47 ` Andreas Tobler
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=50390B17.5050104@gcc.gnu.org \
    --to=gjl@gcc.gnu.org \
    --cc=byron@maqsonar.com \
    --cc=fw@deneb.enyo.de \
    --cc=gcc-help@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).