Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Matthias Klose]

On 22.11.2009 19:49, Florian Weimer wrote:

* Matthias Klose:


On 21.11.2009 06:20, Florian Weimer wrote:

* Steve Langasek:


It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.


My personal impression is that Debian does not view this issue as
critical, either.  Switching the GCC default hasn't happened for other
reasons.


Which are these reasons?


Uhm, aren't you more qualified than me to answer that?

I think we had established quite some time ago that the licensing
issue should not be considered a blocker.


that was before the concerns of a) getting ftpmaster involved, and b) the 
discussion about GPLv2 GPLv3+exception compatibility on lwn.net. I'm upload 
gcc-defaults now, pointing to 4.4 on all architectures. port maintainers didn't 
raise any objections.


  Matthias


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Steve Langasek]

Hi Florian,

On Sat, Nov 21, 2009 at 01:20:15PM +0100, Florian Weimer wrote:

> > It's been suggested to me that it might help Debian move forward on this
> > issue if I provide some background on why Canonical has chosen to not regard
> > this issue as critical for Ubuntu.

> My personal impression is that Debian does not view this issue as
> critical, either.  Switching the GCC default hasn't happened for other
> reasons.

Well, in conversations with Matthias, I understand that this is currently
the main blocker.

> >The FSF has not contacted Canonical requesting a resolution,

> The FSF generally licenses their code under GPL, version x "or later",
> so they are not affected by this at all.

My understanding is that there is a violation of the gcc 4.4 license because
the exception is insufficient.  So whether or not the FSF holds the
copyright on the application /being/ compiled, they're in a position to
comment on whether this is the intended result - and in a position to
resolve the conflict by amending the exception.

> Developers who license their code under the GPL, version 2, and no
> later version, have a reason to complain.  The OpenSSL and KDE issues
> are a precedents showing that we cannot rely on the system library
> exception for linking to the run-time library here.  So the project's
> position will be slightly inconsistent, but I think we can live with
> that.

In the OpenSSL case, we had definite information that the license conflict
would not be resolved.  If it came to light that this recent license
conflict was deliberate on the part of the FSF, I would certainly support
handling it in a consistent manner.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Matthias Klose:

> On 21.11.2009 06:20, Florian Weimer wrote:
>> * Steve Langasek:
>>
>>> It's been suggested to me that it might help Debian move forward on this
>>> issue if I provide some background on why Canonical has chosen to not regard
>>> this issue as critical for Ubuntu.
>>
>> My personal impression is that Debian does not view this issue as
>> critical, either.  Switching the GCC default hasn't happened for other
>> reasons.
>
> Which are these reasons?

Uhm, aren't you more qualified than me to answer that?

I think we had established quite some time ago that the licensing
issue should not be considered a blocker.


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Matthias Klose]

On 21.11.2009 06:20, Florian Weimer wrote:

* Steve Langasek:


It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.


My personal impression is that Debian does not view this issue as
critical, either.  Switching the GCC default hasn't happened for other
reasons.


Which are these reasons? I'm not aware of any other reasons. Maybe it's not the 
best thing to start with this until the eglibc/libstdc++ issue on hppa is 
resolved, but this would affect one architecture only.


  Matthias


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Steve Langasek:

> It's been suggested to me that it might help Debian move forward on this
> issue if I provide some background on why Canonical has chosen to not regard
> this issue as critical for Ubuntu.

My personal impression is that Debian does not view this issue as
critical, either.  Switching the GCC default hasn't happened for other
reasons.

We also ignored a similar issue in the GPLv1 case, but there is far
less code affected, of course.

>The FSF has not contacted Canonical requesting a resolution,

The FSF generally licenses their code under GPL, version x "or later",
so they are not affected by this at all.

Developers who license their code under the GPL, version 2, and no
later version, have a reason to complain.  The OpenSSL and KDE issues
are a precedents showing that we cannot rely on the system library
exception for linking to the run-time library here.  So the project's
position will be slightly inconsistent, but I think we can live with
that.


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Steve Langasek]

Hi all,

On Fri, Apr 10, 2009 at 02:35:28PM +0200, Florian Weimer wrote:
> Starting with version 4.4, the FSF the licenses the GCC run-time
> library with a special exception:

