(L)GPL remarks and FreeGIS licensing

Tue Aug 12 14:26:14 UTC 2003

[ 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.

> 1) 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 at gnu.org is your friend.
(It might take a while for them to answer.)

> 2) 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.

> 3) "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

-- 
Professional Service around Free Software                (intevation.net)  

If freegis is useful for you, consider paying for the service:
	http://freegis.org/about-paying.en.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20030812/e647a2fe/attachment.sig>