En los últimos posts, he tratado de introducir los conceptos de potlacht y mumi, para, a partir de ellos, construir una analogía con la actualidad. Aceptando ahora esas condiciones de partida, podemos centrarnos de lleno en explicar el papel de los mumi y preguntarnos quiénes son los del siglo XXI.

Como hemos explicado, en entornos económicos que siguen la lógica de la abundancia, como en el software libre, aparecen ciertas estructuras y agentes especiales: los potlacht y los mumi por seguir la terminología de Harris.

Asociando esos patrones antropológicos con la época actual, parece sencillo defender que, por ejemplo, Richard Stallman o Google (enlazo a un listado de servicios y productos) son nuestros actuales Mumis, puesto que consiguen agregar voluntades en torno a un proyecto ideológico o facilitar el uso masivo de las herramientas asociadas a internet (gmail es sin duda la killer app de los correos on-line, blogspot fue la plataforma de referencia en los blogs, con google docs han reinventado la manera de trabajar, …).

Por otro lado, el patrón potlacht, puede perfectamente asociarse con los bounties (eventos que tratan de incentivar la creación de código libre), de los que ya hablamos. Pero de hecho, podemos ir más allá y decir que el potlacht, podría asimilarse a la manera misma en que se construyen algunos proyectos de software libre: agregación de múltiples voluntades convergentes de un modo intenso y durante un intervalo de tiempo limitado, pero cuyo esfuerzo repercute (o se redistribuye) a toda la comunidad (con la creación del producto/servicio).

Es ésta idea la que he rescatado brevemente (y de la que prometí escribir chicos :D) durante el curso que estamos tomando ahora en el máster (dinámica de las comunidades de software libre).

Me parece muy interesante esta analogía porque si la clave de un proyecto libre es crear la comunidad, conocer los patrones del entorno en que nos movemos es imprescindible.

• la financiación del producto
  
• el modelo de negocio asociado (o cómo retornar la inversión)

Luego de leer algunos materiales y discutir algunos casos, se hizo un ejercicio que consistió en asociar cada uno de los modelos con algunas empresas muy conocidas. En la parte de financiación obtuvimos el siguiente mapa de conceptos (hechos con la aplicación VYM: ViewYourMind):
En resumen, los esquemas de financiación pueden categorizarse según ésta sea:

1. Pública (modelo LinEx)
2. Privada sin ánimo de lucro (modelo FSF)
3. Mejoras específicas (modelo Wine-Corel)
4. Venta de servicios relacionados (modelo O’Reilly)
5. Inversión interna (que da lugar a diversos modelos de negocio)
6. Otros: marketplace (modelo SourceForge), donaciones, bounties (eventos que tratan de incentivar la creación de código libre)…

Por otra parte, en cuanto a los modelos de negocio, también realizamos nuestro mapa de conceptos con empresas conocidas:

Este esquema lo realizamos según la clasificación de Hecker (página personal), uno de los artífices de la liberación del código de Netscape y que actualmente trabaja para la Fundación Mozilla. Según Hecker se pueden diferenciar los siguientes modelos de negocio (que difieren un poco por los identificados en los materiales del curso):

1. Venta de soporte y servicios asociados (modelo Ubuntu)
2. Loss leader (venta de productos propietarios asociados al libre, modelo Ximian-Exchange)
3. Venta de hardware (modelo Nokia-maemo)
4. Venta de servicios (modelo google)
5. Venta de marca (venta de derechos de uso, formación; modelo MySQL)
6. Franquiciado de la marca (certificaciones, partners; modelo RedHat, MySQL)
7. Sell it, Free it (modelo GNAT)
8. Venta de productos relacionados (modelo O’Reilly)

A pesar del enfoque académico de este post, es evidente que los modelos no son estancos, que las empresas pueden usar varios de forma simultánea. El típico caso sería el de MYSQL que vende servicios (consulting, support), marca y franquiciado.

Con este post espero haber introducido los aspectos económicos de un proyecto libre. Evidentemente, no todo son facilidades… y sin embargo, el ecosistema de negocio generado por la filosofía open source es muy rico y variado.

Para que un software se considere software libre debe cumplir las 4 condiciones de la Free Software Foundation (o, similarmente las 10 directrices de la Open Source Initiative). De cualquier otro modo, no lo será.

Pero en lo que respecta al licenciamento del mismo podemos destacar algunas diferencias con importantes consecuencias prácticas y filosóficas. Se pueden destacar 2 categorías principales de licencias libres:

En este punto emergen 2 preguntas principales y los debates que las siguen:

Lo único que sabemos en la actualidad es que con la GPL (principal exponente de las robustas) se licencia el 65% de los proyectos de Freshmeat, y con la licencia BSD (como licencia permisiva principal) en torno al 6% (sumando bsd original y modificada). Y que a partir de código BSD se ha seguido desarrollando muchos proyectos libres desde hace 20 años.

Por ello, no es descabellado pensar que a pesar de existir la posibilidad de realizar proyectos cerrados a partir de licencias permisivas (y, como en un juego de suma cero, ello podría redundar en menoscabo del software libre), los incentivos para hacerlos abiertos son tales que -de momento- no tenemos el problema de los free riders en el mundo del software.

Para próximos posts (o como contribuciones vuestras a éste ;D) queda pendiente un análisis de los paquetes Debian con una y otra licencia, o incluso la cantidad de código licenciado con una y otra.

Transversalmente a estes 2 términos, se pueden analizar las licencias según sean o no compatibles entre sí. Nosotros, las analizaremos según sean o no compatibles con la GPL:

una licencia se considera GPL-compatible cuando no añade ninguna restricción adicional a las impuestas por ésta.

Como consecuencia práctica se tiene que el código con una licencia no compatible con la GPL, no puede integrarse con código GPL.

Tanto las licencias robustas como las permisivas pueden ser gpl-compatible (o no). Probablemente, uno de los casos más famosos es el de la licencia BSD. La BSD original, tenía como restricción adicional a la GPL que:

Aunque pueda parecer demasiado estricta la GPL-compatibilidad, no olvidemos que pretende ser una licencia, un mecanismo legal al que aferrarse. Por lo tanto, aceptar la anterior restricción suponía abrir legalmente la puerta a otras restricciones similares.

Siendo así, el código BSD no era GPL-compatible y no podía integrarse con ningún código de este tipo. Por ello se creó la licencia BSD modificada que elimina esta restricción, haciéndose de ese modo GPL-compatible (dando soporte legal a la integración con código GPL).

Con este post, espero haber aclarado el mapa de conceptos de licencias libres y su terminología.

Y como ejercicio final para comprobar lo que has aprendido, puedes intentar descubrir qué tipo de licencia tiene la distribución Jesúx .. y postearlo en los comentarios si lo deseas