[GRASS-user] licensing question: calling GRASS GIS modules via the grass.script API in an MIT/Apache licensed script ?

[Moritz Lennert]

Hi Vaclav,

Thanks for taking the time for this !

Le Fri, 23 Aug 2019 21:42:15 -0400,
Vaclav Petras <wenzeslaus at gmail.com> a écrit :

> On Tue, May 7, 2019 at 4:42 AM Moritz Lennert
> <mlennert at club.worldonline.be> wrote:
> 
> > Hi,
> >
> > We work with a company on a project where we use GRASS GIS to
> > calculate accessibility indicators. The main output we provide is a
> > Python script which calls GRASS GIS modules via the grass.script
> > API. The company is willing to make this script free software, but
> > would like to license it with a permissive license such as MIT or
> > Apache.
> >
> > I would think that calling GRASS GIS modules in a script does not
> > automatically imply the script has to be GPL, but what about the
> > use of the Python API ?
> >
> > I would think that this case falls in the grey area described at
> > [1] and have tendency to think that MIT/Apache license would be
> > allowed. 
> 
> Hi Moritz,
> 
> To make things more complicated: Note that if MIT is allowed, that
> (would) mean(s) that proprietary is also allowed, i.e. can you
> license it under an arbitrary licensing terms and conditions. So, I
> think you are basically asking if you can create proprietary scripts
> which are using GRASS GIS modules and also if there is a difference
> between a script and a software in this context. Is doing scripting
> in GRASS GIS mere using of GRASS GIS or it is making derived
> programs? There is general agreement that Bash scripts can be
> MIT/proprietary, but is calling GRASS GIS modules the same as calling
> POSIX defined tools? Depending on the answers, you can be looking at
> incorporating GPL-covered software in a proprietary system [2].

I would consider GRASS modules as equivalent to any bash executables.
My question was more about the GRASS GIS Python API which is actual
GRASS GIS code. That's why I was wondering whether such scripts would
be considered as derived work.

> 
> But first, I would be asking for reasons for requiring MIT/Apache.
> Clearly, it is not *fear* of leaking patent rights with GPLv3 because
> that would rule out Apache. If the reason is keeping the option to
> reuse pieces of the code in a propriety product by the company, I
> don't see why that would be an issue because 1) as a copyright
> holder, you can decide to change licensing at any time

If your code falls under GPL rules (because it is derived) that require
the use of GPL (or similar) for any release, can you still decide to
change the licensing ?

> and 2) even if
> you keep GPL, you can use modified GPL code internally without
> releasing it. 

I'll have to discuss this with the company. It was not clear yet where
the code would actually run, possibly in machines of clients (public
administrations, etc). In that case this means they distribute the
code. They suggested MIT, but I think they could be open to GPL if I
can show them that this will not cause any issues for their business. I
guess that if the script remains an independent piece of software that
clients just use, then it can simply be distributed under GPL, but it
will be used in conjuction with other, proprietary, software, so I
guess it is maybe more a question of how they package the whole thing,
possibly distributing the two separately.

> Use of GPL software is oviously not an issue either
> here. On top of that, the increasing use of SaaS and GPL behavior
> there [3] makes me wonder why to even talk about this and not go with
> the obviously save choice GPL >=2.

Again, this is not entirely up to me (otherwise it would obviously be
GPL). Maybe there is just some unjustified fear on their side.

> 
> To push back a little, I would say that if somebody has the capacity
> to have reasons for MIT/Apache which go beyond what I tried to
> describe in the previous paragraph, I would say they have capacity to
> determine the licensing options here, i.e. answer my first paragraph.
> This serves also as my "I'm not a lawyer statement."
> 
> And a more practical note, in case the conclusion of all this is
> still a MIT or Apache license, note that Apache 2.0 is not compatible
> with GPL v2 (it is compatible only with v3), so it would not be
> possible to include the code into GRASS GIS (which is >=2) if
> somebody decides to do so.

It is not code to be included in GRASS GIS, but code that uses GRASS
GIS...

Thanks again !

Moritz