This whole thing is such a nuisance. It seems one can’t even give something away these days!

Así de infeliz se mostraba G. Grothendieck hace unos días. Y es que habíamos enviado una primera versión del paquete rJython que subir a CRAN y nos encontramos con problemas de licencias.

Eso de las licencias de software es un tema enojoso. Importante, pero enojoso.

Además, da la impresión, que totalmente exótico a la ética y costumbres de este país desde el que escribo: algún día, como divertimento, contaré alguna historieta. Y cuando haya vencido la fecha de prescripción, la más divertida, la más ilustradora del fenómeno, la sin par: la del código con copyright de EverisWaterhouseCoopers.

En resumen, que por acá, todo lo que está en tu disco duro es tuyo y con él puedes hacer capas, sayos y lo que se te antoje. No así en latitudes más honestas y en las que eso de las atribuciones, contratos y licencias se gestiona más seriamente.

Veamos pues en qué consistió el embrollo. El paquete rJython consta de tres partes distintas:

• Código en R desarrollado por los autores. Ambos estamos felices de distribuirlo con una licencia tal como la GPL.
• Un fichero binario, jython.jar, sujeto a la Jython Public License.
• Un módulo de Python, simplejson, ligeramente modificado y cubierto por la licencia del MIT.

CRAN nos obliga a liberar el paquete con una única licencia. La solución que plantea Fedora para este tipo de situaciones no le satisface.

No se puede liberar todo el paquete con licencia de Jython porque ésta sólo la concede la Python Foundation a terceros, sólo cubre un software llamado “Jython” y podría no ser compatible con la MIT. La MIT tampoco vale porque no está claro que sea compatible con la de Jython.

¿GPL? Por ahí encontramos que es compatible con la MIT. También con la de Python. ¿Pero con la de Jython? A saber. Comparamos las licencias de Python y Jython y constatamos que son prácticamente idénticas (sólo que en algunos lugares reemplaza “Python” por “Jython”). Así que asumimos que también son compatibles.

¿Más? Pues sí: compatibles son, pero… ¿qué significa que dos licencias lo sean? Tal vez por aburrimiento y porque se acercaba la hora de comer, queremos creer que significa que si un proyecto consta de tres ficheros,

1. Fichero1.c, cubierto por la GPL
2. Fichero2.c, cubierto por la Jython License
3. Fichero3.c, cubierto por la licencia del MIT,

entonces está permitido liberar el paquete entero como GPL siempre que quede especificado que los ficheros fichero2.c y fichero3.c están cubiertos por sus propias licencias.

¿Será así? Quien sabe. Pero la decisión está tomada y, salvado este último escollo licenciatario, rJython ya está disponible en CRAN para asombro del mundo.

Ya está disponible el paquete rJython que permite llamar a Python desde R. Aunque todavía no se ha subido a CRAN, puede instalarse así:

install.packages("rJython", repos="http://R-Forge.R-project.org")

Una vez instalado puede probarse el paquete ejecutando, por ejemplo,

rJython <- rJython()
a <- 1:4
jython.assign( rJython, "a", a )
jython.exec( rJython, "b = len( a )" )
jython.get( rJython, "b" )
rJython$exec( "import math" )
jython.get( rJython, "math.pi" )
jython.call( rJython, "len", 1:3 )
b <- 5:8
rJython$exec( "def concat(a,b): return a+b" )
jython.call( rJython, "concat", a, b)

Arquitectura: Jython y rJava

El paquete no está basado en el habitual Cpython sino en Jython, un intérprete de Python desarrollado en Java. El motivo es doble:

• La integración de R y Java está bastante madura gracias al paquete rJava.
• Es difícil detectar de una manera robusta y multiplataforma el intérprete de Python.

El paquete se distribuye con la versión 2.5.1 de Jython (actualmente, la más reciente). Esto permite que pueda instalarse sin otras dependencias que rJava.

Las desventajas de usar Jython en lugar de Cpython son:

• Sólo se pueden utilizar módulos de Python escritos enteramente en dicho lenguaje.
• El rendimiento es menor al utilizarse una pila de lenguajes interpretados para ejecutar el código.

Comunicación entre R y Jython: JSON

La comunicación entre R y Python se realiza serializando los objetos de cada lenguaje utilizando JSON. El paquete rjson en R y simplejson en Python se utilizan para codificar y decodificar los objetos en sus respectivos entornos.

Excepciones

Se ha hecho cierto esfuerzo en permitir la captura en R de las excepciones que puede generar Python.

Motivación e historia

Se han realizado varios intentos por  integrar R y Python. El más antiguo del que tengo noticia (y que creo es ya obsoleto) es RSPython. El módulo RPy de Python permite llamar a R desde Python pero echaba en menos una manera de llamar a Python desde R.

Existe un paquete en CRAN, RPyGeo, que llama a Python, aunque de una manera uniplataforma (sólo en Windows y si se instala Python en el mismo directorio que el autor del paquete) y burda: mediante llamadas al sistema por línea de comandos.

La respuesta de Gabor Grothendieck a una pregunta mía en R-devel apuntaba a un paquete suyo, RSymPy, en el que había resuelto el problema de la manera que elabora rJython. En comunicaciones posteriores con él decidimos colaborar para construir un paquete que abundase en su idea original y que pudiese servir de plataforma de comunicación entre R y Python.

Ahora se libera una versión, la 0.0-2, que en justicia podría adoptar el sobrenombre de alfísima.