somebody wrote:
> however, is obfuscating the matter by claiming GPL license limits rights of
> MIT licensees, when in fact, the same software cannot be both GPL licensed
> and a MIT licensed,

What prevents the code from being both MIT licensed and GPL licensed? The 
MIT license, or the GPL license?

Having answered that, can you see where someone would say the GPL is more 
restrictive than the MIT license?

> GPL license perfectly protects the rights of authors who chose it, 

And the conversation is originally about foisting the GPL on authors who 
otherwise would chose a different license. So you can't really say "take 
your pick" when FSF is saying "how can we prevent people from taking their 
pick?"

-- 
   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 <nam### [at] gmailcom> wrote:
> >   I like how GPL fanboys resort to argue about semantics when their "you
> > can use it in any way you want" is proven wrong. Suddenly the term "use"
> > is limited to certain uses, not all of them. Thus, of course, this is a
> > self-contained truth: "GPL code can be used for anything you want, when
> > we define 'use' appropriately."
>
> Using the software is not the same as using the source of the software.
>   That's really where your "semantic" gets skewed.
>
> You can't use the source unmodified as the basis for your software
> without making the larger work a derivative and you can't modify the
> source without release the changes under the GPL as well.  That's the
> only 2 restrictions of the GPL and they don't cover *usage* of the
> software, which *is* unrestricted for any purposes.
>
> There's no fanboyism, just logic.

There's a problem with this logic, lying in the definition of "use".

If I develop an application by modifying an existing one, I'm definitely using
source code. No argument here.

If I develop an application that "uses" a certain library by statically linking
to it - am I *using* the source code here, or am I rather *using* the library
via its well-defined interface?

If I recompile the library and then link it into my binary, the question is
quite clear: I *am* using the source code, because otherwise I couldn't
recompile it. And If I distribute my software in binary format, the question is
rather moot anyway, as I agree that in this case the whole binary can easily be
seen as a single work, of which the library is an inseparable part. After all,
it's one single file.

Now what if I develop an application that "uses" a certain library by
*dynamically* linking to it?

Obviously I'm no longer using the *source code* here - except for the header
files; it can be argued whether these are merely a formal description of the
library API, or part of the library source code, but in the latter case I could
still re-write the header files from scratch according to the API.

So am I not in fact just *using* the software, instead of developing a
derivative work?

What if I don't distribute the library along with my application, and instead
advise the user to get them somewhere else?

What if my application links the library in a way that it will still run if it
isn't present on the target system?

In all these cases, I see GPL still claiming rights on my application by *their*
definition of "derivative work".

However, where's the borderline between this and, say, *using* the API of an
operating system? The command line interface of another application? An
application installed somewhere else in the world-wide web?

It's all a question of borderline, and I think the FSF's interpretation of this
borderline is in itself "borderline", if not already *far* beyond.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> But since the conversation at this point has become a conversation comparing
> the restrictions in the GPL license to the restrictions in other licenses,
> you're not really adding anything to the conversation except disinformation.

Thanks for pointing this out. I guess the world badly needed this post of yours,
huh? :P

Please let the readers decide for themselves whether my posts add anything to
the conversation, right?

Thanks.

Post a reply to this message

clipka wrote:
> Darren, you definitely misunderstood me ;)

Yes I did. Sorry.

> (Unless I'm understanding *you* wrong and what you're currently saying is that I
> have no idea of what the FSF is really saying.... 

No, I thought you were agreeing with their position. Comes from reading 
posts out of order. :-)

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

clipka escreveu:
> It's all a question of borderline, and I think the FSF's interpretation of this
> borderline is in itself "borderline", if not already *far* beyond.

You're right.  The concept of the GPL was well suited for programs that 
had to be statically linked, when you source code was far more needed. 
Today we have many more options for componentization to which the GPL 
has no clear answer, like building "web2.0" mashups out of loose parts 
communicating over http.  Thus, the measures they're taking with gcc 
plugins.  You're either with us or you're not.

Of couse, for those who don't like the GPL and its measures to assure 
sources are always available, forking is an option as is opting for 
another compiler under another license.

Post a reply to this message

Darren New escreveu:
> nemesis wrote:
>> You can't use the source unmodified as the basis for your software 
>> without making the larger work a derivative
> 
> Can you use the object code unmodified as the basis for your software?

Of course, you can always communicate with it via IPC.  When it's a 
single process, it's a single process.

Post a reply to this message

clipka escreveu:
> Darren New <dne### [at] sanrrcom> wrote:
>> But since the conversation at this point has become a conversation comparing
>> the restrictions in the GPL license to the restrictions in other licenses,
>> you're not really adding anything to the conversation except disinformation.
> 
> Thanks for pointing this out. I guess the world badly needed this post of yours,
> huh? :P
> 
> Please let the readers decide for themselves whether my posts add anything to
> the conversation, right?
> 
> Thanks.

You guys can not even agree with yourselves, let alone on license 
matters... ;)

Post a reply to this message

clipka escreveu:
> "nemesis" <nam### [at] gmailcom> wrote:
>> It's a matter of perspective, of course.  They could very well allow for non-GPL
>> closed-source software to be plugins for gcc, but chose not to.  It's their
>> software and their terms.
> 
> ROFL!!
> 
> That's a *really* good one...
> 
> It's not *THEIR* software - it's the software of many, many, many contributors.

Yes, I'd like to say my software, but thought the pronoum their would 
fit best to the situation, ambiguous as it is.

> So say again, who chose this interpretation of "derivative work"?
> 
> The software authors? I doubt.

They chose it when accepted contributing to a software project born out 
of the FSF efforts.  BTW, I believe the FSF is the copyright owner of 
all gcc and other GNU code.  I don't know if their old policy still 
applies, but they used to accept patches only if authors were willing to 
give them the copyright, so as to "fight" any legal threats.  How evil 
is that, huh? ;)

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> > So say again, who chose this interpretation of "derivative work"?
> >
> > The software authors? I doubt.
>
> They chose it when accepted contributing to a software project born out
> of the FSF efforts.

I'm not sure about the history of the GCC code; however, what you say would mean
that no single line of source code existed to start with before the GCC project
was launched as a GPL project, and no single line of source code was taken from
other, truly free software.

I seriously doubt that this is the case.

Post a reply to this message

Darren New escreveu:
> What prevents the code from being both MIT licensed and GPL licensed? 
> The MIT license, or the GPL license?

The author of the code.  He is the copyright holder and can license 
under MIT, GPL, both or none.  If he licenses under MIT, someone later 
can take it verbatim and release under GPL as well.  If he releases 
under the GPL, no one *but him* can later also release it under MIT 
license or any other.

> Having answered that, can you see where someone would say the GPL is 
> more restrictive than the MIT license?

What is more free?  Something that takes measures to always be free or 
something that is so free that even allows something to not be free anymore?

Post a reply to this message