> | Under Section 7 of GPL version 3, you are granted additional
> | permissions described in the GCC Runtime Library Exception, version
> | 3.1, as published by the Free Software Foundation.

> The exception is reproduced below.  Code covered by the exception
> includes routines in gcc/libgcc2.c, which are linked statically with
> many GCC-compiled programs, providing functionality like 64/64 -> 64
> bit division for 32 bit architectures.  (It's not just the C++
> unwinder, as I originally thought.)
> 
> At least with a strict interpretation, the run-time exception suffers
> from a significant issue with compilers which are not licensed under a
> GPLv3-compatible license (such as the GPLv2, or the QPL), and which
> are implemented in the language itself.  (One such compiler is
> Objective Caml.)  After compilation with GCC 4.4, such a compiler is a
> "work based on GCC" because it links to the GCC run-time library.
> Therefore, it's output cannot use the run-time library exception (it's
> not the result of an Eligible Compilation Process because it's neither
> the result of running "GCC, alone or with other GPL-compatible
> software," nor "it is done without using any work based on GCC"), and
> the resulting binary is covered by the GPLv3 (potentially among other
> licenses).  Bootstrapping the compiler results in a
> non-redistributable binary if the compiler is not licensed under a
> GPLv3-compatible license (such as the QPL, in the Objective Caml
> example).

It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.

The Ubuntu 9.10 release has shipped with gcc 4.4 as the default compiler.
Since Ubuntu imports the complete set of packages from Debian, this license
incompatibility affects Ubuntu equally as much as Debian.  However, unlike
Debian, Canonical have concluded that the incompatibility is a nominal one
that should not block the switch to gcc 4.4 by default, and have continued
to track gcc upstream in the belief that this is a bug in the new license
exception:

 - It is my informal understanding that the change in exception clause was
   triggered by a specific use case involving non-free language frontends.

 - The effect of prohibiting incompatibly- but freely-licensed language
   frontends from using gcc does not appear to be of either strategic or
   tactical benefit to the FSF or the promotion of Free Software in general.

 - The lack of prompt reaction from the FSF to this issue (assuming it's
   actually gotten in front of the right eyes at the FSF yet, which I can't
   speak to) is not unreasonable:  if the exception change was made to fix a
   bug and has caused a regression, I would expect them to understandably
   wary of introducing further regressions as a result of further changes.

 - The Ubuntu development release included gcc 4.4 as the default compiler
   from April 2009 on, and Ubuntu 9.10 shipped three weeks ago with gcc 4.4
   as default (and with a full ocaml rebuild due to a toolchain transition,
   so this issue definitely applies to the binary package contents of 9.10).
   The FSF has not contacted Canonical requesting a resolution, in spite of
   the fact that this has been a fairly high-profile issue (i.e., discussed
   in LWN).

Based on this, I think that there's a preponderance of evidence that using
gcc 4.4 together with other language compilers licensed under free but
GPL-incompatible terms is consistent with the FSF's intent and as such is
not unethical, nor does it pose a significant legal risk to the project or
the ftpmasters.  It is my recommendation that we therefore switch to gcc 4.4
by default in squeeze, while continuing to reach out to the FSF for
resolution of the licensing bug.

(In any case, the FSF has a clear history of prioritizing remediation over
penalization in the case of unintended license violations, and Canonical is
a bit bigger of a target than the Debian ftpmasters if the FSF were after
money, so I don't think this should be a source of concern for the
ftpmasters.  I realize that I'm also not on the line personally for any
legal liability on Canonical's side and as a result this may not be very
persuasive, but it's my firm belief that this is the right standard for the
Debian ftpmasters to use as well.)

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Matthias Klose]

On 16.08.2009 10:50, Luk Claes wrote:

Matthias Klose wrote:

On 29.04.2009 04:49, Florian Weimer wrote:

* Florian Weimer:


I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception).  Until we know
for sure how to interpret the exception, it's probably best not to
make GCC 4.4 the default compiler in sid/squeeze.


For the record, due to a MUA glitch, the message to the FSF was not
actually sent until yesterday.  Sorry about that.


