LGPL for Libraries
Posted 25 May 2001 at 16:50 UTC by sej
For starters, I'm an advocate of fair use and a liberal
interpretation of copyright law. I deplore the fact Disney
has the legislative clout to extend the term of copyright as
fast as Mickey Mouse ages. I feel it is a serious
detraction from the quality of community if each new
generation is barred from recycling the works of their
elders as they struggle to get a foothold in life.
think personal sharing of copyrighted material (with a few
friends, not the whole Internet) should be facilitated by
more than the Sony videotape copying court decision. The
ability to have experiences in common with the people you
know by sharing a book or movie needs to be defended and
upgraded in the digital age.
It is from this perspective that I find it necessary to
criticize those who would stretch the power of copyright to
restrict the use of a copylefted software library. I am 100% behind
the right of the copyright holder to control the creation
and dissemination of clearly derivative works. But simply
using a library as is, and abiding to the terms for that
piece of an aggregrate work should in no way impact the
larger work. We would boycott such behavior from Microsoft,
why encourage it for anyone else?
I think the principled thing for the FSF to do would be to
reverse themselves, and start advocating LGPL for libraries,
and GPL for applications. Where does it say the FSF has to
act as the sworn enemy of all forms of intellectual property
(and all forms of intellectual profiteering), and as a
result be willing to go to court to extend the power of the
munitions (copyright law) employed by both sides?
What are they really
fighting for? Many have dreamed of hyper-efficiency by having all
parties do things only one way (their way). Thank goodness nature,
science, and politics all conspire to defeat them. If you are an
advocate of GPL for libraries, let me ask you if you think it fair to
give away something so useful and expect copyright law to govern the
behavior of those whose hands it falls into? Seems like entrapment to
me, and not a good idea for a movement founded on principles of
I understand the motivation of wanting to share free software without
benefiting those who don't share. I don't personally feel that way, but
I believe that choice should be available, just like the choice of not
wanting to share software without economic compensation. But just as
emacs and gcc don't impact the license of software made with their use,
a copylefted library should not impact the license of software it is
aggregated into in an unmodified fashion.
What if Time-Warner-AOL gives
away the ultimate extendable and scriptable multi-media player, then
claim an interest in all intricate extensions of it, regardless of
whether it is done by Hollywood or the PTA? This is not a perfect
analogy for the LGPL/GPL library debate, but if you can successfully
defend the use of copyright law for one kind of borderline derivation,
won't you have established precedent that others can use as well?
You can argue differently. But I would like to know why.
Another view of the GPL, and LGPL would be that they are a trade, rights
in my code, for rights in your code, with additional rights given away
as a loss-leader to help build business.
The GPL and LGPL differ in the amount of rights that they confer without
requiring compensation, in the form of rights to your code. The LGPl
allows linking, while the GPL does not. If, instead of code, we look
at it in terms of something that has a longer history of copyright, my
point may become clearer.
Suuppose I write a short story. By default, you've got pretty much no
rights to use it. I grant a license that allows it to be distributed
and/or published by you, by itself, but require payment to include
it in an anthology (or create derivative works). Certainly I have not
extended the terms of copyright
at all. You are being prevented from distributing it combined with other
works, regardless of whether the resulting product is derived.
Smilarly, the GPL allows you to distribute the works it covers,
but does not allow you to distribute them combined with other works.
Well, it grants you additional rights, allowing you to distribute it
combined with other works, when the combination is "mere aggregation",
and it is not expected that you pay in terms of programs that
are "not derived from the Program, and and can be
reasonably considered independant and separate works in themselves".
You are, in effect, allowed to distribute copies of my story, but not
include it in an anthology, but I go out of my way to make sure that
selling a separately bound copy as part of a collection of books,
without any of the front matter that normally goes into an anthology,
trigger the "anthology exception" to my license.
The LGPL allows inclusion in anthologies (so to speak), but still
requires payment for derivative works. It basically, gives away more
rights free. It's the discount version, is all. And as such, the
FSF does not think you should give things away at fire-sale prices, unless
they're necessary to obtain any compensation, perhaps because the
program is relatively undifferentiated compared to proprietary offerings,
or because it doesn't sell in a large enough volume at the higher price.
The point is, after all, to get paid in as much code as possible :)
Fair use, posted 25 May 2001 at 19:04 UTC by mslicker »
Depends on your definition of fair use. You start by giving an example
of sharing books and movies with others. In software terms the GPL
already provides this form of fair use, even more so. I certainly would
not last very long at all if set up a company for the mass distribution
of Disney movies, yet companies already exist for the mass distribution
of free software.
I'm not sure on what basis you arguing use of LGPL for libraries, it is
certainly not fair use.
The decision of whether to LGPL or GPL is certainly up to you. In
certain cases as the FSF notes, use of
LGPL over GPL would be more benifitial to free software. Advocating that
all libraries be LGPL would weaken free software not strengthen it. What
extra motivation would there be to make something free software when
everything your application could possibly be built on doesn't care?
As in the case of VirtualDub, where the original GPLed code is in an
application, and the company rips part of code out and places them in
See, the difference between applications and libraries are not
obvious. It is harder to tell for, say, CORBA objects.
The issue is more complicated than just libraries vs. applications.
The Common Good, posted 25 May 2001 at 21:36 UTC by Bram »
My goal is to further the common good as much as possible. Common sense
dictates that the more restrictions you put on something, the less
useful it will be, hence I put all my stuff in the public domain.
The GPL is a pain in the ass, and I'm hoping most of it is deemed
unenforceable by the courts.
, I think converting a GPL app to a
library would clearly make the library a derivative work, and make the
terms of GPL apply without question. I admit I didn't realize that was
the case with
Vidomi. With that clarification I am supportive of your recent article
. But it doesn't alleviate
my concern with applying GPL to libraries in the first place.
Fyndo, you seem motivated by "quid
pro quo" to share your copylefted code. A sort of shareware with
teeth. Fine with me, but why rely on enforcing a contested definition
of derivative work to accomplish your goals, when standard contract law
would be more direct? Conversely, do you think all
those library authors who have used the LGPL discouraged each other
way, because they allowed for use in proprietary software? :-)
mslicker, I was trying to argue against
using the GPL on libraries because I think it will lead to either a) an
unnecessary extension of the definition of derivative work (which in
practice might feel like user interface copyright when enforced), or b)
a weakening of the perceived enforcability of GPL for applications if
things go the other way. GPL was necessary to bootstrap the free
software movement. LGPL allowed a greater percentage of software
developers to contribute and participate, and was a pragmatic and fair
compromise that addressed the realities of software libraries (and
software library authors). Yes people can choose whatever path they
want, but when the FSF uses words like ethically
tainted to describe behavior beyond what they advocate, I think it
time for others to speak up.
, Ok, I see what you are getting at. I don't think
applies though. GPL doesn't cover a particular interface only the
software. If I made a GPL licenced libary for OpenGL for example, all
applications which use OpenGL would not have to be GPL'd as long as they
didn't depend on my implementation. In this example that would most
likely be the case since OpenGL is pretty common on different systems
now. Here also there wouldn't be that much incentive to make it GPL over
LGPL since that would rescrict certain software from being available
which would be available on other platforms.
On the other hand, say I make a completely unique GPL'd library, of
which it is the only implementation. Someone is free to reimplement the
library and make a propreitary program, but is not free to release a
propreitary program dependent on my library. This would motivate someone
to make more free software, because they would have advantages they
wouldn't have in the purely propreitary world of software.
Bram, I agree in general, the less restrictions the
better. However, the only thing the GPL prevents is benefiting unfairly
someone elses work. That is one restriction I can live with.
The reason I GPL libraries is it promotes freedom (in the same way
it does for programs).
You are arguing that using a library for writing a program ("using a
library") is different to writing a program derived from another,
and that putting restrictions (to promote freedom) on "using a library"
I want a "free world". GPLing my libraries promotes this end.
This is why we fight copyright and patents, and use these
WRT copyright law, standard IANAL response: we're not claiming
any rights about users of libraries. We're just saying that you
have to release under GPL to use them together. If you put
your code in the "free world", then you have no problems.
For example, I released libparted (the guts of Parted)
under GPL. Free GNU/Linux installers can use it. SuSE got bitten,
because their installer isn't free. This is exactly what I want...
to reward distributions that give as freedom, and to punish those
that don't. (In the end, SuSE went via the parted frontend,
sending commands down a pipe. I'm sure this is causing all sorts
of headaches ;-)
PS: I think most programs should be a library + frontend.
So, almost all free software would end up LGPL by your arguments,
and it would be trivial to derive non-free front-ends.
, I think you're right in that
enforcing the GPL on a completely unique library (like readline) does
not fall under the category of user interface copyright enforcement.
Enforcing it on something like dynamic linking of an OpenGL variant
would equate to that -- but no one is suggesting that. So let us remove
that from the discussion.
My main concern is stretching the definition of a derivative work in the
process of enforcing the GPL on a library. And a curiosity why those
interested in information liberation would want to do that.
If you re-read my arguments, one of the points I was
trying to make is that it does not strictly rely on the work being
derivative. You may not distribute it without permission, even as part
of a "collective work", this is just standard copyright law, without
the collective work being necesarially derivative. The GPL grants you
the right to use it in a collective work, if either, a) the rest of the
work is GPL'ed or b) the rest "can be reasonably considered independent
and separate works in themselves,", and then, just to make sure that
there's no confusion, it adds:
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
Unless you wish to claim that a program requiring a library is
independant of the library (which reqires, IMO, a really weird
definition of either requires, or independent), you lose your
right to distribute the library. If you're not distributing it at all,
you might have a case, but there does come a point at which
you're obviously outside the intent of the license. Obviously any
application can be converted into a library, and then linked to,
where would you draw the line? And how?
I couldn't agree more.
The fact is, when people stubornly and almost by-default make their
projects GPL, they also in many cases close the door to all those guys
who wants to work on free/open software but wants one version of it in
their closed or not-entirely-open projects.
I.e, for every GPLed library that fills a strong demand, there is
destined to come a more liberally licensed (e.g BSD-like) software...
You might say that you lose freedom by doing so, I say more people can
and will contribute when they can use the software more widely.
A lot of us are not in this in order for people to use the software
more widely. We're hoping to create a rich body of software free from
the traditional conditions of redistribution and modification. We do
close the door on people who want to grab our code for (partially or
wholly) non-free projects, but that's intentional. There are objectives
here different from those of filling the greatest demand and getting the
If on the other hand there's an argument here that people use the GPL
ignorantly, without wanting to help extend the software-sharing
community, I can only suggest that that was what a lot of us were hoping
would happen all along: the default has changed. :-)
, I'm not sure why someone would rebuild a free
software library under a different free software licence. If you had a
proprietary software project and you had to reimplement functionality of
GPL'd software in only seems in your best interest to hold onto the code
You are right it does make more work for proprietary developers, and
that is unfortunate. That's not the fault of GPL'd software, but the
fault of companies thinking of software, first and for most, as property
and not as a tool.
If we stick to our guns hopefully we change the corporate thinking from
"How can we sell more software?" to "What software do we need to get the
job done?". This can only create more opportunities for developers to
work on free software and get paid!
Is there anyone who advocates applying the GPL to libraries whenever
possible, yet rejects the claim that any involvement with proprietary
software is ethically tainted? And would your motivation for advocating
the GPL over the LGPL still exist if the illegal monopolistic behavior
of certain software practioners was reined in?
I qualify, posted 27 May 2001 at 15:31 UTC by Fyndo »
I don't believe that any involvement with proprietary software is
ethically tainted, I just do not believe that allowing proprietary
software to use free software however they like is a good way to
promote free software, and feel that free software is more beneficial
to society, and hence, should be promoted.
Doesn't particulary depend on any particular companies behavior, just
don't see what's wrong with expecting to be paid in code for the right
to use a library. And if expecting to be paid in code is wrong, why is
expecting to be paid in cash ok?
IANAL, posted 28 May 2001 at 02:04 UTC by Pseudonym »
IANAL. Just as well, because I'm a geek. The law simply doesn't
think the same way that computers do.
No court is going to accept the argument that a program which uses a
library in some non-essential way is a "work based on" the library.
The non-essential thing is important. A web browser which uses a
GPL'd HTTP protocol implementation or HTML renderer (in library form)
is definitely a "work based on" that other library. Turning an
application into a library and writing a small wrapper is definitely
a "work based on" the library.
However, an encryption package which uses, say, a GPL'd
implementation of a cipher as a plug-in it not necessarily a "work
based on" that plug-in. Especially if the package will work file
(presumably using some other cipher instead) without said plug-in.
My point is that we geeks think in terms of "all libraries" vs "no
libraries". That's not how the law thinks. The law thinks in terms
of "substantial" and "essential". These are vacuous concepts which
attempt to draw a distinction which defies a simple boolean test.
Unfortunately, this makes grey areas. One example is RMS' own
example of a debugger using GNU readline. Is that a "work based on"
readline? That's very hard to say. I wish I knew.
Personally, I will not use a GPL'd library in an application which I
do not intend to release using a GPL-compatible licence. Partly, I
can't afford the legal costs, but more importantly, it would be
hypocritical of me to use the licence but not respect the author's
wishes as to how it is to be used. By placing a library under the GPL,
the author is stating an intention. If I do not agree with that
intention, I'll look elsewhere.
The GPL enforces that people using the library contribute back (in the
form of the code they wrote) - I can see both the reasons why this is
a good thing (obviously - more GPLed applications) and why it's a bad
thing (if things like glibc or XFree86 were GPL, we wouldn't see much
non-free Software on Linux - without things like StarOffice 5.2 or the
Loki games, we probably wouldn't be seen as a viable alternative to
Microsoft stuff even on the desktop yet. (KOffice and OpenOffice are
getting there, but not quite ready yet)).
If it's a really large library, GPL it but make different licensing
available for a reasonable fee (the way Qt does) -- makes everyone
contribute (either in the form of code or in the form of paying people
who write the code - if they can drop a different job, it'll help the
library) without completely shutting out non-free software.
There are valid reasons for all 3 positions (and even for other
options, like BSD-licensing it) - so, consider what you want to do
with the code, and pick the right license (and possibly additional
terms like optional other licensing) for what you want to do.
Please don't invent yet another license though, this will only cause
confusion ("may I link my new GPLed code with code that uses the XYZ
license?", "may I merge code from a project under the XYZ license into
my GPLed code", ...).
Crypto Libraries, posted 28 May 2001 at 16:55 UTC by Bram »
Pseudonym: linking to a cipher implementation tends to not be a
problem. Since most people who write crypto libraries are not open
source zealots and are simply trying to promote crypto usage, they
generally use much freeer licenses.
Often when anyone mentions other licenses than GPL or LGPL, people
worry about that their code will be "stolen" and used in proprietary
solutions without they getting the performed modifications back.
I'd say that risk is present, yes, but in reality very unlikely to
occur. Besides, the Evil Company still just rips the code out and uses
it without acknowledging the license, as is being seen repeatedly.
On the other side, if they use your stuff in closed-source
products, they probably work on it professionally (and thus may be good
programmers that can contribute good stuff) and they _want_ to
contribute their fixes back to you as they want the main branch of the
software to remain easy adaptable for them as they want all (other)
bugfixes and improvements you do to the software. I'm sure many authors
of projects using BSD-like licenses would agree with me.
So, the question then comes: is it better for me to run my project
(L)GPL and have those other guys write their own implementation, or is
it better to join the efforts and risk that someone do take disallowed
advantage of the code?
If the author owns the copyright on the majority of the code. He should
a commercial license to the company for that part. The money he
recieves can be used to fund development of the GPLed version, which the
company may not be able to use, depending on how copyright on
modifications is assigned.
Simple, everyone wins...
Grr..., posted 29 May 2001 at 13:40 UTC by danwang »
I hate it when I post a reply to the wrong article.. please ignore the
stub libraries, posted 29 May 2001 at 22:21 UTC by jmg »
This reminds me of a discussion a while back on the FreeBSD mailing
lists. There is no requirement that the replacement library be fully
So you have a case of a GPL'd library. You write a stub library that
pretty much just returns errors upon all calls (or even just aborts()).
Then you distribute your software with the stub library. Then the end
user can "choose" to use the GPL'd library for their own personal work
(they can't make the results available to the public), but since they
are using it for personal or internal business use, they are not in
violation of the GPL and not required to redistribute the program that
makes use of the GPL'd library.
There are always loop holes in such a complex license. The above
would be perfectly valid. You did in your original program make no
guarantees about how it'd function, so abort()ing is a valid course of
The section of the GPL on modification is pretty clear about what you
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.
In your example you do not satify the "can be reasonably considered
independent and seperate works in themselves" condition, since your
program only works in pressence of certain GPL'd code.
bagder, There are certainly advantages and
disadvantages to each and every license. However, within the relm of
free software licences, I don't think it is very productive to argue in
general about which license a project should use. Each project has
different intentions, and as many point people here point out the line
between library and application is not always clear. If someone is
making free software we should already be satisfied and assume that they
are intelligent enough to pick the proper license for their project.
If anyone here is a proprietary developer (which I don't taint), and you
encounter a piece of GPL'd software you think would be useful, why not
contact the author? There is a good chance the developer would be
willing to work with you and your company provided you give him/her
something in return.
, I agree that "general" discussions about
what license to pick is a rather useless thread to re-iterate.
I am just in my
When it comes to proprietary code and licenses, you and others in this
thread forget something vital:
There is hardly ever only one single author to contact. When there's 24
guys who've contributed code under a certain license, how can the main
author switch that for me?
More, I've worked for companies that rejected the software immediately
when it was GPL'ed, going for a BSD-version instead.
On the other side of the fense, I've had (proprietary-) people thank me
for not using GPL in stuff as that made it possible for them to use my
free software in their closed-source products. The same people have since
contributed significantly and with quality. Thus, having them as
"customers" greatly enhanced the product for all us free persons.
I've also worked on GPL'ed software for companies that the GPL was just
ignored in spite of my complaints. I've also worked for companies that
actually tried to send back the changes we did to GPL'ed software.
Just so people know, there are lots of examples where BSD and
MIT-licensed code has been modified by commercial companies, sold for
profit, and never donated back, leaving a huge mess.
The specific examples I'm thinking of are BSD itself, X11, and
sendmail. Back in the days when commercial Unix actually seemed like
a good idea, we had the "Unix wars" in which vendors would take a
common code base, add one or two new features or fix bugs or security
holes, then release a binary-only version of the new program along
with their OS.
What we got was lots of incompatible versions of sendmail, lots of
incompatible versions of BSD-like Unix kernels, and lots of weird X11
extensions (Display Postscript and binary-only video drivers, anyone?)
that caused portability nightmares.
The most recent example I heard about was the SoftUpdates improvements
to the BSD filesystem, which were very clever but which only appeared
in one commercial BSD implementation (BSDI, I think). On the other
hand, reiserfs on Linux is GPLed because all Linux kernel code has to
Dan Bernstein (of qmail fame) is so weird with his licenses probably
primarily because of the sendmail disaster. He doesn't want to see
his qmail code fork and become a whole bunch of incompatible versions
like sendmail did -- IMHO, the GPL actually protects against this, but
the BSD license can cause the problems he's worried about.
People argue over BSD vs. GPL. BSD people do not consider proprietary
programs using their code bad. Fine.
Simply, GPLed or LGPLed code is good for the general public because it
makes the distributed code and derivatives public property,
usable by all. (If some code is not distributed, it makes no
difference to others whether the code exists or not--web service-type
programs are discussions for another day). So while BSD people don't
care, users may have good reasons to prefer GPLed or LGPLed code.
Now as to LGPL for libraries, there may be no clear line between
libraries and applications--after all, all applications can become
libraries invoked from some other applications. If one wants to use a
GPLed "software piece" and does not want to have his whole program
there is always the option of requesting alternative licensing from the
original author. One would guess most open source authors will grant
permission to other open source authors for using their code...
apenwarr: Please read a bit about SoftUpdated before
you start to spout off about how it was only included in BSD/OS
(remeber, BSDi is the company, BSD/OS is the OS they sell). This is
completely false. It has been included as part of FreeBSD for a VERY
Reading the README
that was originally committed to the FreeBSD source tree in May 1998 has
the following comments about it's license:
Redistributions in any form must be accompanied by
on how to obtain complete source code for any accompanying
software that uses the this software. This source code must
either be included in the distribution or be available for
no more than the cost of distribution plus a nominal fee,
and must be freely redistributable under reasonable
conditions. For an executable file, complete source code
means the source code for all modules it contains. It does
not mean source code for modules or files that typically
accompany the operating system on which the executable file
runs, e.g., standard library modules or system header
That sure doesn't sound like a license that is limited to BSD/OS
only. I guess you can say it was
only included in one commercial OS, but you forgot to mention the FREE
OS that it was included with.