Los dioses digitales 1: guerras santas entre licencias

Primera parte de la serie «Los dioses digitales»

Segunda parte: los dioses de plástico y silicio

Tercera parte: Las comunidades son dioses celosos


 

Hace un par de años, en una conversación privada, un conocido defensor de una conocida licencia «permisiva» (volveré sobre este término más tarde) trató de defender su posición no a través de una lista de beneficios de su licencia adorada, sino diciendo que las licencias GPL eran «inmorales».

Pensando en las absurdas afirmaciones que algunos defensores de las licencias permisivas dicen sobre las «copyleft» (también volveré sobre esto) y en las otras absurdas afirmaciones que algunos defensores de las copyleft dicen sobre las permisivas, es que este artículo ha nacido.

Sobre las licencias: los dioses como «ley»

A no preocuparse, que no entraré en sesudos análisis que otros ya han hecho con mayor autoridad. Solo quiero destacar aquí un par de detalles que considero importantes y que mucha gente suele pasar por alto.

Para comenzar, por más simpáticos que nos parezcan ciertos términos y neologismos toda licencia de software es una licencia de «copyright». Después de todo, copyright solo significa «derecho de copia»: es decir, la licencia nos dice si podemos o no copiar y/o redistribuir algo y bajo qué condiciones. Las licencias copyright estándar, que en el mundillo del software suelen llamarse «propietarias» o «privativas», simplemente dicen «no copiar, todos los derechos reservados». Por otra parte, las licencias de copyright del software libre varían entre «algunos derechos reservados» (las simpáticamente llamadas «licencias copyleft», como la *GPL, algunas CreativeCommons, etcétera), las «hagan lo que usted quiera con mi trabajo» (las permisivas, como BSD, MIT, Apache…) y las de «dominio público» («esto ya no me pertenece»… que yo sepa, rara vez son utilizadas).

Para seguir, las licencias sólo dicen qué hacer a los demás, no al autor: el dueño del copyright (o left, o lo que queramos) siempre tiene derecho a cambiar de idea y utilizar una nueva licencia, incluso una que contradiga la anterior, para cualquier versión posterior de su trabajo.

Ciertamente, si el autor de un trabajo libera su código bajo licencia *GPL las variantes del mismo realizadas por terceros deberán seguir siendo *GPL, en esto la licencia es clara. Pero si ese autor decide luego que las siguientes versiones de lo que él hace sean privativas, pues ningún problema: está en todo su derecho.

Esto ciertamente se complica en proyectos donde se tienen muchos colaboradores: poner a todos de acuerdo para cambiar la licencia puede ser una tarea titánica… a menos, claro está, que el proyecto pida a sus participantes que cedan su copyright a algún tipo de asociación que actúe como representante.

Muchos proyectos utilizan varias licencias simultáneamente (tampoco entraré en consideraciones sobre la compatibilidad de las licencias) y en no pocas ocasiones se ha dado y se da la aparente contradicción de una licencia «copyleft» conviviendo con una privativa: Digia, por ejemplo, tiene una versión «comercial» de Qt junto a las *GPL.

(A no preocuparse, y por sobre todas las cosas a no creer a los troll que se complacen en teorías conspiratorias: los de Digia también tienen un acuerdo con la gente de KDE que dice que si ellos fallan en mantener el código libre, pues todo lo que exista hasta el momento cambiaría automáticamente a una licencia permisiva).

Tampoco es un secreto que durante años IBM mantuvo Lotus Synphony, cuyo código propietario estaba basado en el código *GPL del antiguo proyecto OpenOffice.org (OOo), desarrollado en aquellos tiempos afortunadamente pasados por Sun microsystems.

Y es que al tener completo control del copyright (Sun exigía compartir el copyright para que un código pudiera pasar a formar parte de OOo), además de la versión *GPL Sun licenciaba a IBM una versión que este último hizo privativa. Luego, cuando Sun fue comprada por Oracle y esta última empresa decidió que no tenía interés en OOo, todo el código fue donado a la fundación Apache cambiando la licencia de *GPL a Apache 2. Inmediatamente después de eso, IBM donó también a la fundación Apache su versión privativa, la cual pasó a ser Apache 2 y ahora todo el código de Apache OpenOffice (AOO) es completamente libre bajo una licencia permisiva que autoriza a cualquiera a copiar el código y hacer una versión con la licencia que quiera (que es lo que continuamente hace la gente de LibO, después de todo).

Cada creador tiene derecho a determinar qué puede hacerse o no con su trabajo y cada usuario tiene derecho a poder aceptar o no las condiciones. ¿La licencia no es de tu agrado? Pues no la uses: decir que una particular licencia es inmoral es tan absurdo como querer eliminar los semáforos de las calles ya que estos «limitan la libertad de tránsito».

Cito aquí algo que el amigo Karl dijo una vez y con lo que estoy completamente de acuerdo:

Los defensores de las licencias permisivas distinguen dos tipos de propietarios: usuarios y desarrolladores, y anteponen los intereses de éstos últimos. Los defensores de licencias tipo GPL consideran que el usuario/desarrollador son el mismo ente y por tanto uno no puede perjudicar al otro: un desarrollador no puede cerrar un código porque eso viola el derecho de otros desarrolladores o usuarios. En realidad, puede argumentarse que el concepto de “permisividad” da una idea equivocada: las licencias BSD tienen un potencial restrictivo que no tiene la GPL.

¿Por qué entonces la gente se enzarza en inútiles batallas de licencias donde la lógica suele estar completamente ausente? Aquel que dice que una licencia es inmoral no está siendo lógico, está sometiéndose a una creencia ciega, a una fe particular. Ha elegido a su licencia como a un dios electrónico el cual debe ser defendido por todos los medios posibles, aún los más absurdos.

Si, para bien y para mal la «viralidad» de las licencias GPL es real y las empresas que podrían ayudar a un proyecto suelen «asustarse» de las licencias virales. ¿Entonces? ¿Cuántas empresas contribuyen al sumamente *GPL kernel Linux y cuántas al totalmente permisivo kernel BSD?

¿Es realmente malo «asustar» a una empresa, obligándola a ser más cuidadosa en su uso de código no creado por sus empleados? ¿Es realmente bueno reducir las restricciones de modificar y redistribuir casi a cero? ¿Es realmente malo el hacerlo? No existe una respuesta única a estas preguntas: cada creativo, cada desarrollador debe analizar su situación y sus gustos personales para decidir qué va mejor con su trabajo: todas las decisiones en este campo son válidas, incluso aquellas que podríamos no compartir, incluso aquellas cuyas consecuencias podrían no ser de nuestro gusto.

El problema, como siempre, no lo crean las licencias: el problema nace de las personas que, ciegas en su fe, creen que las decisiones por ellos tomadas son mejores que las que toman otros.

Desgraciadamente las licencias de software no son los únicos dioses tonantes de la era digital: también tenemos los dioses que podemos tocar en forma de ídolos de plástico y arena cocida, y esos dioses intangibles pero no por eso menos presentes llamados «comunidades». Pero el presente artículo ha quedado ya muy largo por lo que volveré sobre estos temas más adelante.

Anuncios

  1. #1 por karlggest el 23 abril, 2014 - 0:59

    Hola.

    Muy interesante el artículo. Bueno, en realidad, es igual de interesante que todo lo que posteas en este blog.

    Después de leerme más de una vez en ForoSUSE, sabrás que me gustan mucho los matices y las anécdotas. Así que ahí va…

    Mediados los noventa del siglo pasado, Sun Microsystems hizo algo no muy usual en el mercado: liberó el código de su suite “StarOffice”. Recuerdo que tenía elementos muy interesantes, como un navegador web, su propio espacio de trabajo con su propia barra de tareas, y otras curiosidades que molaban un montón si lo que te planteabas era montar un equipo tipo “kiosko”, digamos en una oficina, por ejemplo: el espacio de trabajo, como es de esperar, !utilizaba su propio gestor de ventanas!

    ¡ah! la nostalgia… bueno, el asunto es que Sun Microsystems siguió distribuyendo StarOffice con licencia privativa. En general, puedes pensar por ejemplo en Google Talk, que usa tecnologías libres pero que es código privativo.

    El asunto importante es que la licencia GPL es viral en el sentido de que un código dado, una vez que es GPL, debe de seguir siéndolo. El autor no puede poner una licencia privativa en dicho código, ni siquiera si el código es modificado. La licencia establece que las partes no libres deben de ser perfectamente diferenciables, y el significado exacto de esa expresión es lo que marca principalmente las diferentes versiones de la licencia. Incluso es el motivo primordial de que Apache utilice la licencia BSD.

    Tú puedes hacer un derivado de un software GPL, y ponerle una licencia privativa. Pero las partes que utilices que estén cubiertas por la GPL deberán seguir estándolo. El asunto de OpenOffice está en la licencia utilizada por Sun, que no era exactamente GPL(1) y permitía expresamente crear versiones modificadas sin tener que publicar los cambios.

    Una curiosidad más: todo contenido intelectual, agotado el plazo que prescriba la ley para el material de turno, pasa a ser de dominio público. Así, los clásicos de la literatura, las partituras de los grandes compositores, etc. Curiosamente, tú puedes traducir una obra de Shakespeare y ponerle copyright a tu traducción. Creo que es la causa por la que en España las colecciones de clásicos de la literatura universal no incluyan a muchos autores en lengua castellana, y los que se incluyen son versiones “adaptadas” (por ejemplo, El Quijote). También hay cosas que son de dominio público por ley, como por ejemplo el genoma humano.

    Un saludo!!

  1. Los dioses digitales 2: los dioses de plástico y silicio | El pingüino tolkiano
  2. Los dioses digitales 3: Las comunidades son dioses celosos | El pingüino tolkiano
A %d blogueros les gusta esto: