On Fri, 8 May 2009 14:09:58 -0500, Erik Funkenbusch wrote: > 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 <[email protected]> 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. > > http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF > > "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 > documents? > > 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 > binary. > > 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.
This is exactly what I am trying to say ! People in these groups all seem to have their own interpretation of what the GPL is or isn't. I'm not passing judgment, I am simply saying that the fact these uber threads go on for pages is a good indication that people are confused. _______________________________________________ gnu-misc-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
