[GRASSLIST:10816] Re: [GRASS5] FWD: [OSGeo-Discuss] Incubation Committee / Contributor Agreements]

[Glynn Clements]

Markus Neteler wrote:

> > I understand this perspective and welcome mechanisms by which developers and
> > contributors can have their work properly credited and distributed.
> > 
> > On the other hand, I've already run into problems in trying to establish
> > links between GRASS and other open source software, using other licenses
> > (BSD and MIT). Because GRASS is GPL, if the developers of the other software
> > do not want to license under GPL, we are very limited in the kinds of
> > linkages we can establish. I understand (I think) the basic principals
> > though not the legal details.
> 
> Glynn,
> 
> there have been discussions earlier on releasing some libraries
> under LGPL (you will remember).
> 
> What's your suggestions to deal with the issue mentioned by Michael?

My "solution" is for the combined work to be licensed under the GPL.

Anyone releasing code under a BSD/MIT licence is allowing it to be
relicenced under any licence, including proprietary licences, so using
it in a GPL project isn't an issue. Personally, I don't consider
compatibility with BSD/MIT projects sufficient reason to abandon the
key feature of the GPL, namely that all derivatives must remain free.

I consider the LGPL to be appropriate for general-purpose, stand-alone
libraries, where the entire project is the library. Where a larger
project is split into libraries for convenience (e.g. GRASS), the
libraries should generally also be GPL, IMHO.

There are some limited cases where other licences (e.g. LGPL) might be
appropriate, e.g. basic I/O on the GRASS database files, so that the
GRASS database can be used by other applications. However, there isn't
currently a clean separation between the file format handling and
actual functionality.

E.g. lib/gis/get_row.c does the raw I/O, resampling, reclass handling,
mask handling etc. Okay, so that wouldn't be a vast amount amount of
functionality to be giving away for free, but I've been considering
alternative raster storage mechanisms (primarily tiled storage) where
the "chain" between the raw I/O and the application interface would be
quite significant, particularly if you were to have optimised paths
for specific cases (scale-up/scale-down, reclass/no-reclass,
mask/no-mask etc).

-- 
Glynn Clements <glynn at gclements.plus.com>