Apparently there's no feedback yet from the FSF. This issue should not
prevent upgrading GCC to 4.4 for squeeze. I talked with Luk Claes, and
we came to the conclusion that raising awareness for this potential
issue with compilers distributed with Debian and filing a bug report to
track progress would be a step forward. The bug report should be for
`general', severity `serious'. Somebody then needs to identify and
examine all compiler packages shipped.


There does not seem to be filed such a bug report nor was there a
thorough examination of all compiler and plugin packages that I know of?

What's the status?


The topic was picked up by lwn.net. There was an extra issue raised if combining 
GPLv2 only licensed sources and LGPLv3+exception is valid.


I don't plan to file the bug report myself or work on the general compiler 
review besides for packages I maintain as a team member or myself.


  Matthias


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Luk Claes]

Matthias Klose wrote:
> On 29.04.2009 04:49, Florian Weimer wrote:
>> * Florian Weimer:
>>
>>> I've asked the FSF for a clarification (the second time, the first
>>> clarification resulted in the Java bytecode exception).  Until we know
>>> for sure how to interpret the exception, it's probably best not to
>>> make GCC 4.4 the default compiler in sid/squeeze.
>>
>> For the record, due to a MUA glitch, the message to the FSF was not
>> actually sent until yesterday.  Sorry about that.
> 
> Apparently there's no feedback yet from the FSF. This issue should not
> prevent upgrading GCC to 4.4 for squeeze. I talked with Luk Claes, and
> we came to the conclusion that raising awareness for this potential
> issue with compilers distributed with Debian and filing a bug report to
> track progress would be a step forward. The bug report should be for
> `general', severity `serious'. Somebody then needs to identify and
> examine all compiler packages shipped.

There does not seem to be filed such a bug report nor was there a
thorough examination of all compiler and plugin packages that I know of?

What's the status?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Kalle Olavi Niemitalo:

> Please consider also the effect of GCC 4.4 on GPLv2-only applications,
> where the application's licence requires source code under GPLv2,
> including the source code of libgcc if GCC accompanies the executable,
> but the source code of libgcc in GCC 4.4 is not available under GPLv2.

Yuck, I think you are right.  This looks for more serious than the
issue I raised.


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Kalle Olavi Niemitalo]

Matthias Klose  writes:

> Apparently there's no feedback yet from the FSF. This issue should not
> prevent upgrading GCC to 4.4 for squeeze.

Please consider also the effect of GCC 4.4 on GPLv2-only applications,
where the application's licence requires source code under GPLv2,
including the source code of libgcc if GCC accompanies the executable,
but the source code of libgcc in GCC 4.4 is not available under GPLv2.

2007-10-24 incompatibility noted on gcc mailing list:
http://gcc.gnu.org/ml/gcc/2007-10/msg00390.html
mid:20071025003948.gt6...@synopsys.com

2009-02-05 I posted to gnu.misc.discuss, no followups:
http://lists.gnu.org/archive/html/gnu-misc-discuss/2009-02/msg00100.html
mid:87zlh1uqic@astalo.kon.iki.fi

2009-04-23 I asked the FSF, got [gnu.org #433709], no human response:
http://permalink.gmane.org/gmane.comp.web.links/3405
mid:87vdow6ia4@astalo.kon.iki.fi


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Matthias Klose]

On 29.04.2009 04:49, Florian Weimer wrote:

* Florian Weimer:


I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception).  Until we know
for sure how to interpret the exception, it's probably best not to
make GCC 4.4 the default compiler in sid/squeeze.


For the record, due to a MUA glitch, the message to the FSF was not
actually sent until yesterday.  Sorry about that.


Apparently there's no feedback yet from the FSF. This issue should not prevent 
upgrading GCC to 4.4 for squeeze. I talked with Luk Claes, and we came to the 
conclusion that raising awareness for this potential issue with compilers 
distributed with Debian and filing a bug report to track progress would be a 
step forward. The bug report should be for `general', severity `serious'. 
Somebody then needs to identify and examine all compiler packages shipped.



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Florian Weimer:

> I've asked the FSF for a clarification (the second time, the first
> clarification resulted in the Java bytecode exception).  Until we know
> for sure how to interpret the exception, it's probably best not to
> make GCC 4.4 the default compiler in sid/squeeze.

