This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Libgcc and its license

Joseph S. Myers a écrit:
On Wed, 10 Oct 2012, Robert Dewar wrote:
On 10/10/2012 10:48 AM, Joseph S. Myers wrote:
On Wed, 10 Oct 2012, Gabor Loki wrote:

2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra "-E" option to preprocess every sources.
3) create a unique list of all source and header files from the
preprocessed files.
4) at final all source, header and generated files are checked for their
The fact that a header is read by the compiler at some point in generating
a .o file does not necessarily mean that object file is a work based on
that header; that is a legal question depending on how the object code
relates to that header.

At least this is the concept of the FSF:

Making a source file a derivative work of the header needs the header to

   "take a substantial amount of code (coming from inline functions or
   macros with substantial bodies) to do that."  (rms)

This is a quote from an answer to a related question, namely if
including a GPL header turns the module into a derivative work, i.e.
if the module source must be released under the GPL.

I'd say the situation with the runtime library exception is similar.
However, nothing specific can be found on that topic.

From the above quote I depict that the FSF is cool with such includes,
but lawyers from companies that compiler their closed source with GCC and link against libgcc are always concerned about that one line of
code might infect their whole software with the GPL and they have to
publish all their code under the GPL.

The idea of the GPL + RLE is clearly not to introduce such restrictions
or "infection".


Well legally the status of a file is not in anyway affected by what
the header of the file says, but we should indeed try to make sure
that all headers properly reflect the intent.

I'm not talking about the relation between the headings textually located in a source file and the license of that source file. I'm talking about the relation between the license of a .o file and the license of .h files #included at several levels of indirection from the .c source that was compiled to that .o file (in particular, headers included within tm.h, but most or all of the content of which is irrelevant for code being built for the target).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]