Thanks for checking that the list of contributors to contact is correct:
https://bitbucket.org/lgautier/rpy2/issue/171/license-is-the-agpl-making-sense
Best,
Laurent
On 11/29/2013 04:43 PM, Laurent Gautier wrote:
Hi,
Thanks to all for the participation, opinions, and recommendations.
While there are diverging opinions about what the license should/could
be, the consensus appears to be that the AGPL is not the most
appropriate. I am taking note and I'll work on having it taken off the
next rpy2 release.
The process will be slightly tedious but reasonable to handle, I
think. I am proposing to:
- List contributions and open an issue for each one
- Each issue will have to be resolved in the following 2 possible ways:
* Author agrees on the relicensing (as soon as the new license is
decided - more on this below)
* Author disagrees and the contribution is taken out (subsequent
contributions proposing alternative implementation will be possible)
Regarding the new license, my current understanding is that GPLv2
would be the most obvious path, because R is GPLv2 and because of the
following few points and forward-looking statements:
- Allowing to build rpy2 with its own R could be become an option (and
may be even the default). A number of issues reported by users are
caused by building with a version of R and run with a different
version of R.
- Building rpy2 while applying custom patches to R (and compiling its
own R) is a possibility. My experience with getting patches for bugs
or improvements into R has made me consider this more than once.
- rpy2 is only using the R headers / linking to R's dynamic library in
rpy2.rinterface (the low-level interface to R - in fact
rpy2.rinterface._rinterface); rpy2.robjects and friends (high-level
interface to R) are implemented using rpy2.rinterface. Should the
licensing terms be unbearable, the options can be to:
* reimplement a high-level interface in a distinct module
(reimplement, not copy/paste rpy2.robjects)
* isolate (licensing-wise) rpy2 in a distinct process.
Reimplementing a client-server (full RServe, or anything custom is
rather easy - there a minimalist example in the documentation -
http://rpy.sourceforge.net/rpy2/doc-dev/html/server.html. I thought of
a fancier example with, for example, zeromq... may be some day.
Comments, diverging opinions, etc... are welcome.
Best,
Laurent
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
