LGPL versus MPL

15 views
Skip to first unread message

Robin Green

unread,
Mar 28, 1999, 3:00:00 AM3/28/99
to
I know this must have been discussed before, but browsing dejanews archives I
couldn't find a really good analysis of this question:

I want to write free ("freed") software, in the sense used by the Free
Software Foundation (www.fsf.org) whilst avoiding the GPL because of
license-virus effects. Should I use the Mozilla Public License (MPL) or the
GNU Library General Public License (LGPL)?

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Eleftherios Gkioulekas

unread,
Mar 28, 1999, 3:00:00 AM3/28/99
to
Robin Green <gove...@my-dejanews.com> writes:

> I know this must have been discussed before, but browsing dejanews archives I
> couldn't find a really good analysis of this question:
>
> I want to write free ("freed") software, in the sense used by the Free
> Software Foundation (www.fsf.org) whilst avoiding the GPL because of
> license-virus effects. Should I use the Mozilla Public License (MPL) or the
> GNU Library General Public License (LGPL)?

Have you read the articles in http://www.gnu.org/philosophy/?
The essay by Bruce Perens in Open Sources also covers these issues.

I think that you should at least use the LGPL, so that GPLed works
can link to your library. If you have a good reason for prefering the
MPL, and you can articulate to yourself the reason, then it would
still be nice to double license under the LGPL too. The most likely reason
for using the MPL is if you want to contribute to Mozilla, or make
your code available for inclusion in Mozilla.

Elef.
--
Eleftherios Gkioulekas | "The truth points to itself"
http://www.amath.washington.edu/~lf/ | --Kosh

Daniel Veditz

unread,
Mar 31, 1999, 3:00:00 AM3/31/99
to
Eleftherios Gkioulekas wrote:
>
> Robin Green <gove...@my-dejanews.com> writes:
>
> > I know this must have been discussed before, but browsing dejanews archives I
> > couldn't find a really good analysis of this question:
> >
> > I want to write free ("freed") software, in the sense used by the Free
> > Software Foundation (www.fsf.org) whilst avoiding the GPL because of
> > license-virus effects. Should I use the Mozilla Public License (MPL) or the
> > GNU Library General Public License (LGPL)?
>
> Have you read the articles in http://www.gnu.org/philosophy/?
> The essay by Bruce Perens in Open Sources also covers these issues.
>
> I think that you should at least use the LGPL, so that GPLed works
> can link to your library. If you have a good reason for prefering the
> MPL, and you can articulate to yourself the reason, then it would
> still be nice to double license under the LGPL too. The most likely reason
> for using the MPL is if you want to contribute to Mozilla, or make
> your code available for inclusion in Mozilla.

Mozilla can include LGPL code (but not GPL code) so that shouldn't be an
important factor in your decision.

LGPL would require anyone who changes your library to publish their
changes, MPL would allow some kinds of proprietary changes. In both
cases someone could use the library from proprietary code so the end
result could be the same.

The two licenses handle patent/IP issues differently if that's an issue
for you.

-Dan Veditz

Richard E. Hawkins Esq.

unread,
Apr 5, 1999, 3:00:00 AM4/5/99
to
In article <7dk00t$ul0$1...@nnrp1.dejanews.com>,

Robin Green <gove...@my-dejanews.com> wrote:
>I know this must have been discussed before, but browsing dejanews archives I
>couldn't find a really good analysis of this question:
>
>I want to write free ("freed") software, in the sense used by the Free
>Software Foundation (www.fsf.org) whilst avoiding the GPL because of
>license-virus effects. Should I use the Mozilla Public License (MPL) or the
>GNU Library General Public License (LGPL)?

How about Raptor? "You can do anything you damned well feel like with
this code, as long as you provide the source code on the same terms
as any binary upon redistribution."

No virus, no annexation, no taking code proprietary. And no later
author making your work viral, as happens when GPL products slurp up
bsd code.

--
These opinions will not be those of ISU until it pays my retainer.

Alan McLean