For the record, due to a MUA glitch, the message to the FSF was not
actually sent until yesterday.  Sorry about that.


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Joe Smith]

"Stéphane Glondu"  wrote:


So one could even
make a proprietary compiler using C as an intermediate langage, and GCC
for the final stage, I guess.


Comeau C++'s GNU/Linux builds do exactly that. (In general it uses the local 
C compiler as a slightly higher level assembler. This saves them the work of 
needing to write a backend for every target platform. They do need to tweak 
the C-backend for specific platforms/compiler combinations, so as to be able 
to maintain maximum performance of the final binary. That is especially true 
of the exception feature, which has always been problematic for similar 
efforts.)





--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Josselin Mouette:

> Le vendredi 10 avril 2009 à 14:35 +0200, Florian Weimer a écrit :
>> At least with a strict interpretation, the run-time exception suffers
>> from a significant issue with compilers which are not licensed under a
>> GPLv3-compatible license (such as the GPLv2, or the QPL), and which
>> are implemented in the language itself.  (One such compiler is
>> Objective Caml.)  After compilation with GCC 4.4, such a compiler is a
>> "work based on GCC" because it links to the GCC run-time library.
>
> No, the exception is here precisely to make it not so. The ocamlopt
> binary was generated through an eligible compilation process, and as
> such you can choose your terms for redistribution.

Well, it is a work based on GCC, but not subject to the GPLv3 thanks
to the exception.

>> Therefore, it's output cannot use the run-time library exception (it's
>> not the result of an Eligible Compilation Process because it's neither
>> the result of running "GCC, alone or with other GPL-compatible
>> software," nor "it is done without using any work based on GCC"), and
>> the resulting binary is covered by the GPLv3 (potentially among other
>> licenses).
>
> I don’t think you can say this is a work based on GCC just because of
> that.

Why not?  gcc/libgcc2.c and other files are part of GCC.

The license is ambiguous.


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Josselin Mouette]

Le vendredi 10 avril 2009 à 14:35 +0200, Florian Weimer a écrit :
> At least with a strict interpretation, the run-time exception suffers
> from a significant issue with compilers which are not licensed under a
> GPLv3-compatible license (such as the GPLv2, or the QPL), and which
> are implemented in the language itself.  (One such compiler is
> Objective Caml.)  After compilation with GCC 4.4, such a compiler is a
> "work based on GCC" because it links to the GCC run-time library.

No, the exception is here precisely to make it not so. The ocamlopt
binary was generated through an eligible compilation process, and as
such you can choose your terms for redistribution.

> Therefore, it's output cannot use the run-time library exception (it's
> not the result of an Eligible Compilation Process because it's neither
> the result of running "GCC, alone or with other GPL-compatible
> software," nor "it is done without using any work based on GCC"), and
> the resulting binary is covered by the GPLv3 (potentially among other
> licenses).

I don’t think you can say this is a work based on GCC just because of
that.

Anyway, clarification from the FSF would be better, but I don’t think
this is violating the spirit of the license, so this can be fixed later
on, and this is not a reason not to make GCC 4.4 the default.

Cheers,
-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Sylvain Le Gall]

