La gran mayoría de proyectos de Software Libre tienen a su alrededor una comunidad, más o menos grande, que se debe mantener de alguna forma para que el proyecto sea sostenible y perdure en el tiempo. Esta necesidad de sostenibilidad es la que hace que la elección de la licencia o licencias bajo las que se va a distribuir el producto sea muy importante.
Licencias y modelos de negocio
Con respecto a esto, hace unos días navegando por Internet me encontré con el artículo Open Source and Bussiness Model Innovation. The Funambol case de Alberto Onetti y Fabrizio Capobianco que, a pesar de ser de 2005, hace una descripción, a mi entender, muy buena de la relación entre licencias y modelos de negocio en proyectos de Software Libre y por ende de la sostenibilidad del proyecto.
Primero, define dos grandes grupos de licencias:
- Licencias de tipo recíprocas o copyleft, como la GPL (GNU Public License) que aseguran que cualquier obra derivada va a mantener la misma licencia que la que le dio el autor original.
- Licencias permisivas o tipo BSD (Berkeley Software Distribution), que permiten que las obras derivadas puedan tener cualquier tipo de licencia, incluso privativas.
Y en relación con estos dos grupos de licencias define tres grandes tipos de modelos de negocio:
- Modelos de negocio GPL/LGPL (Lesser GPL): Las licencias tipo GPL limitan la adopción comercial del software ya que obligan a liberar también las modificaciones o mejoras realizadas. Las compañías que usan estos tipos de licencia tienen como modelo el servicio a la comunidad y obtienen beneficios de los servicios profesionales que prestan tales como: mantenimiento, personalización, consultoría y formación. Ejemplos de este tipo son el kernel Linux, Gimp, Red Hat, que obtiene sus beneficios de contratos de soporte, consultoría y formación, entre otros.
- Modelos de negocio BSD/Apache: Este tipo de licencias permiten a las empresas convertir al software en privativo habiendo o no, realizado modificaciones al mismo. El código creado o sus derivados, bajo este tipo de licencias, puede ser comercializado por cualquiera, incluso sin ser el desarrollador original. Los beneficios pueden entonces venir tanto de la venta de licencias como de servicios profesionales igual que en el modelo GPL. En muchos casos la licencia es usada para el núcleo (core) de la aplicación y así favorecer su difusión y las licencias privativas para módulos o extensiones del mismo denominándose este modelo open-core. Un ejemplo puede ser Zend creadora de PHP que tiene el núcleo libre y un montón de herramientas privativas alrededor.
- Modelo de negocio de doble licenciamiento: Se basa en disponer de dos licencias una tipo copyleft fuerte y otra privativa y es el cliente quien elige cual quiere usar. Las organizaciones que quieran desarrollar aplicaciones de software libre obtendrán el código como si fuese un producto más de software libre con todos sus beneficios y obligaciones y las que no quieran liberar sus productos adquieren una licencia privativa que les da derecho a no abrir el código. Esto sólo funciona con licencias copyleft fuerte como GPL ya que las licencias BSD lo permiten directamente sin comprar ninguna licencia privativa. Las empresas que usan licenciamiento dual obtienen sus beneficios principalmente de la venta de licencias. Un ejemplo típico de este modelo en MySQL y entre otros está también Funambol.
En el modelo de software privativo el beneficio económico viene fundamentalmente de la venta de licencias mientras que en el Software Libre puede venir de la venta de licencias pero fundamentalmente viene de la venta de los servicios que rodean al propio software.
Conclusión
La decisión del tipo de licencia que vamos a elegir para un proyecto de Software Libre va a depender no solo de nuestra filosofía de vida si no que también de la forma en la que queramos hacer sostenible al proyecto. Si queremos que un proyecto se extienda mucho la elección es BSD pero corremos el riesgo de que alguien lo coja y se aproveche de él, eso sí, nuestro código seguirá siendo libre y si queremos que todas las mejoras reviertan en el código original usaremos GPL pero para las empresas no suele ser atractivo GPL ya que les obliga a liberar sus modificaciones, que pueden ser un activo importante para mantener a raya a la competencia
Bueno, cada uno que tome su decisión según lo que quiera hacer.
Hasta otra …