[GRASS-ABM] [frankie@debian.org: Re: [GRASSLIST:10783] Re: [GRASS5] FWD: [OSGeo-Discuss] Incubation Committee / Contributor Agreements]]

I think that the issue is not whether GRASS can use a piece of software
under a BSD/MIT license, but whether a piece of software licensed under
BDS/MIT can use GRASS.

Does that make sense? If this kind of question can be clarified, it might
help a lot.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Markus Neteler <neteler@itc.it>
Date: Wed, 8 Mar 2006 12:46:14 +0100
To: <grass-abm@grass.itc.it>
Subject: [GRASS-ABM] [frankie@debian.org: Re: [GRASSLIST:10783] Re: [GRASS5]
FWD: [OSGeo-Discuss] Incubation Committee / Contributor Agreements]]

Attached a FWD from GRASS-dev.

Interestingly there is the opinion that GRASS *is*
compliant with new-BSD and MIT:

http://grass.itc.it/pipermail/grass5/2006-March/021606.html
http://grass.itc.it/pipermail/grass5/2006-March/021611.html

Now I wonder why we discussed this some weeks ago? Maybe
I am getting something wrong here.

Markus

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

2006/3/8, Michael Barton <michael.barton@asu.edu>:

I think that the issue is not whether GRASS can use a piece of software
under a BSD/MIT license, but whether a piece of software licensed under
BDS/MIT can use GRASS.

Does that make sense? If this kind of question can be clarified, it might
help a lot.

Michael

You’re right. It’s a caracteristic of BSD licenced software to can be integrated into software with different licence, even non-free.
And sometime, GPL’d software aren’t enough free because they can’t be used by other free software because of licence restriction.
That why I think IMHO that some type of code should be licenced under a more permissive licence. I’m thinking about libraries or protocols.

Laurent

On Wed, 8 Mar 2006, Michael Barton wrote:

I think that the issue is not whether GRASS can use a piece of software
under a BSD/MIT license, but whether a piece of software licensed under
BSD/MIT can use GRASS.

Does that make sense? If this kind of question can be clarified, it might
help a lot.

Please have a look at the text near the head of:

https://svn.r-project.org/R/trunk/doc/COPYRIGHTS

"From the announcement of the change (2001-Feb-05) ..."

The key question is almost always distribution of derived software, not
use of the GPL software itself. In the R case, the API headers were moved
to LGPL to accommodate the distribution of derived software built against
R. The question of whether another work uses a GPL'ed work will also
depend on how it interfaces - through a C-API, loading DLLs/shared
objects, client-server, there's quite a range, and some of the uses are
quite hands-off.

There is a discussion of this in the QGIS codebase (QGIS is GPL) to
accommodate Qt.

The R FAQ is also very clear on commercial use:

http://cran.r-project.org/doc/FAQ/R-FAQ.html#Can-I-use-R-for-commercial-purposes_003f

and insofar as GRASS is GPL, the same permissions for use apply. The
restrictions begin to apply if someone takes GPL'ed code, modifies it, and
distributes it in their own software under a changed license. So it isn't
really about use, we're pleased that people find the software useful. It's
about the distribution of derived works which abuse the copyright and
license terms chosen by the author(s).

Compare this with the academic situation: we all like being cited, but
being cited extensively without the appropriate references is not so much
fun.

Roger

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: Markus Neteler <neteler@itc.it>
> Date: Wed, 8 Mar 2006 12:46:14 +0100
> To: <grass-abm@grass.itc.it>
> Subject: [GRASS-ABM] [frankie@debian.org: Re: [GRASSLIST:10783] Re: [GRASS5]
> FWD: [OSGeo-Discuss] Incubation Committee / Contributor Agreements]]
>
> Attached a FWD from GRASS-dev.
>
> Interestingly there is the opinion that GRASS *is*
> compliant with new-BSD and MIT:
>
> http://grass.itc.it/pipermail/grass5/2006-March/021606.html
> http://grass.itc.it/pipermail/grass5/2006-March/021611.html
>
> Now I wonder why we discussed this some weeks ago? Maybe
> I am getting something wrong here.
>
> Markus
>
> --
> Markus Neteler <neteler itc it> http://mpa.itc.it
> ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
> MPBA - Predictive Models for Biol. & Environ. Data Analysis
> Via Sommarive, 18 - 38050 Povo (Trento), Italy

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

On Wed, Mar 08, 2006 at 09:47:13AM -0700, Michael Barton wrote:

I think that the issue is not whether GRASS can use a piece of software
under a BSD/MIT license, but whether a piece of software licensed under
BDS/MIT can use GRASS.