On 10-04-2009, Florian Weimer  wrote:
> * Sylvain Le Gall:
>
>>> byterun/ints.c, function caml_int64_div, the I64_div macro.  This is
>>> expanded into a plain division operator, and that is compiled into a
>>> run-time library call by GCC.
>>>
>>
>> I64_div is a function defined either in byterun/int64_emul.h o
>> byterun/int64_native.h. Reading both I64_div, I don't see any specific
>> GCC usage. 
>>
>> Could you be more precise ? I must admit I don't understand at all this
>> issue ! 
>
> Here's a disassembly of the caml_int64_div function in ocaml 3.10.2
>
> 0e19 :
>  e19:   55  push   %ebp
>  e1a:   89 e5   mov%esp,%ebp
>  e1c:   83 ec 18sub$0x18,%esp
>  e1f:   8b 45 0cmov0xc(%ebp),%eax
>  e22:   8b 50 08mov0x8(%eax),%edx
>  e25:   8b 40 04mov0x4(%eax),%eax
>  e28:   89 d1   mov%edx,%ecx
>  e2a:   09 c1   or %eax,%ecx
>  e2c:   75 05   jnee33 
>  e2e:   e8 fc ff ff ff  call   e2f 
> e2f: R_386_PC32 caml_raise_zero_divide
>  e33:   89 44 24 08 mov%eax,0x8(%esp)
>  e37:   89 54 24 0c mov%edx,0xc(%esp)
>  e3b:   8b 4d 08mov0x8(%ebp),%ecx
>  e3e:   8b 41 04mov0x4(%ecx),%eax
>  e41:   8b 51 08mov0x8(%ecx),%edx
>  e44:   89 04 24mov%eax,(%esp)
>  e47:   89 54 24 04 mov%edx,0x4(%esp)
>  e4b:   e8 fc ff ff ff  call   e4c 
> e4c: R_386_PC32 __divdi3
>  e50:   89 04 24mov%eax,(%esp)
>  e53:   89 54 24 04 mov%edx,0x4(%esp)
>  e57:   e8 fc ff ff ff  call   e58 
> e58: R_386_PC32 caml_copy_int64
>  e5c:   c9  leave
>  e5d:   c3  ret
>
> The actual division is carried out by calling __divdi3.  This function
> is implemented in the GCC run-time library, and statically linked into
> the executable.
>
> Note that this is just an example.  Other, similar issues probably
> exist on other architectures (particular RISCy ones).
>
>

Just for the sake of my own comprehesion (and future reader of this 
thread), let me rephrase the problem :
- GCC 4.4 add dependency to a GPLv3 library
- Some part of ocamlopt get GCC 4.4 new dependency
- ocamlopt is licensed under QPL
- GCC GPLv3 library has an exception that allow non-compiler usage
- ocamlopt end up with GPLv3 and QPL which is a problem

OK, so GCC embed its own code in the produced code making non-GPLv3 
compiler outlaw. This is VERY unfortunate and should lead to a lot more
problem than just with OCaml.

I don't think there is anything the OCaml Debian Packaging can do
about this issue (nor the OCaml upstream author). Maybe you can create a
bug against GCC to at least provide an alternative to this situation 
(going back to GCC 4.3 behavior when --no-link-GPLv3 is set at gcc 
invocation).

I agree with you that GCC 4.4 should not become default compiler for 
Sid/Squeeze with this kind of bug.

Now, what can save OCaml, IMHO. The dependency added to ocamlopt is
related to a runtime library and not at all to the compilation process.
In other word we don't combine "the Runtime Library with Independent
Modules". And ocamlopt emit assembler instruction that is passed to gas
for compilation into target code. So to my mind, OCaml can be seen as
source code generators for gas... (ok producing gas source code is quite
near to producing target code but it is not yet possible to use it on
the machine). Would this way of thinking stand regarding the runtime
exception ?

Regards,
Sylvain Le Gall

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Sylvain Le Gall:

>> byterun/ints.c, function caml_int64_div, the I64_div macro.  This is
>> expanded into a plain division operator, and that is compiled into a
>> run-time library call by GCC.
>>
>
> I64_div is a function defined either in byterun/int64_emul.h o
> byterun/int64_native.h. Reading both I64_div, I don't see any specific
> GCC usage. 
>
> Could you be more precise ? I must admit I don't understand at all this
> issue ! 

Here's a disassembly of the caml_int64_div function in ocaml 3.10.2

0e19 :
 e19:   55  push   %ebp
 e1a:   89 e5   mov%esp,%ebp
 e1c:   83 ec 18sub$0x18,%esp
 e1f:   8b 45 0cmov0xc(%ebp),%eax
 e22:   8b 50 08mov0x8(%eax),%edx
 e25:   8b 40 04mov0x4(%eax),%eax
 e28:   89 d1   mov%edx,%ecx
 e2a:   09 c1   or %eax,%ecx
 e2c:   75 05   jnee33 
 e2e:   e8 fc ff ff ff  call   e2f 
