debian control license

[Avery Fay]

Hi,

I'm interested in making a web based database of a subset of debian
packages. Even though the scope of the information in the database would be
larger than what's included in the debian package metadata, I think that for
initial seeding purposes the debian metadata would be really useful.
Specifically, I'd like to use the description field from the debian control
file (and possibly other fields).

With that in mind:

1.) What is the license of debian control files?

2.) What requirements would I have to meet to include this information on a
web site?

3.) (depending on the answers to the above) Could I use something like CC-by
for the compete database of my site or would that conflict with using
metadata from the debian packages?

Thanks,

Avery

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: Bug#523093: undetermined copyright/license violation

[Francesco Poli]

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: Bug#523093: undetermined copyright/license violation

[Robert Millan]

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

[Robert Millan]

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: 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: Bug#523093: undetermined copyright/license violation

[Francesco Poli]

[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]

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: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)

[Jeff Carr]

On Fri, Apr 10, 2009 at 01:14, Neil Williams  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

[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

Re: Bug#523093: undetermined copyright/license violation

[Anthony W. Youngman]

In message <20090410141624.gb28...@thorin>, Robert Millan 
 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: Bug#523093: undetermined copyright/license violation

[Robert Millan]

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

[Robert Millan]

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

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 

intercambio de enlaces

[Links de Calidad]

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

Re: Bug#523093: undetermined copyright/license violation

[Anthony W. Youngman]

In message <20090410081139.gb27...@thorin>, Robert Millan 
 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

Re: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)

[Neil Williams]

On Thu, 9 Apr 2009 22:34:15 +
"brian m. carlson"  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

[Robert Millan]

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: Bug#523093: undetermined copyright/license violation

[Robert Millan]

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