Jim Henderson escreveu:
> On Wed, 28 Jan 2009 18:46:27 -0800, Darren New wrote:
> 
>> So you said "The GPL only affects those who modify the code." This is
>> factually wrong, as evidenced by my example.
> 
> No, it's not factually wrong.
> 
> I just purchased X-Plane 9.  It uses openAL, openGL and a slew of other 
> libraries.
> 
> X-Plane is a proprietary software package that links to these libraries 
> which IIRC are licensed under the GPL.
> 
> If Austin (the author of X-Plane) had incorporated the libraries into his 
> binary by compiling the code as part, then yes, he would've had to 
> license his whole software package under the GPL.  He didn't and he's 
> within the requirements of using GPL libraries.
> 
> The argument about "linking means you have to release your code under the 
> GPL" has been disproven time and time again.

Hmm, this sounds weird.  You mean dynamic linking an app against a GPL 
lib doesn't require one to GPL the app code as well?  If so, what's the 
point of the LGPL?

And I didn't know OpenGL was GPL'd.  In fact, it's a specification only. 
  Are you talking about the mesa lib?

Post a reply to this message

Jim Henderson wrote:
> You can link to GPL libraries.  There are plenty of examples of this.

Then what's the LGPL for?

Note that OpenAL is apparently LGPL, so it specifically says you can link to 
it without invoking the GPL.

> What you cannot do is incorporate GPL-licensed code into non-GPL licensed 
> code.

Define "incorporate"? Look at the first paragraph of
http://www.fsf.org/licensing/licenses/why-not-lgpl.html

It doesn't sound like the FSF agrees with you.

> There is, AFAIK, one single exception - if you own the code, you can dual-
> license it. 

Unless it's a plug-in for GCC.

