[GRASS5] why GPL

Eric G. Miller egm2 at jps.net
Tue Mar 27 03:59:07 EST 2001


On Mon, Mar 26, 2001 at 09:49:42PM -0800, strobe anarkhos wrote:
> At 12:04 PM +0700 3/27/01, Justin Hickey wrote:
> >Hi Strobe
> >
> >I'm not going to comment much on the main arguments so far, however, I
> >feel I need to clarify a point about the protection offered by the LGPL
> >and the GPL. Note that I'm not a lawyer and the only parts of these
> >licenses I read were the preambles.
> 
> FSF preambles are political rhetoric. I'm only concerned over the
> legality, which by the way hasn't changed since it was called the
> 'Library' GPL.

I'll agree that the preambles have little legal weight.  But the
preamble states an intention which could be considered in adjudication
should the interpretation of the wording of the license come into
question.  But, this is beside the point.

I think myself and most others understand your argument for the LGPL
quite well.  Many of us simply disagree that it is a good idea for
GRASS in general.  

We have discussed previously the possibility of creating a GRASS I/O
library that would provide the necessary facilities for reading, writing
and basic manipulations of GRASS database items.  The bulk of such a
thing would come from the current libgis, with portions from the vector
library and possibly the image library.  This libgrassio (or whatever
it'd be called) would be licensed under the LGPL so that vendors could
use it to write import/export "filters" or otherwise access GRASS
databases through GRASS's native "interface".  In the near term, this is
more likely to be feasible than any high falutin' ideas about major
rewrites of GRASS.  And, it would facilitate interoperability with other
commercial vendors' products.

Now, if I understand your proposal, you would wish to create a library
and application framework vis-a-vis OpenStep Foundation classes that
would supply a somewhat higher level of abstraction and supposed
functionality.  Depending on how you break it out, could not such a
thing be designed with a minimal set of functionality (similar to the
GRASS I/O library proposal)?  And, if this is true, if such a thing were
licensed under an LGPL couldn't both GPL and non-GPL code utilize this
framework provided the non-GPL code does not depend on the GPL code?

Anyway, I'd suggest we let this topic rest for a while.  No point in
arguing the license for something that only exists in the ether...

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list