[ale] OT: GPL Question

[Byron A Jeff]

> 
> Some PLEASE correct me if I am wrong...  But here is my take on what you
> guys are saying.
> 
> So does that mean if somebody say makes a GPL'd version of winsock.dll
> (for example) and replaces the propriatary version of winsock.dll on
> their windows box with it, everything that is now using the new and
> GPL'd dll is required to take on the GPL license or be sued by the FSF?

Touchy area but no. The LGPL is designed precisely for this situation where
the API already exists but a clone with source code available is released.

GPL'd libraries are to be used (according to RMS) when the library API or
functionality is unique so as to "encourage" others to release their code
as GPL when using uniquely GPL functionality.

> 
> Or back to the web server example... If someone makes a web server
> plugin that is propriatary, and writes it to the plugin API of a
> propritary web server, and someone else loads their module into a web
> server thats GPL'd that uses the same API (and thus works with the
> module), does that mean that someone you do not even know or have
> control over just forced you to GPL your code without you even knowing
> it?

Of course not because since the API is cloned your code isn't a deriviative
work of the GPL code. It's not unique.

It would be a different story if the API only existed for the GPL'd server
and the plugin couldn't run unless it was loaded into the GPL'd server. Then
RMS/FSF would consider it to be a deriviative work.

> 
> I do not understand this license... Really I do not :)  But the way you
> guys are describing the linking process (specificly dynamic) it seems to
> me that noone has control over code that they write anymore.  I can see
> it now, some bastard (well in this case its not a bsatard ;) goes out
> and writes a GPL'd API compatibility layer that allows you to run
> windows programs on Linux (I do not think Wine is GPL'd is it?) thus
> forcing all the windows companies out there to GPL their code... I don't
> think so...  But that does sound like what you guys are talking about...

You're putting the cart before the horse. If there's two implementations,
a proprietary one and a GPL one, then the work cannot be deriviative of only
the GPL implementation because it can run on the propritary one. Almost in
every instance, such implemenations are LGPL'd.

No one can force you to do anything with your code that you wrote. The GPL
only comes into play when you start including/interfacing your code with GPL
code. And if there's a cloned proprietary interface our there that mimics the
GPL interface (or vice versa) then your code cannot be deriviative of the
GPL code.

> 
> I think the only way we will ever know how or if this license will work
> is if someone sues.  And I think that if someone does sue, the license
> may fall apart...  I have not read it myself (nor could I, I do not
> understand legalease AT ALL), but it sounds like it is not a very
> logical license to me.

You've taken it to the edge of sanity, that's why it doesn't make much sense.
The basics still holds true: If you use someone else's GPL code/library, then 
you much GPL. But the converse isn't true (though you're trying to make it so):
if someone links/inserts GPL code into your code, they have to play by your 
rules. They cannot force you to GPL your code because your code doesn't
depend on theirs.

BAJ
> 
> Mike
> 
> On Tue, 2002-09-03 at 08:47, Michael Hirsch wrote:
> > On Fri, 2002-08-30 at 17:48, Andrew Grimmke wrote:
> > > It is my understanding that this is the specific reason that the LGPL
> > > was developed.  So that one could use a free library and not be bound by
> > > the GPL. (lesser also stands for library)
> > 
> > Yes, that was the motivation.  But that was also before dynamic linking
> > was common.  I think most people agree that statically linking to GPLed
> > code requires the GPL for all code.  But the issue for dynamic linking
> > is much more vague.
> > 
> > Matt Asay, in his article, claims that most people agree that
> > dynamically linking to GPLed code does not require GPLing your code.  He
> > says, this, but I couldn't find any justification for this claim other
> > than the fact that Linus and the other kernel developers have agreed
> > that code can make system calls to the GPLed kernel without requiring
> > that the code be GPLed.  This is a far cry from linking GPLed libraries.
> > 
> > I also don't know of any programs that do what Asay is claiming--linking
> > against GPLed libraries.  Lots of proprietary code links against glibc
> > and other LGPLed libraries, but try releasing sealed code that links to
> > readline (a GPLed library) and see how long before the FSF lawyers call
> > you.
> > 
> > I do know of several software companies that dual license their
> > libraries as either proprietary or GPL.  The most prominent example is
> > Troll Tech with their qt library.  They do not agree that you can use
> > their GPL library to develop closed code:
> > 
> >  Why is Qt Free Edition not distributed under the GNU Library (or Lesser) General Public License (LGPL)?
> >  The LGPL is designed to "permit developers of non-free programs to use
> > free libraries" (quote from the LGPL). In other words, if Qt Free
> > Edition were LGPL'd, companies would not have to purchase the
> > Professional or Enterprise Edition in order to make
> > commercial/proprietary software, they could just use the Free Edition,
> > free of charge. That would mean Trolltech would not get the revenue
> > necessary for improving and extending Qt.
> > <http://www.trolltech.com/developer/faqs/free.html#Q2>
> > 
> > I think that you are acting dangerously if you link to GPLed libraries
> > with closed code.  There is a definite case to be made for it, but,
> > unlike Asay, I think there are very few precedents backing up such an
> > action.
> > 
> > You are, however, safe if you link to LGPLed libriries and you may make
> > system calls to the GPLed Linux kernel without risk.
> > 
> > --Michael
> > 
> 
> 
> 
> ---
> This message has been sent through the ALE general discussion list.
> See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
> sent to listmaster at ale dot org.
> 


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.