unread,
Apr 5, 1999, 3:00:00 AM4/5/99
to
Richard E. Hawkins Esq. <ha...@eyry.econ.iastate.edu> wrote:
>
> No virus, no annexation, no taking code proprietary. And no later
> author making your work viral, as happens when GPL products slurp up
> bsd code.

The GPL and BSDL are mutually exclusive due to the advertising
clause.

s/bsd/MIT and similarly licensed (BSDL minus #3)/

-amcl

Roger Espel Llima

unread,
Apr 5, 1999, 3:00:00 AM4/5/99
to
In article <aw7O2.581$tz2...@news.flash.net>,

And, more importantly, GPL does NOT "viralize" or "infect" MIT-L (or
XFree-L) code.

You're always as free to take the MIT-licenced code out of the GPL
product, and use all the freedom the MIT-licence gives you on it. It's
only the combination (including the GPL bits) that is being distributed,
as a whole, under the terms of the GPL.

I wish people would stop making this stupid claim that the GPL applies
to code that wasn't GPL'd to begin with. That is simply not the case,
and I doubt copyright law would even allow something like it.

--
Roger Espel Llima, es...@llaic.u-clermont1.fr
http://www.eleves.ens.fr:8080/home/espel/index.html

Lynn Winebarger

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <7ebgkv$f6n$1...@nef.ens.fr>,

Roger Espel Llima <es...@news.ens.fr> wrote:
>And, more importantly, GPL does NOT "viralize" or "infect" MIT-L (or
>XFree-L) code.
>
>You're always as free to take the MIT-licenced code out of the GPL
>product, and use all the freedom the MIT-licence gives you on it. It's
>only the combination (including the GPL bits) that is being distributed,
>as a whole, under the terms of the GPL.
>

Actually, you're not. You can always go and find another copy of the
original code, and use that under the original license, but the XFree86
license gives specific permission to sublicense a particular
distribution of the code any way you want. That means you can place
your distribution under the GPL, and it's all under the GPL. That
doesn't mean that their aren't other distributions (possibly of exactly
the same software) that might be under different licensing conditions.

>I wish people would stop making this stupid claim that the GPL applies
>to code that wasn't GPL'd to begin with. That is simply not the case,
>and I doubt copyright law would even allow something like it.
>

Licenses do not apply to the code itself (per se) but only to a
particular copy of the code that's distributed under that license. You
don't need to own a copyright to put the GPL on something, you only need
the (delegated) right to license it. Which XFree86 gives you.

Lynn

Roger Espel Llima

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <7ebjk0$fv1$1...@flotsam.uits.indiana.edu>,

Lynn Winebarger <owin...@ezinfo.ucs.indiana.edu> wrote:
> Licenses do not apply to the code itself (per se) but only to a
>particular copy of the code that's distributed under that license. You
>don't need to own a copyright to put the GPL on something, you only need
>the (delegated) right to license it. Which XFree86 gives you.

I still don't see how this distinction can be relevant in the world of
free software. If I go download a copy of GNUWhatever and use a bit of
XFreesomething from it, or if I go download a copy of XFreesomething
directly, the code I end up with is the same. Since, in both cases,
no-one has been paid, notified, or in commercially interacted with in
any way, I don't see how this distinction could have any value here.

If we want to make the distinction really clear though: how would one
actually distinguish if the XFree-ish code has been actually
sublicenced? You have the right, but does it happen "automatically"
just by cut'n'pasting it into a GPL project (and keeping the original
copyright mention)? If it does, then how does one make it clear that
the intent is *not* to sublicence, but to keep each bit as free as it
originally came?

Sam Holden

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
On 6 Apr 1999 00:33:54 GMT, Roger Espel Llima <es...@news.ens.fr> wrote:
>In article <7ebjk0$fv1$1...@flotsam.uits.indiana.edu>,
>Lynn Winebarger <owin...@ezinfo.ucs.indiana.edu> wrote:
>> Licenses do not apply to the code itself (per se) but only to a
>>particular copy of the code that's distributed under that license. You
>>don't need to own a copyright to put the GPL on something, you only need
>>the (delegated) right to license it. Which XFree86 gives you.
>
>I still don't see how this distinction can be relevant in the world of
>free software. If I go download a copy of GNUWhatever and use a bit of
>XFreesomething from it, or if I go download a copy of XFreesomething
>directly, the code I end up with is the same. Since, in both cases,
>no-one has been paid, notified, or in commercially interacted with in
>any way, I don't see how this distinction could have any value here.

Because you are fundamentally an honest person? And thus wouldn't
violate the license. And it doesn't take much effort to download the
original XFreesomething and so sleep better at night.

--
Sam

We prefer English to remain a rich language, quirky, sloppy, and full
of redundancy. Same for Perl.
--Larry Wall

Steven Blunt

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
On 5 Apr 1999 10:35:05 -0500, in gnu.misc.discuss

ha...@eyry.econ.iastate.edu (Richard E. Hawkins Esq.) wrote:

>How about Raptor? "You can do anything you damned well feel like with
>this code, as long as you provide the source code on the same terms
>as any binary upon redistribution."
>

>No virus, no annexation, no taking code proprietary. And no later
>author making your work viral, as happens when GPL products slurp up
>bsd code.

I don't see why the GPL couldn't "slurp up" that licence, there's nothing
there that makes it incompatable.

cya

Lynn Winebarger

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <7ebkpi$j7i$1...@nef.ens.fr>,

Roger Espel Llima <es...@news.ens.fr> wrote:
>I still don't see how this distinction can be relevant in the world of
>free software. If I go download a copy of GNUWhatever and use a bit of
>XFreesomething from it, or if I go download a copy of XFreesomething
>directly, the code I end up with is the same. Since, in both cases,
>no-one has been paid, notified, or in commercially interacted with in
>any way, I don't see how this distinction could have any value here.

You're correct in that probably no one will come to your door and
demand you put it under GPL, as long as you only used the code from the
original package and not any bits that we're contributed under GPL. But
the distinction exists just as much as if you bought a copy of the code
from a vendor who put it under a restrictive proprietary license - I
don't see how GNU not busting your chops about it makes the distinction
go away.

>
>If we want to make the distinction really clear though: how would one
>actually distinguish if the XFree-ish code has been actually
>sublicenced? You have the right, but does it happen "automatically"
>just by cut'n'pasting it into a GPL project (and keeping the original
>copyright mention)? If it does, then how does one make it clear that
>the intent is *not* to sublicence, but to keep each bit as free as it
>originally came?
>

Once you've amalgamated code into a GPL'ed product, it's either
distributed under GPL or it's being illegally distributed. The end
users get to use the product under the terms of the GPL whether or not
the person doing the distribution tries to license it differently. So
it doesn't matter what the intent was.

If you want the user to know about it though, you could always point
to a non-GPL'ed distribution of the code in question, or even distribute
that package along with the GPL'ed product as a separate entity - then
that separate package is not subject to GPL.

By the way, I disagree with the notion that BSD-variant licenses
provide more freedom than the GPL. BSD and its variants don't restrict
an author (or even just redistributor) from exerting control over users,
which makes those users less free, and does not enhance the freedom of
the author.

Lynn

Steve Peltz

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <7ebn1b$he4$1...@jetsam.uits.indiana.edu>,

Lynn Winebarger <owin...@ezinfo.ucs.indiana.edu> wrote:
>the distinction exists just as much as if you bought a copy of the code
>from a vendor who put it under a restrictive proprietary license - I
>don't see how GNU not busting your chops about it makes the distinction
>go away.

I think the only issue is how do you determine which bits are the
original code and which bits were added GPLed (or even proprietary)
code. If the code is identical, it doesn't matter which disk you ended
up copying it from.

Steve Peltz

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <370f5fed...@news.supernews.com>,

If you are required to distribute the soure code along with the binary,
then it is not compatible with the GPL, which allows several methods
for making the source code available.

"on the same terms"? What exactly does that mean? I sold you the binary
for $400 and a requirement that you don't re-distribute it - does that
mean I can charge you an additional $400 for the source and require that
you not re-distribute that as well?

Also, I'm not sure I understand what exactly you're required to
re-distribute. If I modify the sources and distribute a binary, am I
required to redistribute the original sources, or the modified ones? If
the latter, it is every bit as much of a "virus", as it requires me
to distribute my code under the same terms (not that I'm saying that's
necessarily a bad thing).

Richard E. Hawkins Esq.

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <7ecp8g$4d9$1...@harbinger.nn.com>,

agh, let me rephrase,


"You can do anything you damned well feel like with this code, as

long as you provide the source code at no additional cost on the same
terms as any binary upon redistribution, and under this license"

Yes, it means that deri<missing key>ati.es stay under the same license,
which leaes you free do do whateer. But it doesn't try to annex other
software, or limit how it can be linked. If you want it to be able
to be taken priate, or re-licensed, bsd or mit would be a better choice.

I'd also be inclined to add another phrase allowing the original author
to allow it to be relicensed, or e.en carte blanche to relicense in
a non-.ial form.

rick, esq.

Jamie Lokier

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to Lynn Winebarger
Clarification.

A key paragraph in the GPL seems to be missed by many.

It goes:

"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it."

To me, it says that it doesn't matter whether you receive a non-GPL work
directly, or as part of a GPL work. In both cases, you have permission
to use the non-GPL work under its original license.

Enjoy,
-- Jamie

Roger Espel Llima <es...@news.ens.fr> wrote:

> You're always as free to take the MIT-licenced code out of the GPL
> product, and use all the freedom the MIT-licence gives you on it. It's
> only the combination (including the GPL bits) that is being distributed,

> as a whole, under the terms of the GPL.

Lynn Winebarger followed with:

Lynn Winebarger

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <w05yak5lk...@ash.comlab>,

Jamie Lokier <spamfilte...@tantalophile.demon.co.uk> wrote:
>Clarification.
>
>A key paragraph in the GPL seems to be missed by many.
>
>It goes:
>
>"These requirements apply to the modified work as a whole. If
>identifiable sections of that work are not derived from the Program,
>and can be reasonably considered independent and separate works in
>themselves, then this License, and its terms, do not apply to those
>sections when you distribute them as separate works. But when you
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>distribute the same sections as part of a whole which is a work based
>on the Program, the distribution of the whole must be on the terms of
>this License, whose permissions for other licensees extend to the
>entire whole, and thus to each and every part regardless of who wrote
>it."
>
>To me, it says that it doesn't matter whether you receive a non-GPL work
>directly, or as part of a GPL work. In both cases, you have permission
>to use the non-GPL work under its original license.
>

Funny, it says to me that when they're distributed separately, the
separate distribution that doesn't contain any of the (originally) GPL'ed code
doesn't "infect" the second distribution. The GPL, does, however, apply
to the whole of the work that uses code obtained under the GPL.
It just says I can incorporate XFree86 licensed code into a GPL'ed
product without having the original distribution of that code infected.
Similarly, I can distribute the new code I've written separately from
the GPL'ed work, and it doesn't have to be GPL'ed.

Lynn

Barry Margolin

unread,
Apr 6, 1999, 3:00:00 AM4/6/99
to
In article <w05yak5lk...@ash.comlab>,
Jamie Lokier <spamfilte...@tantalophile.demon.co.uk> wrote:
>Clarification.
>
>A key paragraph in the GPL seems to be missed by many.
>
>It goes:
>
>"These requirements apply to the modified work as a whole. If
>identifiable sections of that work are not derived from the Program,
>and can be reasonably considered independent and separate works in
>themselves, then this License, and its terms, do not apply to those
>sections when you distribute them as separate works. But when you
>distribute the same sections as part of a whole which is a work based
>on the Program, the distribution of the whole must be on the terms of
>this License, whose permissions for other licensees extend to the
>entire whole, and thus to each and every part regardless of who wrote
>it."
>
>To me, it says that it doesn't matter whether you receive a non-GPL work
>directly, or as part of a GPL work. In both cases, you have permission
>to use the non-GPL work under its original license.

I think that if you receive the combination as a single work, with a single
license, you don't have the right to split it up and apply different rules
for components unless the license identifies the components. When you
receive it as a single work under the GPL, how can you tell which parts
were derived from something with a different license? The only way is to
have access to that other original, in which case you might as well derive
directly from it.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Niels Möller

unread,
Apr 7, 1999, 3:00:00 AM4/7/99
to
Barry Margolin <bar...@bbnplanet.com> writes:

> In article <w05yak5lk...@ash.comlab>,
> Jamie Lokier <spamfilte...@tantalophile.demon.co.uk> wrote:
>
> >To me, it says that it doesn't matter whether you receive a non-GPL work
> >directly, or as part of a GPL work. In both cases, you have permission
> >to use the non-GPL work under its original license.
>
> I think that if you receive the combination as a single work, with a single
> license, you don't have the right to split it up and apply different rules
> for components unless the license identifies the components. When you
> receive it as a single work under the GPL, how can you tell which parts
> were derived from something with a different license? The only way is to
> have access to that other original, in which case you might as well derive
> directly from it.

Most likely, the original came with some license of its own. That
license most likely requires that the information about copyright and
origin *not* be removed when the work is redistributed. And the person
making the GPL:ed redistribution has to obey these requirements.

So I don't think that identifying the independent parts is a real
problem. If the original code is enhanced by or merged with new GPL
code, that's a different situation.

/Niels

Roger Espel Llima

unread,
Apr 7, 1999, 3:00:00 AM4/7/99
to
In article <s1sO2.323$kM2.42613@burlma1-snr2>,
Barry Margolin <bar...@bbnplanet.com> wrote:

>I think that if you receive the combination as a single work, with a single
>license, you don't have the right to split it up and apply different rules
>for components unless the license identifies the components. When you
>receive it as a single work under the GPL, how can you tell which parts
>were derived from something with a different license? The only way is to
>have access to that other original, in which case you might as well derive
>directly from it.

You make a good practical point here. I've been arguing for
splittability because I think this is an issue that will present itself
more and more, as the number of free software packages, and the number
of free licenses, keeps growing.

When two projects X and Y under licenses A and B incorporate a work Z
under a third license C (and assuming these licenses are compatible in
this way, even though A and B may well not be compatible with each
other), it is a *good* thing for the common work to be commonly
maintainable.

So I would strongly encourage maintainers of packages who are faced with
this situation to explicitly identify the components, and even to
explicitly C-license their modifications to Z, so that they can be
shared.

Steve Peltz

unread,
Apr 7, 1999, 3:00:00 AM4/7/99
to
In article <7ed81e$2bb$1...@eyry.econ>,

Richard E. Hawkins Esq. <ha...@eyry.econ.iastate.edu> wrote:
> "You can do anything you damned well feel like with this code, as
>long as you provide the source code at no additional cost on the same
>terms as any binary upon redistribution, and under this license"

[ I've filled in your v key for you ]

>Yes, it means that derivatives stay under the same license,
>which leaves you free do do whatever. But it doesn't try to annex other

>software, or limit how it can be linked. If you want it to be able

>to be taken private, or re-licensed, bsd or mit would be a better choice.

So if I modify the source and release a binary, I'm required to release
the modified source, not just the original? Isn't that the same property
that the GPL has? The GPL has some additional restrictions, but that right
there is the "viral" property of the GPL that some people object to.

>I'd also be inclined to add another phrase allowing the original author

>to allow it to be relicensed, or even carte blanche to relicense in
>a non-viral form.

The original author needs no permission from the license. The author can
re-license it any way he wants, unless he's assigned copyright to someone
else, or given exclusive rights to someone.

Richard E. Hawkins Esq.

unread,
Apr 8, 1999, 3:00:00 AM4/8/99
to
In article <7eg8af$q0n$1...@harbinger.nn.com>,

Steve Peltz <pe...@medusa.nn.com> wrote:
>In article <7ed81e$2bb$1...@eyry.econ>,
>Richard E. Hawkins Esq. <ha...@eyry.econ.iastate.edu> wrote:
>> "You can do anything you damned well feel like with this code, as
>>long as you provide the source code at no additional cost on the same
>>terms as any binary upon redistribution, and under this license"

> [ I've filled in your v key for you ]

Thanks. I was stuck scanning 56 pages of code back in (grr), and
had to use a nearby dark-side machine and xwin32. Turns out
that under "automatic" for keyboard, the v key doesn't work . . .

>>Yes, it means that derivatives stay under the same license,
>>which leaves you free do do whatever. But it doesn't try to annex other
>>software, or limit how it can be linked. If you want it to be able
>>to be taken private, or re-licensed, bsd or mit would be a better choice.

>So if I modify the source and release a binary, I'm required to release
>the modified source, not just the original? Isn't that the same property
>that the GPL has? The GPL has some additional restrictions, but that right
>there is the "viral" property of the GPL that some people object to.

It's one of the two restrictions, and one of the two viral properties.
This viration [? :) ] doesn't bother me, and I don't think it'ts the
one that bothers other people. The more serious problem is the attempt
to slap the GPL on everything else in sight (the borg problem), and to
prevent linking. This is the part that traps unwary developers, such as
almost happened with lyx & xforms. Fortuneately, the developers had
told everyone to go forth and distribute binaries, and I was able to
write the disclaimer explaining the license.

If you don't want to require that the source be redistributed, I'm not
clear why anyone would look further than BSD (with or without
advertising), or public domain.

I think the desire to keep the source free is fairly common; the desire
to force GPL on other code, or to prevent linking to or by non-GPL
is not (though some desire this).

>>I'd also be inclined to add another phrase allowing the original author
>>to allow it to be relicensed, or even carte blanche to relicense in
>>a non-viral form.

>The original author needs no permission from the license. The author can
>re-license it any way he wants, unless he's assigned copyright to someone
>else, or given exclusive rights to someone.

Yes, but I'm thinking in terms of projects. I write a package, get some
fixes, and generally couldn't grant permission for the modified package
to be used under a different license. With a clause like this I could.

Richard E. Hawkins Esq.

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to
In article <7ebgkv$f6n$1...@nef.ens.fr>,

Roger Espel Llima <es...@news.ens.fr> wrote:

>And, more importantly, GPL does NOT "viralize" or "infect" MIT-L (or
>XFree-L) code.

>You're always as free to take the MIT-licenced code out of the GPL


>product, and use all the freedom the MIT-licence gives you on it. It's
>only the combination (including the GPL bits) that is being distributed,
>as a whole, under the terms of the GPL.

>I wish people would stop making this stupid claim that the GPL applies


>to code that wasn't GPL'd to begin with. That is simply not the case,
>and I doubt copyright law would even allow something like it.

I write "widgets" under a free license. You include widgets in
"gearbox", which you GPL. Peter then takes widgets from gearbox,
makes some changes, and ships "cogs" as GPL. I see no
way that these changes can go back into "widgets" without his
permission.

Mitchell Baker

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
I think the LGPL requires you to determine if your program is a "work based on the
Library" (section 2) or a "work that uses the library" by being compiled or linked
with the Library (section 5).

A "work based on the Library" (Section 2) seems to have the same virus effects as
the GPL, since Section 2c) says "You must cause the whole of the work to be licensed
at no charge to all third parties under the terms of this License."

The source code of "work that uses the library" by linking does not have to be
governed by LGPL (Section 5). But the executable created by actually doing the
linking IS covered by the LGPL (Section 5 again).

The MPL requires changes to MPL files to be made public, but does not require code
linked to such files to be public or governed by the MPL.

Mitchell Baker
mozilla.org

Daniel Veditz wrote:

> Eleftherios Gkioulekas wrote:
> >
> > Robin Green <gove...@my-dejanews.com> writes:
> >

> > > I know this must have been discussed before, but browsing dejanews archives I
> > > couldn't find a really good analysis of this question:
> > >
> > > I want to write free ("freed") software, in the sense used by the Free
> > > Software Foundation (www.fsf.org) whilst avoiding the GPL because of
> > > license-virus effects. Should I use the Mozilla Public License (MPL) or the
> > > GNU Library General Public License (LGPL)?
> >

Reply all
Reply to author
Forward
0 new messages