Re: GCC 4.4 run-time license and non-GPLv3 compilers
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
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
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: ocaml, QPL and the DFSG: New ocaml licence proposal.
On Wed, Jul 28, 2004 at 10:26:42AM +0200, Sven Luther wrote: > On Wed, Jul 28, 2004 at 02:05:28AM +0100, Andrew Suffield wrote: > > On Tue, Jul 27, 2004 at 05:39:06PM -0700, Josh Triplett wrote: > > > Sven Luther wrote: > > Bah, i still don't believe that these two clause are really non-free. They may > be a bother and everything, but not non-free accordying to the DFSG. > > Now, if you feel like solving problems in 5 minutes, could you please have a > look at the unicode.data problem, which Sylvain Legal asked about here over 6 > month ago, and which didn't find an appropriate solution and has been in limbo > since then, even though it seems many other packages carry it already in main. > > Sylvain, could you quickly recapitulate the issue, so Andrew can help solving > it as he so nicely volunteered to do in 5 minutes ? > Hello, Well, this problem has nothing to do with ocaml... But i can set this problem once again : - i have library which contains UnicodeData.txt - copyright of upstream and package contains references to UCD ( you can find this licence here : http://www.unicode.org/copyright.html ) - the files UnicodeData.txt is only shipped in the source ( there is a program to transform into ocaml readable file ) - after having read -legal archive, and submitted my problem http://lists.debian.org/debian-legal/2004/01/msg00022.html, i am still waiting for a solution To sum up, you told every one to wait for a release of a new miscfiles containing up to date UnicodeData.txt. The latest release date from October 2002. I contact maintainer/upstream author who told me he was no more in charge of this package... Now, i am waiting for a solution... Since, i begin to really need the package i am working on, it would be really nice to be able to upload the package in his native form ( ie without doing nasty replacement with files from other package ). Is the current licence of this data, should be enough DFSG free to allow a distribution in main ? Kind regard Sylvain Le Gall ps : my question is a trap : python, perl et al already shipped the file ( i don't know for whom is it a trap : perl maintainer or -legal... good luck perl maintainer )
Re: More questions about the QPL for a compiler
On Tue, Jul 20, 2004 at 04:07:34PM -0400, Brian Thomas Sniffen wrote: > "Sylvain LE GALL" <[EMAIL PROTECTED]> writes: > > > Ocaml, as far as i know, is splitted in two differents sets of object > > files : > > - one set represents the compiler, this means the internal guts of the > > compiler, typing system et al > > - another set represents the standards library, stubs system ( foreign > > call ), VM et al > > > > The first set ( compiler ) is under QPL, the second set is under LGPL > > with Ocaml exception. This means, you can produce binary using LGPL ( > > with Ocaml exception ) only licenced ocaml objects... > > Yes, I understand that the runtime library and such are LGPL'd. But > the compiler, when it compiles a loop, for example, does it in a > particular way. The patterns of assembly code output by the compiler > -- not the parts in the library linked in, but the part actually > written out by the compiler -- are part of the compiler. And they end > up linked with my code. > > It's hard for me to believe that the compiler doesn't write any > creative bits into its output -- though maybe there really has been > effort to put those all into the runtime. > Well -- using your arguments, let me claim that every french book in the world fall under the copyright of "Grammaire Francaise". I am not sure whom belongs this licence ( maybe "Bled" should be the good one )... In other word : the translation made by the compiler is a translation. The original idea which can be copyrighted comes from the code which are translated... No compiler produces automatic meaningfull code... Compilers are made to simplify the task of producing binary code, but they only mimics what human should have written for code. Compilers -- even the actual clever one -- doesn't have the skill to write loop code better than human... Compilers are just tool to manage complexity... There are not really clever -- and they don't produce copyrighted things ( or maybe they take contact by themselves with the patent office, to say : "well, i have written a new loop, and this one is really good, could i copyright it ?" ) This mail is ridiculous -- sorry, Regard Sylvain Le Gall ps : the Categorical Abstract Machine ( ie the CAM ) is clever, but it just interprets the code to have a good view of it, this is the main QPLed part of "o CAM l"
Re: More questions about the QPL for a compiler
On Tue, Jul 20, 2004 at 12:59:35PM -0400, Brian Thomas Sniffen wrote: > My understanding of the Ocaml compiler is that it emits part of itself > into its output. Not all of itself, not even most of itself, but a > noticeable and copyrightable part. I know this is the case for most > compilers, and see no reason it wouldn't be for Ocaml as well. > > Now I look again at QPL 6: > > > You may develop application programs, reusable components and other > > software items that link with the original or modified versions of > > the Software. These items, when distributed, are subject to the > > following requirements... > > And I wonder about executables compiled by the QPL'd Ocaml compilers. > Are they application programs that link with versions of the Software? > It sure sounds like it. I doubt INRIA intended the license to be read > that way. But saying, "this is free because they didn't really mean > what they wrote," doesn't seem a good route. > > Under this interpretation, does this fail DFSG 9? Or is it no worse > than the case of Emacs, where .elc files must be distributed under the > terms of the GPL? > Hello, Ocaml, as far as i know, is splitted in two differents sets of object files : - one set represents the compiler, this means the internal guts of the compiler, typing system et al - another set represents the standards library, stubs system ( foreign call ), VM et al The first set ( compiler ) is under QPL, the second set is under LGPL with Ocaml exception. This means, you can produce binary using LGPL ( with Ocaml exception ) only licenced ocaml objects... Regard Sylvain Le Gall
Re: UnicodeData.txt : what solution ?
On Wed, Jan 07, 2004 at 08:56:49AM -0500, Anthony DeRobertis wrote: > > On Jan 4, 2004, at 13:57, Sylvain LE GALL wrote: > > >Hello, > > > >I have heard that the licence coming with UnicodeData.txt is not DFSG > >free. I am not sure of this assertion. > > > >Can you give me the current debian position about this ? > > The list archives (http://lists.debian.org/debian-legal/) contain > discussion of that file. I believe the last we heard was that a free > version was going to come from the FSF. > Hello, Thank you very much. Kind regard ps : do you a release date, or a place to look for this file
UnicodeData.txt : what solution ?
Hello, I have heard that the licence coming with UnicodeData.txt is not DFSG free. I am not sure of this assertion. Can you give me the current debian position about this ? If it is not DFSG compliant, what should be the solution to still have unicode support ? Thanks Kind regard Sylvain LE GALL ps : i think that there is the same problem with gucharmap package.
