[om-list] Re: GPL vs. LGPL

[Tom and other Packers]

Mark

    Regarding licensing for MTShell, I will have to read up a little more
and then talk to you in person about licensing.  I'll let you know when I'm
ready, if you're willing and able to have another meeting.

    Anyone else who is interested in the MTShell project (Ben Oman) can
join.

tomp

----- Original Message -----
From: "Mark Butler" <butlerm at middle.net>
To: "Tom and other Packers" <TomP at burgoyne.com>
Sent: Thursday, October 04, 2001 1:24 PM
Subject: Re: GPL vs. LGPL


Tom,

 The L in LGPL used to stand for library, but now it stands for
lesser.  It is usually used for libraries, but since every well
written program looks like a collection of semi-independent modules,
it is relevant there as well.  You can GPL the main program file and
LGPL usable modules if you want.

The people who invented these licenses did not write them to restrict
you, but rather to protect you.  If you wrote the code you can do
whatever you want with it, GPL license to others notwithstanding. The
GPL license is designed to keep *others* from using your code in a
proprietary closed source product.

Now, if you want to use outsiders contributions in your project the
LGPL or MPL is more appropriate.  However, if you choose the MPL you
should dual license it under the GPL because otherwise open source
authors will be not be able to link it with prominent GPL libraries
like Qt.

I personally happen to write all my future open source GUI programs
using the Qt library, so dual licensing is a personal requirement for
me to contribute.

 - Mark

Tom and other Packers wrote:
>
> Mark
>
>     I thought L=library in LGPL.  So that's why glibc uses that licence.
> I'm suspecting that LGPL is not as flexible as MPL, because it was borne
out
> of a need for a specific flexibility, regarding only libraries; so I'm
> assuming that it made no attempt to regain other types of flexibilities
not
> relevant to libraries -- although I haven't studied enough to figure out
> what those restrictions might be.
>
> tomp
>
> ----- Original Message -----
> From: "Mark Butler" <butlerm at middle.net>
> To: "Tom and other Packers" <TomP at burgoyne.com>
> Cc: "One Model List" <om-list at onemodel.org>
> Sent: Wednesday, October 03, 2001 1:29 PM
> Subject: Re: GPL vs. LGPL
>
> Tom,
>
>   The LGPL (Lesser GPL) does not have viral properties like the GPL
> does.  You can link LGPL modules to GPL and proprietary modules - that
> is why I recommend it in this case.
>
> A real world example is the GNU C Library (glibc) - if is was not
> LGPL, no one (e.g. Oracle) would be able to compile and distribute
> proprietary software with the GNU C compiler (gcc).  Most critical
> open source infrastructure libraries are LGPL for this very reason.
>
> However, due to the ability for companies to license their *own* code
> under looser terms to paying customers, the GPL can actually protect
> commercial interests better than the LGPL / MPL. Trolltech has
> alternate for their very nice Qt toolkit - normally GPL, proprietary
> for paying customers - which forces anyone writing a closed source
> product (except themselves, of course) to pay for a license.  Anyone
> writing a true GPL product can use it for free.  If Qt were LGPL, most
> of their current license revenue would dry up, because most commercial
> customers do not really need $1000/year of technical support for a C++
> class framework. On the other hand, if it were LGPL, it would probably
> dominate the proprietary Unix software world in a matter of months.
>
> The only real reason to combine licenses is to overcome unusual legal
> technicalities (e.g. choice of venue) that keep many open source
> software licenses from being compatible with the GPL.  Since licensing
> code under the GPL is more restrictive than any of the other true open
> source licenses, this type of multiple license has little real effect
> other than making it possible to use such software in GPL projects.
> Since the GPL dominates the free software world, this makes life a lot
> easier.
>
> - Mark

--
Mark Butler        ( butlerm at middle.net )
Software Engineer
Epic Data Systems
(801)-451-4583