[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GPL traitor !
From: |
Hadron |
Subject: |
Re: GPL traitor ! |
Date: |
Fri, 08 May 2009 16:02:29 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) |
Alan Mackenzie <acm@muc.de> writes:
> 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.
>
>> 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.
Well, that's clarified it. Hey! Only an idiot would not understand the
GPL eh?
LOL.
--
In view of all the deadly computer viruses that have been spreading
lately, Weekend Update would like to remind you: when you link up to
another computer, you’re linking up to every computer that that
computer has ever linked up to. — Dennis Miller
- Re: GPL traitor !, (continued)
- Re: GPL traitor !, Hyman Rosen, 2009/05/10
- Re: GPL traitor !, Alan Mackenzie, 2009/05/11
- Re: GPL traitor !, Hyman Rosen, 2009/05/11
- Re: GPL traitor !, Alan Mackenzie, 2009/05/11
- Re: GPL traitor !, Hyman Rosen, 2009/05/11
- Re: GPL traitor !, Alexander Terekhov, 2009/05/11
- Re: GPL traitor !, David Kastrup, 2009/05/08
- Re: GPL traitor !, Hyman Rosen, 2009/05/08
- Re: GPL traitor !,
Hadron <=
- Re: GPL traitor !, Tim Smith, 2009/05/08
- Re: GPL traitor !, Alan Mackenzie, 2009/05/09
- Re: GPL traitor !, Erik Funkenbusch, 2009/05/08
- Re: GPL traitor !, Doctor Smith, 2009/05/08
- Re: GPL traitor !, Hyman Rosen, 2009/05/08
- Re: GPL traitor !, David Kastrup, 2009/05/09
- Re: GPL traitor !, Thufir Hawat, 2009/05/10
- Re: GPL traitor !, Hadron, 2009/05/10
- Re: GPL traitor !, David Kastrup, 2009/05/11
- Re: GPL traitor !, Thufir Hawat, 2009/05/11