e2f: R_386_PC32 caml_raise_zero_divide
 e33:   89 44 24 08 mov%eax,0x8(%esp)
 e37:   89 54 24 0c mov%edx,0xc(%esp)
 e3b:   8b 4d 08mov0x8(%ebp),%ecx
 e3e:   8b 41 04mov0x4(%ecx),%eax
 e41:   8b 51 08mov0x8(%ecx),%edx
 e44:   89 04 24mov%eax,(%esp)
 e47:   89 54 24 04 mov%edx,0x4(%esp)
 e4b:   e8 fc ff ff ff  call   e4c 
e4c: R_386_PC32 __divdi3
 e50:   89 04 24mov%eax,(%esp)
 e53:   89 54 24 04 mov%edx,0x4(%esp)
 e57:   e8 fc ff ff ff  call   e58 
e58: R_386_PC32 caml_copy_int64
 e5c:   c9  leave
 e5d:   c3  ret

The actual division is carried out by calling __divdi3.  This function
is implemented in the GCC run-time library, and statically linked into
the executable.

Note that this is just an example.  Other, similar issues probably
exist on other architectures (particular RISCy ones).


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Sylvain Le Gall]

On 10-04-2009, Florian Weimer  wrote:
> * Sylvain Le Gall:
>
>>> But in Debian, we compile with GCC.  And for the Int64 module,
>>> functionality from libgcc2.c gets compiled into the binary.  (This is
>>> just the example I've verified.)
>
>> Int64 module is under LGPL + static link exception (and everything
>> related to runtime library). Does it change anything ?
>
> No, I don't think so.  The compiler license doesn't change as a
> result.
>
>> Could you point us to the precise location of "the functionality from
>> libgcc2.c" ?
>
> byterun/ints.c, function caml_int64_div, the I64_div macro.  This is
> expanded into a plain division operator, and that is compiled into a
> run-time library call by GCC.
>

I64_div is a function defined either in byterun/int64_emul.h o
byterun/int64_native.h. Reading both I64_div, I don't see any specific
GCC usage. 

Could you be more precise ? I must admit I don't understand at all this
issue ! 

At least in int64_emul.h, I don't see anything specific to GCC (the
same code will perfectly fit with MSVC, which is what it does).

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Sylvain Le Gall:

>> But in Debian, we compile with GCC.  And for the Int64 module,
>> functionality from libgcc2.c gets compiled into the binary.  (This is
>> just the example I've verified.)

> Int64 module is under LGPL + static link exception (and everything
> related to runtime library). Does it change anything ?

No, I don't think so.  The compiler license doesn't change as a
result.

> Could you point us to the precise location of "the functionality from
> libgcc2.c" ?

byterun/ints.c, function caml_int64_div, the I64_div macro.  This is
expanded into a plain division operator, and that is compiled into a
run-time library call by GCC.


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Sylvain Le Gall]