> But if you're building something large and you want to leverage code 
> others have written, you have to respect their license terms (whatever 
> that license is, not just if it's GPL).

Agreed. I'm not arguing the GPL is a bad thing, even. I'm simply pointing 
out that a lot of the slogans promoted by FSF supporters are wrong.

The gcc changes aren't aimed at making sure the plug-ins are "free 
software". They're aimed at making sure the plug-ins are "copyleft".

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

nemesis wrote:
> True.  Perhaps I should've written "the copyright owner can always 
> dual-license it", but that would lead to further ambiguity, like in the 
> case of someone submitting code to a large project only to find out it 
> really wouldn't matter to dual code his lone little patch.  What sense 
> does it make to release it in, say, a closed-source license, something 
> that is but a little part of a far larger GPL'd whole and which wouldn't 
> exist independently of it?

It doesn't. I don't think anyone would complain that a patch to the 
internals of the Linux kernel won't get incorporated unless they too are GPLed.

It's major functionalities, like, say, plug-ins, that people might want to 
dual-license.

>>> The original GPLed code can't be closed by anyone, like MIT code.
>>
>> Original MIT code can't be closed by anyone either.
> 
> I thought I said that in that very sentence, but now reading it looks 
> ambiguous, yes.  Sorry.

I see.

>> I agree with all of this. My disapproval is of the attempts to take 
>> code from people that doesn't fall under the GPL and doesn't contain 
>> any code of a GPLed project, and force them to release it under the GPL.
> 
> It doesn't force anyone any more than the GPL forces everyone to use Linux.

No, the GPL doesn't. But that's exactly what the FSF is trying to do for gcc 
plug-ins. Remember where the thread started? Did you read the article that 
was linked? The article was specifically "how can the FSF force gcc plug-ins 
to be released as GPL even if they don't incorporate any GPLed code?"

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

nemesis wrote:
> Hmm, this sounds weird.  You mean dynamic linking an app against a GPL 
> lib doesn't require one to GPL the app code as well?  If so, what's the 
> point of the LGPL?
> 
> And I didn't know OpenGL was GPL'd.  In fact, it's a specification only. 
>  Are you talking about the mesa lib?

OpenAL is also LGPL, as far as I can tell. (They don't actually put the 
license on the web site anywhere.)  You'd think fsf.org would have a FAQ 
section too, or at least have links to the actual licenses off the home page 
somewhere.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Darren New escreveu:
> nemesis wrote:
>> extension for gcc, so without gcc, there would be no plugin of yours.
> 
> This is not true. Someone else may write a gcc-compatible compiler.

Down to the devious plugin architecture?!  I think Duke Nukem Forever 
and HURD are released first, or Wine 2.0 is Vista compatible.

> it may be a large codebase that works for any compiler, and I want it to 
> work for gcc also.

Why?  You don't like the damned GPL stuff, remember?  Why help spread 
it?  Why not tell your users that if they want said functionality 
they'll need to use other, possibly better and unrestricted compiler?

>> So, why would you even write a plugin for gcc in the first place?
> 
> And my Linux application wouldn't exist if I didn't have Linux to run it 
> under. Does that mean my application is GPLed? My apache module wouldn't 
> exist if apache wasn't around. Does that mean my module is GPLed? My 
> PSQL stored procedures wouldn't exist if PSQL wasn't around. That 
> doesn't make my stored procedures GPLed.

Of course, none of those projects require your code to be GPLed.  GCC 
will, and not by the GPL.

BTW, all your examples do not constitute a single program running in the 
same process space, they are very different from app and lib or plugin.

> If every Linux application you wrote was required to use the GPL, would 
> you find software companies like Adobe porting their software to it?

You talk like as if the plugin is an external app running in a "gcc 
kernel space".

> You can certainly license code with a license that says "if you use this 
> compiler, everything you compile with it belongs to us."  As you say, 
> people don't do that, because people wouldn't use the compiler if they did.

GCC doesn't say that, so I don't know how the example is any pertinent.

> I find it interesting that in the areas where FSF *is* the leader, they 
> wind up acting like monopolists.

Like in areas where they are actually the original developers of GNU 
software?  Yeah, sound as bad as Apache...

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> nemesis wrote:
>>> extension for gcc, so without gcc, there would be no plugin of yours.
>>
>> This is not true. Someone else may write a gcc-compatible compiler.
> 
> Down to the devious plugin architecture?! 

Someone may write a word processor compatible down to the undocumented 
binary file format?!?

Maybe someone likes your gcc plug-in so much they want you to port it to 
*their* compiler.  Whoops, sorry! You can't!

>> it may be a large codebase that works for any compiler, and I want it 
>> to work for gcc also.
> 
> Why?  You don't like the damned GPL stuff, remember?

I didn't say that. I said I don't always like what it does to my employment, 
and I said I don't like how the FSF is trying to force unrelated software to 
be GPLed. But most of the developer tools are pretty nice.

> BTW, all your examples do not constitute a single program running in the 
> same process space, they are very different from app and lib or plugin.

I'm not sure what "single address space" has to do with it. Certainly my 
program runs in the same address space as the Linux kernel, or the Linux 
kernel wouldn't be able to fill my buffers with data when I call read().

>> If every Linux application you wrote was required to use the GPL, 
>> would you find software companies like Adobe porting their software to 
>> it?
> 
> You talk like as if the plugin is an external app running in a "gcc 
> kernel space".

It is, as much as FLASH is. It's an "external app" in that it doesn't 
incorporate any of the code from GCC into itself.

>> You can certainly license code with a license that says "if you use 
>> this compiler, everything you compile with it belongs to us."  As you 
>> say, people don't do that, because people wouldn't use the compiler if 
>> they did.
> 
> GCC doesn't say that, so I don't know how the example is any pertinent.

Right. I was trying to explain *why* it doesn't say that, even tho it could 
say that with at least as much authority as the plug-in architecture could.

>> I find it interesting that in the areas where FSF *is* the leader, 
>> they wind up acting like monopolists.
> 
> Like in areas where they are actually the original developers of GNU 
> software?  

No, like in areas where the product is so good it has pushed most 
competitors out. Like, Sun shipping the gcc compiler instead of continuing 
to improve their own.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Darren New escreveu:
>  You can
> prevent me from distributing your code in ways you don't like, but 
> that's true of every license.

What isn't true of every license is that it lets you use software for 
any purposes *or* modify or make it as basis for other software as long 
as you release it all under the same license too.

Post a reply to this message

On Fri, 30 Jan 2009 11:32:19 -0800, Darren New wrote:

> Jim Henderson wrote:
>> You can link to GPL libraries.  There are plenty of examples of this.
> 
> Then what's the LGPL for?

Provides some additional options.

> Note that OpenAL is apparently LGPL, so it specifically says you can
> link to it without invoking the GPL.

Yes, but again, linking to something that's GPL'ed doesn't mean your 
program has to be GPL'ed.  I used OpenAL as an example, probably not the 
best example given that it is LGPL.

>> What you cannot do is incorporate GPL-licensed code into non-GPL
>> licensed code.
> 
> Define "incorporate"? Look at the first paragraph of
> http://www.fsf.org/licensing/licenses/why-not-lgpl.html

I write this:

void main(void)
{
	puts("do something here");
	/* Call a bunch of other functions */
}

You write code and you use some/all of my code in your code.  My code is 
released under the GPL, now yours must be as well because you're using 
the source code I wrote in your code/product.

> It doesn't sound like the FSF agrees with you.
> 
>> There is, AFAIK, one single exception - if you own the code, you can
>> dual- license it.
> 
> Unless it's a plug-in for GCC.

Well, argue that with the GNU foundation, I would agree that the root of 
this debate is suspicious.  It seems, though, they're trying to do 
something similar to the Linux kernel's "tainted" flag with the compiler, 
but pushing it to a new level.

>> But if you're building something large and you want to leverage code
>> others have written, you have to respect their license terms (whatever
>> that license is, not just if it's GPL).
> 
> Agreed. I'm not arguing the GPL is a bad thing, even. I'm simply
> pointing out that a lot of the slogans promoted by FSF supporters are
> wrong.
> 
> The gcc changes aren't aimed at making sure the plug-ins are "free
> software". They're aimed at making sure the plug-ins are "copyleft".

Well, as the authors of gcc, surely they have the right to extend the 
license terms in whatever way they see fit.

Jim

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:49834830$1@news.povray.org...

> The thing that's "getting ridiculous" is when people go out of their way
to
> apply the GPL to *your* code when it *isn't* a derivative of any GPLed
code.
> See how that works?

No, I don't. How is it even possible for *others* to GPL *your* code? It's
only you who can do that.

Post a reply to this message

On Fri, 30 Jan 2009 17:19:54 -0200, nemesis wrote:

> Jim Henderson escreveu:
>> On Wed, 28 Jan 2009 18:46:27 -0800, Darren New wrote:
>> 
>>> So you said "The GPL only affects those who modify the code." This is
>>> factually wrong, as evidenced by my example.
>> 
>> No, it's not factually wrong.
>> 
>> I just purchased X-Plane 9.  It uses openAL, openGL and a slew of other
>> libraries.
>> 
>> X-Plane is a proprietary software package that links to these libraries
>> which IIRC are licensed under the GPL.
>> 
>> If Austin (the author of X-Plane) had incorporated the libraries into
>> his binary by compiling the code as part, then yes, he would've had to
>> license his whole software package under the GPL.  He didn't and he's
>> within the requirements of using GPL libraries.
>> 
>> The argument about "linking means you have to release your code under
>> the GPL" has been disproven time and time again.
> 
> Hmm, this sounds weird.  You mean dynamic linking an app against a GPL
> lib doesn't require one to GPL the app code as well?  If so, what's the
> point of the LGPL?

I don't believe it does.  But I've not done an in-depth look at the 
differences between GPL and LGPL.  I have read a lot of discussions about 
it, though.

> And I didn't know OpenGL was GPL'd.  In fact, it's a specification only.
>   Are you talking about the mesa lib?

D'oh!  Yes, Mesa is what I'm talking about, it provides libGL.  However, 
Mesa is X11/MIT licensed.

Jim

Post a reply to this message