[GRASS-dev] Re: Copyright and license issue

Roger Bivand Roger.bivand at nhh.no
Sun Jan 15 07:36:03 EST 2012


Hamish <hamish_b <at> yahoo.com> writes:

> 
> Jarek wrote:
> > Ok, it explains everything. So if I want to publish code with any GPL 
> > privileges granded, but keep code integrity in one official place which 
> > I can put in paper as link to OFFICIAL source code, with guarantee that 
> > it won't be accidentaly changed, I must put it outside GRASS repository? 
> > Right?
> 
...
> if you want to delay releasing under the GPL until you have your article
> published, then you would have to wait to put it in the grass addons repo
> too, which is open to GPL-compatible code only. (as per rfc2)
> 

I think that Jarek's concern is that someone other than the add-on developers
have commit rights. In R, this is handled by having an add-on incubator called
R-Forge https://r-forge.r-project.org/, which can also be used for installation,
but where the project intiator(s) are the only non-admins with commit rights.
When packages are released to CRAN, installation becomes somewhat easier. This
might work here if OSGeo had a *-Forge facility, part of which could be used for
add-ons for GRASS. The point about R-Forge rather than CRAN is that the R-Forge
SVN lets people collaborate and try things out before the add-ons reach
usability (the classes start at Planning, then pre-Alpha, and so on using
Trove). So until the add-on developers release it, no-one they haven't nominated
can commit. It looks as though the -install argument takes a complete URL, so a
miminal *-Forge would make a nightly tarball that could be installed.

Of course, someone might download the add-on source, modify it, and distribute
that modified version, but I'm not sure that this was the underlying issue here,
rather that the public add-on SVN server has potentially many commit permissions.

Roger

> Hamish
> 






More information about the grass-dev mailing list