Of course no, the resulting program will be GPL. I mean the GRASS
library, because mere aggregation is legitimate. This is the reason
why libc is LGPL for instance. And surely a derivative GRASS work
will be GPL, as well.

Does that make sense? If this kind of question can be clarified, it might
help a lot.

Sure, clarified :slight_smile:

--
Francesco P. Lovergine

On Wed, Mar 08, 2006 at 06:03:27PM +0100, Laurent C. wrote:

You're right. It's a caracteristic of BSD licenced software to can be
integrated into software with different licence, even non-free.
And sometime, GPL'd software aren't enough free because they can't be used
by other free software because of licence restriction.
That why I think IMHO that some type of code should be licenced under a more
permissive licence. I'm thinking about libraries or protocols.

Re-licensing the GRASS library only under LGPL would allow those kind of things.

--
Francesco P. Lovergine

Let me ask again:

how could a (say, fictive) project such GRASS-ABM, written
in JAVA and not GPLed for whatsoever reason, make use of
GRASS modules?

I hope that the answer isn't: "use a proprietary GIS".

In my opinion we should work on a solution for this
problem.

Markus

On Wed, Mar 08, 2006 at 09:47:13AM -0700, Michael Barton wrote:

I think that the issue is not whether GRASS can use a piece of software
under a BSD/MIT license, but whether a piece of software licensed under
BDS/MIT can use GRASS.

Does that make sense? If this kind of question can be clarified, it might
help a lot.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

how could a (say, fictive) project such GRASS-ABM, written
in JAVA and not GPLed for whatsoever reason, make use of
GRASS modules?

could you elaborate on how the modules would be used?
e.g. back-engine processing for online non-GPL mapserver software?

Hamish

On Tuesday 14 March 2006 00:45, Markus Neteler wrote:

Let me ask again:

how could a (say, fictive) project such GRASS-ABM, written
in JAVA and not GPLed for whatsoever reason, make use of
GRASS modules?

I hope that the answer isn't: "use a proprietary GIS".

the answer should be: "GRASS-ABM should better go for a
GPL compatible license to take advantage of GRASS".

I would like to see the GRASS team defend this and take
it as a strong benefit rather than trying to help others to keep
their developments separate from GRASS.

The easier to use GRASS without being
GPL compatible the less contributions GRASS will receive
in the mid term.

Does the benefit of GRASS-ABM using GRASS really weight
out this? I don't know.

In my opinion we should work on a solution for this
problem.

Tell GRASS-ABM that they should either think about a GPL
compatible license or on some "bridging" layers under a GPL compatible
license. The latter is sort of a grey area, but depending on
the actual needs of GRASS-ABM there can be practical solutions.

Best

  Jan

--
Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de
Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org
Intevation GmbH : www.intevation.de | Kolab : www.kolab.org
FreeGIS : www.freegis.org | GAV : www.grass-verein.de

On Tue, 14 Mar 2006 jan@intevation.de wrote:

On Tuesday 14 March 2006 00:45, Markus Neteler wrote:
> Let me ask again:
>
> how could a (say, fictive) project such GRASS-ABM, written
> in JAVA and not GPLed for whatsoever reason, make use of
> GRASS modules?
>
> I hope that the answer isn't: "use a proprietary GIS".

the answer should be: "GRASS-ABM should better go for a
GPL compatible license to take advantage of GRASS".

I would like to see the GRASS team defend this and take
it as a strong benefit rather than trying to help others to keep
their developments separate from GRASS.

The easier to use GRASS without being
GPL compatible the less contributions GRASS will receive
in the mid term.

Does the benefit of GRASS-ABM using GRASS really weight
out this? I don't know.

> In my opinion we should work on a solution for this
> problem.

Tell GRASS-ABM that they should either think about a GPL
compatible license or on some "bridging" layers under a GPL compatible
license. The latter is sort of a grey area, but depending on
the actual needs of GRASS-ABM there can be practical solutions.

I agree. They should consider their options carefully, and go with GPL
unless they have very good reasons not to. If that is the case, then they
will need bridging layers that mean that users download and install GRASS,
and their non-GPL software uses GRASS at arm's length (shell or other
scripts, system() calls, possibly calls to LGLP'ed libraries if they
appear - though from earlier discussion this does not seem to be a viable
option, ...). People can have different opinions, but the positive
consequences of information externalities coming from GPL should not be
overlooked.

Roger

Best

  Jan

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

jan@intevation.de wrote:

On Tuesday 14 March 2006 00:45, Markus Neteler wrote:

Let me ask again:

how could a (say, fictive) project such GRASS-ABM, written
in JAVA and not GPLed for whatsoever reason, make use of
GRASS modules?

I hope that the answer isn't: "use a proprietary GIS".
   
