gnupic: Thread: Re: [gnupic] GCC port for PIC

I'm not sure why I'm bothering to argue this any more as you clearly  
don't believe I know what I'm talking about. Good luck persuading  
Microchip (and Rowley, and Keil, and all the other toolchain vendors  
selling products based around GCC) that their legal departments have  
interpreted the GPL incorrectly and they need to GPL their  
proprietary libraries and IDEs because they've distributed them in  
the same package as GCC. One last time...

On 5 Apr 2006, at 13:49, Colm O' Flaherty wrote:
> I think thats a good summary of our interpretations...   The PICC- 
> gcc compiler (as opposed to the C30 package which contains it) is  
> certainly a "modified work".. no argument there.  Why isn't the C30  
> package (and its distributed in such a fashion) which contains the  
> PIC-gcc compiler also a "modified work" then?  It seems to fit the  
> criteria.

Because it falls under the aggregation clause. Microchip's C library  
isn't a derivative work of GCC because it wasn't created by taking  
GCC's code and modifying it. Distributing the two works together in  
one package doesn't create a single work that is derivative of both  
GCC and the C library. A package file is simply a way of conveniently  
distributing multiple works at the same time, and is equivalent to a  
CD ROM or a tape archive (.tar files anyone?). You wouldn't say that  
every program on a linux distribution CD must be covered by the GPL  
because some of the programs on it are GPLed and bundling them  
together creates a single derivative work would you?

> And why would the GPL say "These requirements apply to the modified  
> work as a whole." if you don't mean the package that contains GNU CC?

That means you're not supposed to only distribute the source code to  
part of a modified work, you need to distribute the source to the  
whole work. It doesn't say anything about other non-GPLed works that  
are included in the same package file as the GPLed work.

> http://www.fsf.org/licensing/licenses/gpl- 
> faq.html#GPLRequireSourcePostedPublic
> See the following:
> - Does the GPL allow me to distribute a modified or beta version  
> under a nondisclosure agreement?
> - I heard that someone got a copy of a GPL'ed program under another  
> license. Is this possible?
> - If I add a module to a GPL-covered program, do I have to use the  
> GPL as the license for my module?

Not relevant to this case. They're not using an NDA as far as I'm  
aware, they're not releasing a GPLed work under a different license,  
and they're not adding modules to a GPLed program.

> - What is the difference between "mere aggregation" and "combining  
> two modules into one program"?

This explains why what Microchip are doing is mere aggregation, not  
combining two modules into one program.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

Alex Holden wrote:
> I'm not sure why I'm bothering to argue this any more as you clearly  
> don't believe I know what I'm talking about. Good luck persuading  
> Microchip (and Rowley, and Keil, and all the other toolchain vendors  
> selling products based around GCC) that their legal departments have  
> interpreted the GPL incorrectly and they need to GPL their  proprietary 
> libraries and IDEs because they've distributed them in  the same package 
> as GCC. One last time...

