[ I'm also crossposting this to the fsfeurope discussion list as many points are quite general to Free Software licensing. ]
On Tue, Aug 12, 2003 at 03:07:17PM +0200, Radim Blazek wrote as answer to a post On Monday 11 August 2003 09:11 by Jan-Oliver Wagner:
Here are some LGPL disadvantages: (by application I mean any application using LGPL library)
Naturally I consider the valid points as advantages, because the freedom of the software part under LGPL is protected.
- Staticaly linked application must be probably distributed also as source code.
They must not be distributed as source code.
The GNU LGPL wants to protect against that you get in the position that you cannot fix a bug in the Free Software code part that was included in the end product. If this protection would not be in place a vendor might use a bug or special behaviour in the library to do a extend and embrace tactic in that his product will only be compatible with his product.
So the LGPL requires that the end user must be able to exchange the LGPL part. The static part of the license is not relevant in many cases as using dynamic libraries has gotten increasingly easy in the last years. Object code before static linking would be enough for the cause; dynamical linking really makes it easy to fulfill that requirement just having the library.
http://www.fsf.org/copyleft/lesser.html If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it.
Yes, I say 'probably', because LGPL is not very clear, and I found on the Web two kinds of explanations for article 6. a), one states that object code is enough, the second that source code is required.
The GNU LGPL is legally very clear, but complicated in itself, because the legal coyright situation in the US is complicated.
The indention of that paragraph is made clear in other sections of the license. E.g. at the end of paragraph 6: For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it.
Some people obviously read "object code and/or source code" as "object code or source code", but it does not seem to be right.
It depends on what is necessary to reproduce the executable after an exchanged library part with the same interface. With a shared library or object code for static linking you do not need the source code. So for this situation "or" is correct.
Also "permit modification of the work for the customer's own use" imposes distribution of source code, but that would apply to dynamicaly linked application as well.
No, because the distributed work is the binary. So you can modify the binary, which was a more common thing to do and some (proprietary) licenses do not allow this (nor reverse enginerring).
Unfortunately, I cannot find any FAQ for LGPL.
Most questions are answered in the FAQ for the GNU GPL. Others are answered in the archives of mailinglists. If you have a question, which happens even of only because the legislative system changes around you, licensing@gnu.org is your friend. (It might take a while for them to answer.)
- The application cannot use any third party libraries or tools needed to build the application which are not standard part of OS and cannot be distributed with the application. For example library which can read proprietary data format, available for download on Web, but without permission to redistribute it. On Windows, compiler like "Visual C" is also such tool. This is of course valid regardless the application is proprietary or free!
You missinterpret the end of paragraph 6 and mix something up with option a) from the same paragraph.
If you don't have permission to distribute the third party library in executable form (tple), then you cannot distribute it anyway no matter what the GNU LGPL licenced part says. That is a drawback of the license of the tple.
On the other hand, if you have permission to distribute the tple, paragraph 6 only says that you must be able to also distribute the necessary tools to be able to reassemble the executable. All because of the intended goal to be able to exchange the LGPL part.
This tool usually is a linker or a dynamic loader. So you can of course use a proprietary tple not usuablly distributed with the operating system. E.g. there is no problem on windows if you use dlls because the loader comes with the operating systems or objects compiled by "Visual C" for static linking, because you can link them on windows with Free Software linkers like ld.
- "You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change." this does not block the use, but it is annoying and extra work.
If you use version control like CVS, you can easily produce this by a script. Also some editors and the diff application will make this quite easy. It is a minor hassle but a very sensible one that even helps the quality of the software. It is also protecting the freedom, because proprietary companies cannot slip nasty tricks or backdoors by the user as easily as without it.
If I look around, successful open source GIS projects don't use (L)GPL: GDAL/OGR: MIT/X License Mapserver: MapServer License (almost MIT/X) PROJ4: MIT/X License
It depends on how you define success. E.G. PostGIS, GRASS, GMT, GPSDrive, JTS, KFLog, Vis5d, Geotools, GnuGaMa, BBBike and R use GNU GPL; OSSIM, OpenEV, VRS and degree both also utilse the LGPL. All those can be called successful in their area or targetted use.
GDAL/OGR are format exchange libraries for which LGPL and X11 have a higher strategic value. PROJ4 also is a core library similiar like ogg/vorbis. Even the FSF found the X11 license to be of strategic advantage for ogg/vorbis.
Additionally the question is: Could e.g. Mapserver even be more successfull when it would use a different license? This can also be asked the other way round of course and makes up the difficult strategic question which license to use.
Finally, I've found no evidence at all that L(GPL) harms the practical aspects of software. It only protects the freedom - thus if you mean that the license harms your practice to derive proprietary products from Free Software then of course you are right.
The problem is that it complicates/disables the use of the LGPL library for both free and proprietary programs.
It also protects the freedom of the software part under LGPL and history shows that some companies will otherwise have no reason not to use the results and make money with proprietary software on the efforts of the Free Software community.
But in that case your anyway not interested in the ideas and values of Freedom and Free Software.
I am interested in free software when it is feasible and sensible.
The upcoming of GNU/Linux systems is credited to a huge part to the GNU project and the licensing efforts of Richard Stallman and the FSF. I've made some simple analysis about license and it seems that the GNU GPL still is the most important Free Software license. http://mail.fsfeurope.org/pipermail/discussion/2001-June/001167.html
I am not interested to force people to do what FSF considers to be the best.
If we do not defend our freedom it will slowly be taken away. As author of software you have the right to decide on its license. The Free Software community (which included much more than the FSF or the people of the GNU project) has been using copyleft for about 15 years now and it is a sensible and viable concept.
Regards, Bernhard