gnu-misc-discuss
[Top][All Lists]
Advanced

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

Re: GPL traitor !


From: Rjack
Subject: Re: GPL traitor !
Date: Fri, 08 May 2009 07:41:40 -0400
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

Alan Mackenzie wrote:
Hi, Erik!

It's good to talk to somebody with a name.  :-)

In gnu.misc.discuss Erik Funkenbusch <erik@despam-funkenbusch.com> 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.

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.

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

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.

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

It is extremely difficult to convince a U.S. federal court to enforce
a copyright license that violates statutory federal copyright law as
well as state common laws. No plaintiff has ever followed through on
an attempt to convince a U.S. court to do so. Just check the record
for the SFLC and FSF in the Second Circuit. To wit:

1. Dismissal Without Prejudice.

2. Dismissal Without Prejudice.

3. Dismissal Without Prejudice.

4. Dismissal WITH PREJUDICE.

5. Dismissal Without Prejudice.

6. Dismissal Without Prejudice.

7. Dismissal Without Prejudice.

8. Dismissal WITH PREJUDICE.


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.



reply via email to

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