[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPL traitor !

From: Erik Funkenbusch
Subject: Re: GPL traitor !
Date: Fri, 8 May 2009 14:09:58 -0500
User-agent: 40tude_Dialog/

On Fri, 8 May 2009 09:58:11 +0000 (UTC), Alan Mackenzie wrote:

> Hi, Erik!
> It's good to talk to somebody with a name.  :-)
> In gnu.misc.discuss Erik Funkenbusch <> wrote:
>> The GPL is misunderstood on a daily basis by many people.  In fact,
>> even GPL advocates can't seem to come to a consensus over what it
>> means, so how is any "normal" person supposed to know?
>> Here's an example.  Some GPL advocates believe that dynamic linking is
>> not covered by the GPL, while others (including the FSF) believe it is.  
> Dynamic linking, along with static linking, compilation, interpretation,
> profiling, and other specific techniques used by hackers are not covered
> by the GPL - they're outside its scope, and would be more of matter of
> patents than a copyright license, were they patentable.

Gee, you should really tell the FSF that.

"If the program dynamically links plug-ins, and they make function calls to
each other and share data structures, we believe they form a single
program, which must be treated as an extension of both the main program and
the plug-ins. This means that combination of the GPL-covered plug-in with
the non-free main program would violate the GPL."

Funny, but even YOU don't seem to understand the GPL that nobody could
possibly misunderstand.  Or maybe it's the FSF that doesn't understand it.

You're not doing a good job of proving your point.

>> Another example is XMLRPC (or SOAP or other similar technoloties) in
>> which a function is called via network request on a distributed system.
>> Some believe that this is covered by the GPL, others believe it isn't.
> I'll assume that by "this" you mean the invocation of a GPL licensed
> function over a network, or a GPL licensed program invoking something
> over a network.
> The GPL doesn't differentiate between calling technoloties.  It's _what_
> gets called that matters, not the technoloty by which it gets called;
> whether the thing getting called is a program independent of what's
> calling it, or is really part of it.  The same applies to functionality
> in a separately compiled library.
> It is not always quite clear whether a library function or network
> function is "an independent program".  That's just life; software isn't
> simple and the GPL can't make it so.
> The GPL doesn't distinguish between calling methods for a good reason,
> namely it would allow anybody to incorporate GPL code into his
> proprietary program.  All he would have to do is make his proprietary
> extension callable via a network call (say, a BSD socket, much like
> X-Windows does (I think)), and then publish the source code only for
> the GPL bit, to which he's added a network call.

Yet you can do the exact same thing by making the program into an
executable that gets called from the command line.  Again, your argument
just doesn't stand up.  

The GPL is vague, and frequently misunderstood.  

>> Many people think the GPL prevents you from charging money for GPL
>> software, yet the FSF says they encourage you to do so.
> A less intelligent, less literate class of people, perhaps.

You mean like judges?  Those that make it their job to interpret legal

There was a recent lawsuit in which the judge's ruling stated that you
could not charge a fee for GPL code.  I can't seem to find the right search
terms to locat it right now, but it was quoted several times here in COLA.

> SuSE, Redhat,
> and friends have been charging money "for" GPL software for years.  You
> may charge money for distributing GPL software, or for offering support.
> You may not charge money for a GPL license.  A slightly subtle difference,
> but really not all that hard to grasp for people who've actually read the
> GPL.

Actually, no.  The GPL says nothing about charging for the license.
However, in effect that is correct.  The FSF says you can charge any fee
you like for the software.

>From the FSF:

"Does the GPL allow me to sell copies of the program for money?

Yes, the GPL allows everyone to do this. The right to sell copies is part
of the definition of free software. Except in one special situation, there
is no limit on what price you can charge. (The one exception is the
required written offer to provide source code that must accompany
binary-only release.) "

The point is, many people think the GPL only allows you to charge a
"nominal fee" for the software, when in fact the GPL says you may only
charge a noninal fee to distribute the source.  It says nothing about the
fee to sell the program.

>> Many people think the GPL requires you to "give back" your changes to
>> the author, but nothing could be further from the truth.  Even if you
>> consider the GPL's software requirements to provide source to anyone
>> you provide binaries that doesnt' require you to give that source to
>> the upstream authors, only the downstream customers.
> That might be true, but is of piffling importance.  Generally, the author
> can get the binary just like anybody else, hence is entitled to get the
> source corresponding to that binary.

Nope.  He is not entitled to anything, *UNLESS* he's given a copy of the

Again, from the FSF:

"If I know someone has a copy of a GPL-covered program, can I demand he
give me a copy?

No. The GPL gives him permission to make and redistribute copies of the
program if he chooses to do so. He also has the right not to redistribute
the program, if that is what he chooses."

>> So no, the GPL is *NOT* perfectly plain and straight forward.  And yes,
>> you do need a lawyer to explain it to you, particulary when the issues
>> of "derived work" are brought up, since the GPL does not define the
>> term and relies on the accepted legal definition of the term, which is
>> not as simple as it would seem.
> Of course the GPL relies on the legal definition of "derived work", since
> the notion of creating derived works is central to it.  That this can be
> complicated, particularly at boundary cases, is simply a reflection of
> the real world.  But that complexity lies outside of the GPL - the world
> of copyright law is complex, and it's clearly unreasonable to expect the
> GPL somehow to eliminate that complexity.

That is what you are implying when you say that nobody can misunderstand
the GPL.  Because not all terms the GPL uses are defined by the document
itself, it's impossible for everyone to fully understand it because
interpretations will be different.

> That said, it's usually fairly easy for somebody acting in good faith to
> see whether some piece of software is derived from GPL software.  The
> difficulties arise when somebody not acting in good faith attempts to
> find some loophole through which she can legally violate the intention
> and spirit of the GPL.

Even the spirit of the GPL is not fully understood.  We have a good idea of
what the FSF thinks the spirit is, but many other people, including die
hard GPL advocates disagree with the FSF.

Larry Rosen, for instance.

>> The only people who do *NOT* find the GPL difficult to understand are
>> those thoat think they understand it when they really do not.
> That's a wild thing to say.  I think you're failing to distinguish the
> GPL, which is easy to understand, with the wider chaos of copyright and
> licensing law, which is anything but.

You cannot understand the GPL without understanding the wider chaos of
copyright law.  That's why the GPL is not easy to understand.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]