the answer should be: "GRASS-ABM should better go for a
GPL compatible license to take advantage of GRASS".

I would like to see the GRASS team defend this and take
it as a strong benefit rather than trying to help others to keep
their developments separate from GRASS.

The easier to use GRASS without being
GPL compatible the less contributions GRASS will receive
in the mid term.

Does the benefit of GRASS-ABM using GRASS really weight
out this? I don't know.

It was an example for existing problems. I have spoken quite a few times to
people who were interested to connect to GRASS, to invest even money into
further GRASS development, but then went away since this didn't want to
or could not (because they were not owner) publish their piece of software
under GPL.

More users = more developers, for sure. And we definitely need more
developers.

In my opinion we should work on a solution for this
problem.
   
Tell GRASS-ABM that they should either think about a GPL
compatible license or on some "bridging" layers under a GPL compatible
license. The latter is sort of a grey area, but depending on
the actual needs of GRASS-ABM there can be practical solutions.

That's why I try to push the SWIG interface idea. But I am not sure if this
works as a (legal) bridge.

Markus

Hamish wrote:

how could a (say, fictive) project such GRASS-ABM, written
in JAVA and not GPLed for whatsoever reason, make use of
GRASS modules?
   
could you elaborate on how the modules would be used?
e.g. back-engine processing for online non-GPL mapserver software?

Hamish,

I have no idea. I am not really involved in GRASS-ABM,
so Michael Barton may answer.

I just sort of forwarded what they told me, with some
personal observations.

Markus

On Tue, 14 Mar 2006, Markus Neteler wrote:

jan@intevation.de wrote:

>On Tuesday 14 March 2006 00:45, Markus Neteler wrote:
>
>
>>Let me ask again:
>>
>>how could a (say, fictive) project such GRASS-ABM, written
>>in JAVA and not GPLed for whatsoever reason, make use of
>>GRASS modules?
>>
>>I hope that the answer isn't: "use a proprietary GIS".
>>
>>
>
>the answer should be: "GRASS-ABM should better go for a
>GPL compatible license to take advantage of GRASS".
>
>I would like to see the GRASS team defend this and take
>it as a strong benefit rather than trying to help others to keep
>their developments separate from GRASS.
>
>The easier to use GRASS without being
>GPL compatible the less contributions GRASS will receive
>in the mid term.
>
>Does the benefit of GRASS-ABM using GRASS really weight
>out this? I don't know.
>
>
It was an example for existing problems. I have spoken quite a few times to
people who were interested to connect to GRASS, to invest even money into
further GRASS development, but then went away since this didn't want to
or could not (because they were not owner) publish their piece of software
under GPL.

More users = more developers, for sure. And we definitely need more
developers.

>>In my opinion we should work on a solution for this
>>problem.
>>
>>
>
>Tell GRASS-ABM that they should either think about a GPL
>compatible license or on some "bridging" layers under a GPL compatible
>license. The latter is sort of a grey area, but depending on
>the actual needs of GRASS-ABM there can be practical solutions.
>
>
That's why I try to push the SWIG interface idea. But I am not sure if this
works as a (legal) bridge.

The summary here:

http://news.hping.org/comp.lang.python.archive/35539.html

looks positive, I think you are on the right track. It's about "copying,
distribution or modification of GPLed code", and if the interface doesn't,
it should help. In the quoted summary:

"Our approach to thsi issue has been to instruct end users to obtain third
party GPLed code from its original source, and to install both it and our
non-GPLed code (it is Mozilla licensed) on their system. In that way what
we are doing cannot possibly be construed as "copying, distributing or
modifying" that third-party GPLed code. Rather, our code just calls it at
run-time on the end user's system."

and:

"... if your non-GPLed SWIG source code needs to use GPLed header files,
there is nothing to stop you distributing your code to an end user, and
then instructing the end user to download the GPLed coded needed by your
non-GPLed code, and to then compile everything, all within teh confines of
their system. Provided that the end results of this compilation are not
then distributed to anyone else, then the GPL is not violated, not in
letter nor in spirit."

For "distribution" this is awkward, but is possible. As the note says, GPL
is not worried about use outside of "copying, distribution and
modification".

Roger

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

Markus Neteler wrote:

It was an example for existing problems. I have spoken quite a few times to
people who were interested to connect to GRASS, to invest even money into
further GRASS development, but then went away since this didn't want to
or could not (because they were not owner) publish their piece of software
under GPL.

If they can't release the combined work under the GPL, that means that
some other code which they wish to use is neither GPL/LGPL nor
BSD/MIT, but under some licence which requires different restrictions
on redistribution (e.g. non-commercial use only).

Personally, I don't see any reason to assist such projects.

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