I have a question about putting into add-on repository the code containing completly new terrain analysis system.
Code will be on classic GPL license, however I would like to TEMPORARILY restrict the name of module, scientific idea (completely new) and permission to code modification. It means that everybody can use, analyze, rewrite it for own purpose etc, however if someone would like to modify original source code in repository should have our permission (for some time).
This is because the code and entire idea is strongly under development, however we were asked to publish it for geomorphological community (also for submitted paper)
I think that it probably will never happen that someone would like to modify it (except of course bugs), however I would like to keep control on code integrity for scientific discussion as long as it won't be finished as an idea.
I have a question about putting into add-on repository the code
containing completly new terrain analysis system.
Code will be on classic GPL license, however I would like to TEMPORARILY
restrict the name of module, scientific idea (completely new) and
permission to code modification. It means that everybody can use,
analyze, rewrite it for own purpose etc, however if someone would like
to modify original source code in repository should have our permission
(for some time).
This is because the code and entire idea is strongly under development,
however we were asked to publish it for geomorphological community (also
for submitted paper)
I think that it probably will never happen that someone would like to
modify it (except of course bugs), however I would like to keep control
on code integrity for scientific discussion as long as it won't be
finished as an idea.
The whole point of a revision-control repository is to facilitate
making modifications to the code.
Whoever controls the GRASS repository can control who can commit to a
specific directory, but this is involves more work than implementing
repository-wide controls.
In terms of licensing, the GPL grants each recipient permission to
make modifications and to distribute modified versions, provided that
they indicate that the code has been modified.
As the GRASS libraries use the GPL (not LGPL), any module which uses
them must also be licensed under the GPL if it is to be redistributed
in binary form.
I have a question about putting into add-on repository the code
containing completly new terrain analysis system.
Code will be on classic GPL license, however I would like to TEMPORARILY
restrict the name of module, scientific idea (completely new) and
permission to code modification. It means that everybody can use,
analyze, rewrite it for own purpose etc, however if someone would like
to modify original source code in repository should have our permission
(for some time).
This is because the code and entire idea is strongly under development,
however we were asked to publish it for geomorphological community (also
for submitted paper)
I think that it probably will never happen that someone would like to
modify it (except of course bugs), however I would like to keep control
on code integrity for scientific discussion as long as it won't be
finished as an idea.
The whole point of a revision-control repository is to facilitate
making modifications to the code.
Whoever controls the GRASS repository can control who can commit to a
specific directory, but this is involves more work than implementing
repository-wide controls.
In terms of licensing, the GPL grants each recipient permission to
make modifications and to distribute modified versions, provided that
they indicate that the code has been modified.
As the GRASS libraries use the GPL (not LGPL), any module which uses
them must also be licensed under the GPL if it is to be redistributed
in binary form.
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?
J.
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?
is the intention simply to be able to provide a link to the exact version
of the code you are writing about? or is it to retain personal control
during the development phase?
if you simply need to be able to provide a link to the exact version you
are writing about that's easy, just add "?p=" to the end of the websvn URL
or "?rev=" to the end of the trac URL. e.g.:
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)
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.
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?
is the intention simply to be able to provide a link to the exact version
of the code you are writing about? or is it to retain personal control
during the development phase?
both. This is because it is that not only code is in development but also entire idea is under development. Frankly speaking I do not afraid that someone may want to change code for no reason. The best option is to publish code temporary outside the svn repository, but it also have a lot of cons.
if you simply need to be able to provide a link to the exact version you
are writing about that's easy, just add "?p=" to the end of the websvn URL
or "?rev=" to the end of the trac URL. e.g.:
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)
This solution solves this problem partially. Maybe adding an asking in main.c preamble to contact author before modify the code in this particular repository may solve this issue??
thanks
Jarek
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.
yes, it would be really nice to have restricted area for incubated projects.
I also do not think that it is not GPL compatible. Everybody can download, change and publish modified code except that original repository may be changed by limited group of people.
jarek
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.