Entradas

Reflexiones sobre la ponencia de licencias libres en las Jornadas OpenERP 2012

  • Igualar Copyleft y AGPL. De acuerdo con la FSF : “Copyleft es un método general para hacer un programa (u otro tipo de trabajo) libre, exigiendo que todas las versiones modificadas y extendidas del mismo sean también libres”. Es por tanto, un concepto, una idea, sobre la cual luego se pueden aplicar diversas licencias (las principales, y recomendadas por la FSF: FDLv1.3, FDLv1.2, FDLv1.1, GPLv3, GPLv2, GPLv1, LGPLv3, LGPLv2.1 y AGPLv3 de GNU).
  • Aunque pueda sonar raro, Copyleft no sustituye a Copyright, es más, lo necesita. ¿Como? Si, es así dado que si el código fuera liberado bajo dominio público, cualquiera podría “adueñarse” de él, y convertir en privativo cualquier derivado del mismo. Es difícil encontrar programas libres (Ayuda-Acerca de) que no están registrados bajo Copyright, precisamente porque es necesario para proteger su licencia libre. Aunque sería posible utilizar un registro diferente al Copyright para licenciar software libre, en la práctica esto no se hace (ni es recomendable).
  • Tampoco es aplicable al software las licencias Creative Commons (pensadas para otro tipo de trabajos, no software), explicadas muy bien aquí. Las licencias Copyleft para software son las mencionadas anteriormente.
  • Libre no es igual a gratis. Un error de base que puede confundir a muchos. Extraído, nuevamente de la FSF (punto 4): “Usted podrá cobrar cualquier importe o no cobrar nada por cada copia que distribuya, y podrá ofrecer soporte o protección de garantía mediante un pago.” Todos los que hemos trabajado con Joomla o Magento y hemos comprado extensiones GPL ya lo sabemos. También existen soluciones verticales de OpenERP que tienen un coste de “distribución y soporte”, que no licencia de uso.
  • Es necesario entender que el propietario del código es quien lo hace, y aunque el desarrollo sea colaborativo, dicha regla no cambia. Así, podemos encontrar desarrollos como Tryton, que cuenten con varios Copyrights, ya que al ser un fork de OpenERP cuenta con código realizado por diferentes partes. No hay un único autor, o un único propietario del programa. En este caso para realizar un cambio de licencia sería necesario un acuerdo unánime entre todas las partes.
  • Revisando rápidamente otros puntos de la presentación:
      1. Garantía de que nunca pase a ser código cerrado: las licencias libres no ofrecen esa garantía. Un software puede cambiar de licencia cuando el propietario así lo decida, como de hecho ha pasado (como ya explicamos aquí, en el supuesto 2)
      2. No puede haber otro beneficiario que no sea el autor: es un error de base. Por supuesto que yo puedo tomar un proyecto, modificarlo y revenderlo. Esto es lo que hace RedHat, entre otros. Pero es lógico que pueda ser así, de otra manera todos los beneficios irían al que escribió la primera línea de código del kernel, o de la base de datos o de la librería principal que utiliza el software.
  • Por lo demás, la diferencia entre software libre y software privativo, es básicamente una característica jurídica. No se es mejor software (técnicamente hablando) por ser libre, y hay buenos y malos programas tanto libres como privativos. El software privativo sólo necesita un cambio de licencia para volverse libre, y viceversa. No posiciona mejor en Internet mágicamente ni va a atraer una comunidad que se haga cargo de mantenerlo, si bien con el trabajo adecuado esto puede ser posible.

Como la mayoría de reflexiones ya se hicieron en su momento para el portal openerpspain, recomendamos la lectura del artículo:

¿Es mejor para mi empresa el sofware libre?

Otra pequeña aclaración: las licencias libres no obligan a liberar código realizado, lo que obligan es a distribuir los binarios junto con el código fuente. Es decir, si yo tomo un desarrollo libre y lo mejoro para uso propio, no tengo obligación de liberarlo públicamente. Si ese desarrollo lo comercializo o distribuyo, tampoco existe la obligación de liberarlo más allá de las copias con las que se han distribuido los binarios (es decir, a nuestros clientes o amigos). La AGPL sí que va un poco más lejos, y obliga a entregar el código incluso en el caso de que los binarios no se entreguen, como es el caso de los servicios saas.

Yendo más allá, incluso dentro del mundo del software libre, hay conceptos más allá del código. Por ejemplo Android y OpenERP son productos libres, pero las decisiones, el rumbo y el código están marcados y decididos por una única empresa, mientras que otros desarrollos como LibreOffice o Tryton son más comunitarios, digamos, meritocráticos. Las decisiones técnicas y el rumbo del proyecto son decididas por la comunidad de usuarios, y éstos tienen más peso en función de las aportaciones realizadas. Evidentemente cuanto más libre y participativo es un desarrollo, mayor es la posibilidad de atraer una comunidad grande y motivada.

Como se podría hablar mucho más largo y tendido sobre esto, quizás merezca la pena alargarlo en otro artículo más completo, o volver a tratar el tema en una charla o mesa redonda en las próximas jornadas de OpenERP.

¿Qué es Creative Commons?

CreativeCommons Por cierto, la licencia de uso CC no es más que la adaptación para obras literarias y artísticas de la licencia GPL, originalmente pensada y utilizada para para programas informáticos.