On 10-04-2009, Florian Weimer  wrote:
> * Stéphane Glondu:
>
>>  * The runtime (ocamlrun) is a pure C program, that can be compiled with
>>any C compiler. Customized runtimes (with functions implemented in C)
>>can be generated; in this case, a C file might be generated by
>>ocamlc{,.opt}, and this file is handled the same way as the other
>>files containing the C functions.
>
> But in Debian, we compile with GCC.  And for the Int64 module,
> functionality from libgcc2.c gets compiled into the binary.  (This is
> just the example I've verified.)
>

Int64 module is under LGPL + static link exception (and everything
related to runtime library). Does it change anything ?

Could you point us to the precise location of "the functionality from
libgcc2.c" ?

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Stéphane Glondu:

>  * The runtime (ocamlrun) is a pure C program, that can be compiled with
>any C compiler. Customized runtimes (with functions implemented in C)
>can be generated; in this case, a C file might be generated by
>ocamlc{,.opt}, and this file is handled the same way as the other
>files containing the C functions.

But in Debian, we compile with GCC.  And for the Int64 module,
functionality from libgcc2.c gets compiled into the binary.  (This is
just the example I've verified.)

> In any case, intermediate representations of GCC are not used. IMHO,
> the exception applies to OCaml itself (and its runtime), and code
> generated by OCaml are usually not concerned. Therefore, I don't
> consider any part of the OCaml system being a work based on GCC.

IMHO, "Work based on GCC" has to be interpreted in a copyright sense.
Programs compiled with ocamlopt likely contain some pieces of the GCC
run-time library, so they are works based on GCC to some degree.  (And
this is not really debatable---after all, the FSF uses precisely this
angle to restrict the use of GCC, by limiting the scope of the
run-time library exception).

I don't even think it's an expansionist position because it involves
static linking.  (I don't like the related view that referencing
functionality described in a language standard, perhaps through
dynamic linking, makes your code subject to the copyright license of
one implementation of that functionality, but this does not apply
here.)

> The FSF obviously wants to outlaw proprietary compilers that use
> intermediate representations of GCC. Using GCC as a C-to-asm compiler is
> fine, even in a proprietary project. The FAQ states explicitly that a
> program generating a C file, for example (which might be a compiler in
> fact), doesn't take part in the "compilation process". So one could even
> make a proprietary compiler using C as an intermediate langage, and GCC
> for the final stage, I guess.

Well, this is an argument why the FSF might not like the effect of the
run-time library exception on Objective Caml.  I don't think it's a
compelling argument against the interpretation of the exception I've
outlined.  Unless the FSF clarifies it's position, we don't know how
they prefer to resolve the conflict.  I can image that they want to
promote the use of the GPLv3-compatible licenses for compilers on free
operating systems (comparable to how they promote the use of GNUTLS).


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Stéphane Glondu]

Florian Weimer a écrit :
> Starting with version 4.4, the FSF the licenses the GCC run-time
> library with a special exception: [...]

A few precisions:

 * OCaml doesn't depend on any GCC-specific feature. It works with any
   C compiler.

 * There are 4 compilers for Objective Caml:

   - ocamlc, ocamlc.opt generate bytecode objects specific to OCaml,
 which can be considered as "Target Code" (IMHO), using the terms of
 [1]. When running these compilers, GCC is not involved at all in
 the compilation process. The process of compilation of ocamlc.opt
 itself invokes GCC merely as a linker, the process of compilation
 of ocamlc only uses ocamlc itself (either the binary provided by
 upstream, or the bootstrapped one which is identical modulo
 system-specific locations).

   - ocamlopt, ocamlopt.opt generate assembly code, i.e. another form of
 "Target Code". When running these compilers, GCC is invoked only
 as a linker. The process of compilation of ocamlopt itself can use
 only ocamlc (no GCC at all). The process of compilation of
 ocamlopt.opt uses GCC as a linker.

 * The runtime (ocamlrun) is a pure C program, that can be compiled with
   any C compiler. Customized runtimes (with functions implemented in C)
   can be generated; in this case, a C file might be generated by
   ocamlc{,.opt}, and this file is handled the same way as the other
   files containing the C functions.

In any case, intermediate representations of GCC are not used. IMHO, the
exception applies to OCaml itself (and its runtime), and code generated
by OCaml are usually not concerned. Therefore, I don't consider any part
of the OCaml system being a work based on GCC.

The FAQ [2] seems to confirm this analysis, in particular the answers to
the following questions:

> I use GCC in conjunction with proprietary preprocessors and/or source 
> generators to compile my program. Can I still take advantage of the exception?

and

> I use GCC to compile parts of my program, and a proprietary compiler to 
> compile other parts. The pieces are combined afterward, during assembler or 
> linking phases. Can I still take advantage of the exception?

Back to the original mail:

> We might weasel out of this if we always bootstrap off GCC 4.3, but
> this is not how the Objective Caml build system works (it bootstraps
> the compiler off pre-compiled bytecode shipped along the sources).
> Perhaps the above interpretation is too narrow, but I don't think it's
> a fringe reading.  The FSF obviously wants to outlaw proprietary
> compilers, and from a purely license-centric point of view, a
> proprietary compiler is as good or bad as one licensed in a way which
> is not compatible with the GPLv3.  What makes the license
> interpretation some awkward is the bootstrapping process and its
> recursive nature.

The FSF obviously wants to outlaw proprietary compilers that use
intermediate representations of GCC. Using GCC as a C-to-asm compiler is
fine, even in a proprietary project. The FAQ states explicitly that a
program generating a C file, for example (which might be a compiler in
fact), doesn't take part in the "compilation process". So one could even
make a proprietary compiler using C as an intermediate langage, and GCC
for the final stage, I guess.

[1] http://www.gnu.org/licenses/gcc-exception.html
[2] http://www.gnu.org/licenses/gcc-exception-3.1-faq.html


Cheers,

-- 
Stéphane


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

Starting with version 4.4, the FSF the licenses the GCC run-time
library with a special exception:

| Under Section 7 of GPL version 3, you are granted additional
| permissions described in the GCC Runtime Library Exception, version
| 3.1, as published by the Free Software Foundation.

The exception is reproduced below.  Code covered by the exception
includes routines in gcc/libgcc2.c, which are linked statically with
many GCC-compiled programs, providing functionality like 64/64 -> 64
bit division for 32 bit architectures.  (It's not just the C++
unwinder, as I originally thought.)

At least with a strict interpretation, the run-time exception suffers
from a significant issue with compilers which are not licensed under a
GPLv3-compatible license (such as the GPLv2, or the QPL), and which
are implemented in the language itself.  (One such compiler is
Objective Caml.)  After compilation with GCC 4.4, such a compiler is a
"work based on GCC" because it links to the GCC run-time library.
Therefore, it's output cannot use the run-time library exception (it's
not the result of an Eligible Compilation Process because it's neither
the result of running "GCC, alone or with other GPL-compatible
software," nor "it is done without using any work based on GCC"), and
the resulting binary is covered by the GPLv3 (potentially among other
licenses).  Bootstrapping the compiler results in a
non-redistributable binary if the compiler is not licensed under a
GPLv3-compatible license (such as the QPL, in the Objective Caml
example).

We might weasel out of this if we always bootstrap off GCC 4.3, but
this is not how the Objective Caml build system works (it bootstraps
the compiler off pre-compiled bytecode shipped along the sources).
Perhaps the above interpretation is too narrow, but I don't think it's
a fringe reading.  The FSF obviously wants to outlaw proprietary
compilers, and from a purely license-centric point of view, a
proprietary compiler is as good or bad as one licensed in a way which
is not compatible with the GPLv3.  What makes the license
interpretation some awkward is the bootstrapping process and its
recursive nature.

I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception).  Until we know
for sure how to interpret the exception, it's probably best not to
make GCC 4.4 the default compiler in sid/squeeze.


