Una de las preguntas más frecuentes a la hora de liberar un proyecto de software es la selección de la licencia. En función de los objetivos técnicos y estratégicos del proyecto, puede ser interesante considerar una estrategia que se ha llamado “dual licensing” (licenciamiento dual o doble).
 
Esta estrategia se usa sobre todo por empresas “comerciales” involucradas en el desarrollo y distribución de software libre (“Professional Open Source Companies”), como MySQL, Trolltech, iText, y otras, pero no siempre. A veces se usa esta estrategia para permitir el uso de un software en proyectos con licencias de SFA incompatibles: por ejemplo la licencia doble “CDDL o GPL2” que se usa para gran parte de la plataforma Java o Glassfish (cuando fue liberado por Sun Microsystems).
 
Cuando se usan una licencia de SFA y una licencia “cerrada”, esta estrategia permite por un lado participar en y beneficiarse de la comunidad libre (con respecto a una versión del programa bajo licencia libre) y por otro lado obtener ingresos a partir de la distribución del mismo bajo licencia propietaria y comercial. El principio que rige es un “quid pro quo”: la empresa ofrece algo a la comunidad (la versión libre) pero recibe algo a cambio (correcciones de errores, extensiones, etc.) que puede – o no – incluir en el producto propietario.
 
Distinguimos habitualmente tres modelos de “licenciamiento doble”:
 
a) Un solo software, dos licencias (MySQL, Trolltech, Jahia, Sleepycat, eXoplatform...): El proyecto ofrece el mismo software

  • bajo una licencia libre, a veces con limitaciones “para usos libres y no-comerciales” pero esta limitación no es compatible con la definición de software libre o la OSD, por tanto se acercan lo más posible utilizando la licencia GPL (que impide su reutilización en software cerrado), y
  • bajo una licencia propietaria y de pago para usos “comerciales” (es decir, cuando uno quiere cerrar el código en un software distribuido bajo licencia propietaria).

b) Dos softwares casi similares, dos licencias (SugarCRM, Jahia, otros de tipo “Open Core”- un modelo más reciente, similar en algunos aspectos al freeware): el proyecto ofrece

  • una versión básica del programa bajo licencia libre y gratuita; y
  • una versión más completa bajo licencia propietaria (para evitar redistribuciones) y de pago (para obtener ingresos).

c) Un software, una licencia (pero con opción de elegir otra licencia): el licenciante ofrece el software bajo una licencia que tiene dos opciones, a elección del licenciante (licencia MPL) o del usuario (licencias LGPL o CeCILL). Es el caso de Glassfish y varios otros proyectos, para maximizar el uso del software en proyectos libres bajo otras licencias. De hecho, la EUPL 1.1 incluye un sistema similar, que permite incorporar el software en proyectos bajo licencias normalmente incompatibles con la EUPL, pero expresamente permitidas (en su Anexo; CPL, MPL, GPL...), así como la nueva MPL2 (que incluye la compatibilidad expresa con GPL, salvo que se excluya).
 
En el caso (a), el modelo de negocio de la empresa se basa en ingresos obtenidos a partir de la versión comercial (distribuida para usos y distribuciones comerciales). Normalmente la empresa mantiene la titularidad sobre todo el código (por un desarrollo interno o por la cesión de derechos por los contribuidores), lo cual permite “vender” el producto bajo una licencia propietaria. Se ha comentado que son programas que no requieren extensiones o plug-ins, y por lo tanto no usan el modelo (b). Habitualmente, se usa la licencia GPL para la versión libre para evitar que otros agreguen una extensión propietaria y vendan lo que será básicamente el mismo producto, y para evitar los forks (proyectos paralelos pero diferentes, en base al mismo código, que robarían parte del mercado del producto libre). La licencia libre permite establecer el producto como “estándar” y favorece las contribuciones.
 
En el caso (b), los ingresos vienen de la venta de licencias propietarias sobre la versión extendida y mejorada del software. Las condiciones de la licencia restrictiva impiden que las versiones más completas vuelvan a la comunidad y se liberen. Las empresas que usan esta estrategia suelen alegar que, a medida que el producto avance, las extensiones irán incorporándose dentro de la aplicación “básica” libre. Además, las empresas consideran importante mantener su imagen en relación con la versión libre, para fomentar o incentivar la compra de la versión comercial, por lo tanto agregan pactos sobre branding (SugarCRM, en sus inicios, Pentaho, Zimbra).
 
El modelo (c) no parece soportar modelos de negocio comerciales a primera vista (los ejemplos más “comerciales” eran OpenOffice.org, pero se considera que no se trataba de una estrategia comercial sino de ganar cuotas de mercado de productos propietarios). Justamente, la FSF “promociona” la licencia LGPL como herramienta legal para establecer un software como “estándar” en la industria: su copyleft “suave” permite el uso libre como librería en cualquier programa – incluso su posible incorporación en productos propietarios. Otro proyecto con esta estrategia, Mozilla, es gestionado por una fundación sin ánimo de lucro. Es posible que se use esta estrategia para favorecer la adopción de un producto, directamente o indirectamente a través de socios de negocio (intermediarios o consultores que proveen servicios basados en el producto), y ganar cuotas de mercado - lo que lleva a más ingresos basados en la provisión de soporte de segundo nivel (y quizás adaptaciones particulares).
 
No obstante, hay otras maneras de usar dos licencias: hay proyectos que crean un “framework” general o “commons” que licencian bajo licencia permisiva (Apache 2 es popular) y luego crean una aplicación “encima” que licencian bajo otra licencia, normalmente con un grado u otro de copyleft. Asimismo, hay proyectos con estructura cliente/servidor, que utilizan licencias diferentes para la parte cliente y la parte servidor.