Why don't we submit the problem to the FSF? Let's write to ####@####.#### 
(or even ####@####.#### describing the case and giving the 
necessary links, and see what they say.

Ciao,
Marco

-- 
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

On Wed, 2006-04-05 at 16:12 +0200, Marco Pantaleoni wrote:

> Why don't we submit the problem to the FSF? Let's write to ####@####.####
> (or even ####@####.#### describing the case and giving the
> necessary links, and see what they say.

Marco,

The reason no one will submit this to the FSF is, as Alex *clearly*
explains, Microchip is not in violation.

Scott

Hey, Alex, relax.. I was looking for answers, and now I seem to be getting 
them.  Nothing personal. ok?

I was prepared to agree to differ earlier, but you seemed to want to 
continue the discussion then too.. :)

Having said that, the weight of the argument now seems to be in your favour, 
so I'll just have to absorb whats been said..

>From: Alex Holden ####@####.####
>Reply-To: ####@####.####
>To: ####@####.####
>Subject: Re: [gnupic] GCC port for PIC
>Date: Wed, 5 Apr 2006 15:05:01 +0100
>
>I'm not sure why I'm bothering to argue this any more as you clearly  don't 
>believe I know what I'm talking about. Good luck persuading  Microchip (and 
>Rowley, and Keil, and all the other toolchain vendors  selling products 
>based around GCC) that their legal departments have  interpreted the GPL 
>incorrectly and they need to GPL their  proprietary libraries and IDEs 
>because they've distributed them in  the same package as GCC. One last 
>time...
>
>On 5 Apr 2006, at 13:49, Colm O' Flaherty wrote:
>>I think thats a good summary of our interpretations...   The PICC- gcc 
>>compiler (as opposed to the C30 package which contains it) is  certainly a 
>>"modified work".. no argument there.  Why isn't the C30  package (and its 
>>distributed in such a fashion) which contains the  PIC-gcc compiler also a 
>>"modified work" then?  It seems to fit the  criteria.
>
>Because it falls under the aggregation clause. Microchip's C library  isn't 
>a derivative work of GCC because it wasn't created by taking  GCC's code 
>and modifying it. Distributing the two works together in  one package 
>doesn't create a single work that is derivative of both  GCC and the C 
>library. A package file is simply a way of conveniently  distributing 
>multiple works at the same time, and is equivalent to a  CD ROM or a tape 
>archive (.tar files anyone?). You wouldn't say that  every program on a 
>linux distribution CD must be covered by the GPL  because some of the 
>programs on it are GPLed and bundling them  together creates a single 
>derivative work would you?
>
>>And why would the GPL say "These requirements apply to the modified  work 
>>as a whole." if you don't mean the package that contains GNU CC?
>
>That means you're not supposed to only distribute the source code to  part 
>of a modified work, you need to distribute the source to the  whole work. 
>It doesn't say anything about other non-GPLed works that  are included in 
>the same package file as the GPLed work.
>
>>http://www.fsf.org/licensing/licenses/gpl- 
>>faq.html#GPLRequireSourcePostedPublic
>>See the following:
>>- Does the GPL allow me to distribute a modified or beta version  under a 
>>nondisclosure agreement?
>>- I heard that someone got a copy of a GPL'ed program under another  
>>license. Is this possible?
>>- If I add a module to a GPL-covered program, do I have to use the  GPL as 
>>the license for my module?
>
>Not relevant to this case. They're not using an NDA as far as I'm  aware, 
>they're not releasing a GPLed work under a different license,  and they're 
>not adding modules to a GPLed program.
>
>>- What is the difference between "mere aggregation" and "combining  two 
>>modules into one program"?
>
>This explains why what Microchip are doing is mere aggregation, not  
>combining two modules into one program.
>
>--
>------------ Alex Holden - http://www.alexholden.net/ ------------
>If it doesn't work, you're not hitting it with a big enough hammer
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>

Scott Dattalo wrote:
> On Wed, 2006-04-05 at 16:12 +0200, Marco Pantaleoni wrote:
> 
> 
>>Why don't we submit the problem to the FSF? Let's write to ####@####.####
>>(or even ####@####.#### describing the case and giving the
>>necessary links, and see what they say.
> 
> 
> Marco,
> 
> The reason no one will submit this to the FSF is, as Alex *clearly*
> explains, Microchip is not in violation.
> 
> Scott

I don't want to throw fuel at the discussion, but I'm not completely 
convinced by the explanation. From my admittely ingnorant POV, I'm 
inclined to believe that the aggregation clause is thought for the case 
of distribution of completely independent software on the same medium 
(CD-ROM, ...), and it seems to me that the libraries (*.a) and header 
files are not that completely independent. Without the compiler they are 
of little use, and the compiler without those too is not that useful.
These items complements each other, and they seem to form a "whole".

But IANAL, and I'm ignorant too, so I'll consider your opinions more 
informed than mine. I just wanted to express my doubts.
Ciao,
Marco

-- 
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

I don't see why we shouldn't ask the FSF directly.  I, for one, would like a 
"from the horses mouth" statement, (from the FSF) of what Microchips rights 
and obligations are in this particular case.

If I was wrong, then I'd like to know in what respect I was wrong.  If a 
couple of intelligent people are questioning the meaning of the GPL in a 
particular case such as this, then I think it warrants a reasonable 
clarification of the situation from the FSF itself.  If the FSF doesn't get 
a chance to clarify things, I think it will be to its loss.

Personal opinions on this will always differ.. thats fair enough.  I have no 
issue accepting someone elses opinion on this if they can logically reason 
it out to me, and can reasonably explain away my concerns or questions.  
Right now, I personally don't feel that has happened here (for me, at 
least).

Colm

On 11 Apr 2006, at 13:54, Colm O' Flaherty wrote:
> I don't see why we shouldn't ask the FSF directly.  I, for one,  
> would like a "from the horses mouth" statement, (from the FSF) of  
> what Microchips rights and obligations are in this particular case.

Nobody's stopping you from asking them yourself.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer