[GRASS5] why GPL

[strobe anarkhos]

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

I think you are the only one who understands my argument. Everybody else is rambling on about 'protection' and not 'reciprocity'.

>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?

The short answer is no.

You say that the IO is all that is necessary to interface with other applications. I disagree. The whole point is to encapsulate data into objects which are then edited using a set of methods thus when one app (or whatever) touches the data, everybody else knows about it and may even undo the operation.

I didn't know this was going to drag on and on and on with red herrings and RMS quotes and lectures on free speech etc. However I should have expected it given my experience with other FSF projects in the past. All I know is the GPL uses extremely strict/vague/general language about what derivative works are. I don't need to know the structure or offsets of an Objective-C library in order to call a method. I only need to know the object's name and the method's name. I can call a method by linking, or by connecting to a server offering an object, or by some notification, or by a command line interface, or using sockets or fifos or morse code. All I know is the GPL is sufficiently vague that all or none of these could be binding.

At least with the LGPL it's generally considered that linking is OK, but improving a library without LGPL-ing changes is NOT OK. There is a clearer dividing line between fair and unfair use. I'm not a proponent of the LGPL, perhaps more restrictions ought to be amended for our purposes. The GNUStep people use the straight LGPL and have no fear of code misuse. Any changes to the GNUStep library HAVE to be released under the LGPL.

Thus like you said before (and everybody else seems to disagree with) the issue is not protection buy reciprocity.

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

I don't think I have a choice, people are still talking about protection and other non-issues. I guess the topic will just have to die at the preamble which nobody can seem to get past.

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