Minor but important point: if switching to GPL please make it GPLv2+ (I.e.,
use the "or any later version as published by..." language), not just
GPLv2. This allows compatibility with GPLv3 code...
On 29 Nov 2013 13:44, "Laurent Gautier" <lgaut...@gmail.com> 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
> <http://rpy.sourceforge.net/rpy2/doc-dev/html/server.html>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
