[Rcpp-devel] Review request: Sandboxed R integration via RInside

Dirk Eddelbuettel edd at debian.org
Thu Nov 20 17:41:27 CET 2014


Hi Christian,

On 20 November 2014 at 17:10, Christian Authmann wrote:
| Hello,
| 
| I don't want to get into lengthy legal discussions (I'm a programmer, 
| not a lawyer), but let me just state my intent.
| 
|  From the way I read the GPL-FAQ
|  > http://www.gnu.org/licenses/gpl-faq.html
| the GPL2 only applies to derivative work and linking.
| 
| Which means that the client, which is written in a generic, 
| non-R-specific way and does not link to R headers or libraries, should 

Does the client code use R code to (de-)serialize R objects?  If it is, then
it is tainted too.  If not, what the hell are you doing?  A Tibco TERR-alike
complete rewrite?  Really?

I think some RServe clients try to play that trick, which is possible
(against GPL-2) and a reason why GPL-3 and AGPL came to play.  On the one
hand I find such code unethical, but I also resist those urging all licenses
to be converted to GPL-3 ...  

| not need to be GPL. (Yes, we're planning to use the same client code and 
| network protocol to integrate other scripting languages eventually. 
| setValue, getValue, setCallback and runCode should be generic enough, 
| right?)
| All code relevant to the server (i.e. the process linked to R) must be 
| GPL of course, while shared code can be dual-licensed.
| 
| That's the way RServe interprets it (otherwise their client libs would 
| need to be GPL, too), and that's the way I interpret it, which is why I 
| released the client sources under the MIT license (and thus implicitely 
| under GPL, too).

I would prefer it if you made code you generously offer for us to be included
in RInside consistent with the rest of the RInside project: GPL-2.

Simple because it avoids these discussions.  But also ...
 
| That means that you could include the client in a proprietary 
| application and have great R integration without making your project 
| open source. Some people consider that bad.

... because I am such a person. :)

For the open source work that I do, I stronly prefer GPL-2.  Which is both
"copyleft" and "viral".  Which means that you should add code to it under
same license (and that is at least the spirit of the law, and pretty much
also the letter of the law as you understand for the server side).

Other cases are clear. Look at at HP / Vertica with their Distributed R -- it
contains Rcpp and RInside (and a lot more), and all that HP / Vertica added
is under GPL-2 as well, presumably for the same reason of "it all bubbling up
to R binary code that is GPL-2 anyway" (my interpretation).  Their repo is at 

   https://github.com/vertica/DistributedR

and they 

 
| It also means that we can include R into our project at all. We're using 
| a multitude of different libraries with incompatible open source 
| licenses, and it seems impossible for us to include GPL code and 
| distribute the results. If the client is MIT licensed, we can eventually 
| release our project under a (non-GPL) open source license, which I 
| consider good. If it isn't, our project would either need to ditch R 
| (our scientists would hate that) or remain internal (I'd hate that).
| 
| 
| IANAL, and if the project maintainers disagree with that view, or don't 
| want non-GPL applications to even talk to RInside, then I don't have a 
| problem with removing the MIT license and distributing it GPL-only 
| within RInside.

I would really much prefer if you could alter the pull request and change the
licensing. 

| So there, I'd like to talk about code now :)

:)

Dirk

 
| -- 
| Christian Authmann
| Philipps-Universität Marburg
| Fachbereich Mathematik und Informatik
| AG Datenbanksysteme
| Hans-Meerwein-Straße
| D-35032 Marburg
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org


More information about the Rcpp-devel mailing list