GCC RUNTIME LIBRARY EXCEPTION

Version 3.1, 31 March 2009

Copyright (C) 2009 Free Software Foundation, Inc. 

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

This GCC Runtime Library Exception ("Exception") is an additional
permission under section 7 of the GNU General Public License, version
3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
bears a notice placed by the copyright holder of the file stating that
the file is governed by GPLv3 along with this Exception.

When you use GCC to compile a program, GCC may combine portions of
certain GCC header files and runtime libraries with the compiled
program. The purpose of this Exception is to allow compilation of
non-GPL (including proprietary) programs to use, in this way, the
header files and runtime libraries covered by this Exception.

0. Definitions.

A file is an "Independent Module" if it either requires the Runtime
Library for execution after a Compilation Process, or makes use of an
interface provided by the Runtime Library, but is not otherwise based
on the Runtime Library.

"GCC" means a version of the GNU Compiler Collection, with or without
modifications, governed by version 3 (or a specified later version) of
the GNU General Public License (GPL) with the option of using any
subsequent versions published by the FSF.

"GPL-compatible Software" is software whose conditions of propagation,
modification and use would permit combination with GCC in accord with
the license of GCC.

"Target Code" refers to output from any compiler for a real or virtual
target processor architecture, in executable form or suitable for
input to an assembler, loader, linker and/or execution
phase. Notwithstanding that, Target Code does not include data in any
format that is used as a compiler intermediate representation, or used
for producing a compiler intermediate representation.

The "Compilation Process" transforms code entirely represented in
non-intermediate languages designed for human-written code, and/or in
Java Virtual Machine byte code, into Target Code. Thus, for example,
use of source code generators and preprocessors need not be considered
part of the Compilation Process, since the Compilation Process can be
understood as starting with the output of the generators or
preprocessors.

A Compilation Process is "Eligible" if it is done using GCC, alone or
with other GPL-compatible software, or if it is done without using any
work based on GCC. For example, using non-GPL-compatible Software