Re: Bug#523093: undetermined copyright/license violation
Hi Anthony, On Wed, Apr 08, 2009 at 11:42:33PM +0100, Anthony W. Youngman wrote: Each author *should*, as a matter of *courtesy*, explicitly mention the licence in all of their files, Yes, I agree, in general, but it's still not clear to me that section 12 of LGPL can't be interpreted as you can put a single GPL header just like 2 or later in a GPLv2+ header can be interpreted as you can update the version number and use a single header. What would be the difference? and *should* *not* use a different licence when modifying a different author's original files. That depends on whether the original author chose license terms that would allow this. In this case they did. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote: License and copyright are one and the same. GPL license relies on copyright law, just like almost any other open source license there is, be it BSD, Artistic or LGPL. Without copyright, the license is meaningless. Without license, you have no right to the source code. Thanks for the explanation; but I think what you mean is they're dependant on each other. This doesn't imply they're the same thing though. I think we all agree the Copyright lines, whenever they were present, need to be preserved. The license bits in general too, but what happens when the license terms explicitly give you permission to relicense? I gave this example in another mail (sorry if I sound redundant); my understanding is that in 2 or later terms in a GPLv2+ header the license version can be updated by recipients of the code, and that keeping the old license blob around is not a must; is this correct? Does section 12 of LGPL 2.1 work the same way? If not, where's the difference? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)
On Thu, 9 Apr 2009 22:34:15 + brian m. carlson sand...@crustytoothpaste.ath.cx wrote: * The firmware actually has a separate license that reads as follows: * Firmware is: * Derived from proprietary unpublished source code, OK, I wasn't aware of that. With the clear statement that source code was involved in the derivation of the firmware, I'd agree that the effect of the GR is that this firmware needs source code to be in main. * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. This license does not allow for modification. Therefore, Debian can legally distribute the firmware, but only in non-free. I have no objection to Debian distributing this firmware in non-free; nevertheless, as I stated in my original post, whether Debian distributes this firmware is mostly irrelevant with regard to having a functioning tg3 driver. I don't know about you, but I'd much prefer to modify any sort of program, firmware or not, using C or assembly rather than editing the binary directly. I suspect that this is the case for any reasonable programmer. I still hanker after the days of tweaking things in the assembly or hacking around in a compiled binary with a hex editor. As long as source code exists, the effort required becomes a pointless diversion but there remain instances where binary constructs are not compiled, they are created by test and experimentation according to the design (and more often the errata) of a particular piece of hardware using electrical equipment or hardware tools, not text editors. As such, not all firmware can be expected to have any source code. In this case, as we have a declaration that source code was involved, that doesn't apply here. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgTGowGy464.pgp Description: PGP signature
Re: Bug#523093: undetermined copyright/license violation
In message 20090410081139.gb27...@thorin, Robert Millan r...@aybabtu.com writes On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote: License and copyright are one and the same. GPL license relies on copyright law, just like almost any other open source license there is, be it BSD, Artistic or LGPL. Without copyright, the license is meaningless. Without license, you have no right to the source code. Thanks for the explanation; but I think what you mean is they're dependant on each other. This doesn't imply they're the same thing though. I think we all agree the Copyright lines, whenever they were present, need to be preserved. The license bits in general too, but what happens when the license terms explicitly give you permission to relicense? I gave this example in another mail (sorry if I sound redundant); my understanding is that in 2 or later terms in a GPLv2+ header the license version can be updated by recipients of the code, and that keeping the old license blob around is not a must; is this correct? Does section 12 of LGPL 2.1 work the same way? If not, where's the difference? I think you're wrong here! The GPL does NOT give you the right to change the terms on which the original author granted use of the code! What it does give you (if the author uses the or later wording) is the right to use a later licence to cover what YOU do. Let us say that I licence something under Version 2 or later. I have NOT given you the right to relicence my code! What you *can* do is say I prefer the terms of version 3, the licence grant gives me the right to claim version 3 as my permission to use this code, therefore I will modify/distribute/etc under version 3. It DOES NOT allow you to take away my grant of version 2. If you then distribute modified code and say modifications are v3 only the resulting file becomes distributable under v3 only. It still hasn't taken away my grant of version 2 to my code. THAT is why it is downright offensive to change the licence on minor modifications to someone else's file. Your 5% modification is taking away rights that the author of the other 95% granted. You just DON'T DO THAT in the Free Software world. So I repeat, minor fixes should never change the licence. If the changes are large enough to warrant a licence change, they should be in a separate file. And be careful - check your licences. Do they give you the right to *change* the licence on *someone* *elses* *code*. The GPL DOESN'T. The legal result may not matter when mixing licences. But the Free Software world places the SPIRIT of the grant much higher than the letter (okay, the letter has to be correct, but in the Free Software world, abusing the spirit makes enemies!). Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
intercambio de enlaces
Disponemos de varios portales de primer nivel con temática Turismo para intercambio de enlaces de calidad, si estas interesado puedes responder a este correo. -- 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
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. http://fsf.org/ 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 to optimize any GCC
Re: Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 09:37:22AM +0100, Anthony W. Youngman wrote: I think you're wrong here! The GPL does NOT give you the right to change the terms on which the original author granted use of the code! What it does give you (if the author uses the or later wording) is the right to use a later licence to cover what YOU do. Let us say that I licence something under Version 2 or later. I have NOT given you the right to relicence my code! What you *can* do is say I prefer the terms of version 3, the licence grant gives me the right to claim version 3 as my permission to use this code, therefore I will modify/distribute/etc under version 3. It DOES NOT allow you to take away my grant of version 2. If you then distribute modified code and say modifications are v3 only the resulting file becomes distributable under v3 only. It still hasn't taken away my grant of version 2 to my code. Alright then. Thanks for the correction. So what we need it to keep the old license header around, whenever there was one. I'll make sure this applies before the package is uploaded. Thanks -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
I reply to this separately, because it's quite off-topic and unrelated to the problem at hand. I don't want to add noise to the wnpp log. On Fri, Apr 10, 2009 at 09:37:22AM +0100, Anthony W. Youngman wrote: THAT is why it is downright offensive to change the licence on minor modifications to someone else's file. It is not. The author chose a license that explicitly allows this, in section 12, because they didn't want to prevent the license from being upgraded by third parties. This is precisely what is happening. The legal result may not matter when mixing licences. But the Free Software world places the SPIRIT of the grant much higher than the letter The spirit of LGPL (or GPL for that matter) never intended to allow use of patents as a means to impose a tax on software covered by the license, and Novell is doing exactly that. Looks like fair play to me. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
In message 20090410141624.gb28...@thorin, Robert Millan r...@aybabtu.com writes I reply to this separately, because it's quite off-topic and unrelated to the problem at hand. I don't want to add noise to the wnpp log. On Fri, Apr 10, 2009 at 09:37:22AM +0100, Anthony W. Youngman wrote: THAT is why it is downright offensive to change the licence on minor modifications to someone else's file. It is not. The author chose a license that explicitly allows this, in section 12, because they didn't want to prevent the license from being upgraded by third parties. This is precisely what is happening. Just because the author allows it, doesn't mean it isn't offensive. Your small change is taking a lot of rights away from other people. It may be legal and permitted, but isn't it one of the principles of Free Software that downstream can't take away rights granted by upstream? Yet that's exactly what this does! If you do a major rewrite and just re-use part of the old code, then fair enough. But if your changes are minimal then you are preventing your recipients from exercising their rights wrt the *majority* of the code (at least, not without considerable wasted effort stripping out your changes). That's not on. The legal result may not matter when mixing licences. But the Free Software world places the SPIRIT of the grant much higher than the letter The spirit of LGPL (or GPL for that matter) never intended to allow use of patents as a means to impose a tax on software covered by the license, and Novell is doing exactly that. Looks like fair play to me. That's what I meant about breaking the Spirit makes enemies! Novell are seen as not playing fair, and if we play the same tricks back on Novell then as you say, fair's fair. But just because we're playing tit for tat with Novell, doesn't justify us pulling the same trick on other people just because we can. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- 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 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
Re: GCC 4.4 run-time license and non-GPLv3 compilers
* 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: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)
On Fri, Apr 10, 2009 at 01:14, Neil Williams codeh...@debian.org wrote: * Firmware is: * Derived from proprietary unpublished source code, electrical equipment or hardware tools, not text editors. As such, not all firmware can be expected to have any source code. In this case, as we have a declaration that source code was involved, that doesn't apply here. Those tools often have source code like verilog or vhdl, but that doesn't change the problem that this blob can be put into any recognizable form. I wouldn't rule it out is the statement seems to imply that. It says derived from not compiled from. Even the person that made it may not know. -- 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 f...@deneb.enyo.de 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
* 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
On 10-04-2009, Florian Weimer f...@deneb.enyo.de 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: Bug#523093: undetermined copyright/license violation
[no need to Cc: me, as long as you reply on debian-legal] On Thu, 09 Apr 2009 20:38:33 -0400 Hubert Figuiere wrote: [...] Except that the original files don't have any notice. For those that did, the notice has been kept. In that case, I personally think the safest strategy is including such notice, even though it was not present in the first place. Of course, in order to do that, one has to *know* which copyright and permission notice applies to the original code... But one *also* has to know that, in order to engage in any redistribution of the original work or of any modified version! Once more: IANAL, TINLA, IANADD, TINASOTODP. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJs05AExQts.pgp Description: PGP signature
Re: GCC 4.4 run-time license and non-GPLv3 compilers
* 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 caml_int64_div: 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 caml_int64_div+0x1a e2e: e8 fc ff ff ff call e2f caml_int64_div+0x16 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 caml_int64_div+0x33 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 caml_int64_div+0x3f 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: Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 03:51:23PM +0100, Anthony W. Youngman wrote: It is not. The author chose a license that explicitly allows this, in section 12, because they didn't want to prevent the license from being upgraded by third parties. This is precisely what is happening. Just because the author allows it, doesn't mean it isn't offensive. Your small change is taking a lot of rights away from other people. It may be legal and permitted, but isn't it one of the principles of Free Software that downstream can't take away rights granted by upstream? Yet that's exactly what this does! You're confusing rights with leverage. The right to force people into paying you for a service you didn't provide, the right to prevent people from running modified versions of a program, etc. If you do a major rewrite and just re-use part of the old code, then fair enough. But if your changes are minimal then you are preventing your recipients from exercising their rights wrt the *majority* of the code (at least, not without considerable wasted effort stripping out your changes). That's not on. They can still use the original code if they want to. Although if they're US-based corporate users, maybe they'll have to pay Novell for a Peace of Mind pack (aka SLED). That's what I meant about breaking the Spirit makes enemies! Novell are seen as not playing fair, Patent extortion is unethical, in and on itself. They do it by violating the spirit of the GPL, and you perceive this as unfair, but it's not the reason that makes it unethical. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 09:15:39PM +0200, Francesco Poli wrote: On Thu, 09 Apr 2009 20:38:33 -0400 Hubert Figuiere wrote: [...] Except that the original files don't have any notice. For those that did, the notice has been kept. In that case, I personally think the safest strategy is including such notice, even though it was not present in the first place. This is getting extreme. If the original author didn't bother asserting their copyright, why would one have to do it in the modified version? Consider the situation in which you send a patch for some program, but don't add your name in the copyright header. Does this mean every redistributor of the program will have to track you down and add the missing lines? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Fri, 10 Apr 2009 22:01:17 +0200 Robert Millan wrote: On Fri, Apr 10, 2009 at 09:15:39PM +0200, Francesco Poli wrote: On Thu, 09 Apr 2009 20:38:33 -0400 Hubert Figuiere wrote: [...] Except that the original files don't have any notice. For those that did, the notice has been kept. In that case, I personally think the safest strategy is including such notice, even though it was not present in the first place. This is getting extreme. Always extreme! ;-) If the original author didn't bother asserting their copyright, why would one have to do it in the modified version? Because otherwise people reading the modified code would be misled to think that the entire code was written by one single author. This would be plain false, as this single person is in fact the modifier, rather than the only author! Consider the situation in which you send a patch for some program, but don't add your name in the copyright header. I tend to do so only when I think the patch is so trivial that it does not actually add any copyrighted material to the work. Anyway, I can see your point, since many people seem to be much more quick in forgetting about copyright notices when sending patches... Does this mean every redistributor of the program will have to track you down and add the missing lines? No, I don't think so. A mere re-distributor of a work will just have to check copyright and permission notices (and license texts) in order to determine whether he/she has the right to redistribute verbatim copies. The situation gets more interesting when someone takes a multi-file software package which has a centralized copyright and permission notice (rather than detailed copyright information in each file), extracts one file, modifies it (maybe by translating it into another language and then making further modifications?) and incorporates the modified file into his/her own distinct multi-file software package. In this case, I personally think that the safest and cleanest way to behave would be as follows: this person should copy the original copyright/permission notice from the centralized file in the original package into the modified extracted file and then add his/her copyright/permission notice. If the original centralized copyright/permission notice failed to mention some contributor(s) in the first place, oh well, it's not the modifier's fault... But the modifier should include all the copyright information which is easy to retrieve (i.e.: what is found in the centralized file). Again: IANAL, TINLA, IANADD, TINASOTODP. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpl2wNcsi5Zq.pgp Description: PGP signature
Re: GCC 4.4 run-time license and non-GPLv3 compilers
On 10-04-2009, Florian Weimer f...@deneb.enyo.de 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 caml_int64_div: 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 caml_int64_div+0x1a e2e: e8 fc ff ff ff call e2f caml_int64_div+0x16 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 caml_int64_div+0x33 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 caml_int64_div+0x3f 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
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
