No sólo software

Una vez centrado el debate, se puede empezar a discutir: ¿están los mecanismos jurídicos actuales funcionando como debieran?

Los datos nos dicen que no: la propiedad intelectual, no sólo no ha aumentado la innovación, sino que ha creado una industria altamente concentrada y muy poco innovadora. En el caso de la industria farmacéutica esto tiene además consecuencias peligrosas. En el caso de la informática, se ha ido desarrollando un movimiento contestatario y vanguardista que ha roto las bases mismas de la industria informática convencional (venta de licencias de producto) obligándola a reconvertirse o perecer.

Así, la experiencia del software libre (y ahora también los estudios económicos) nos demuestran que, en este momento histórico, la propiedad intelectual no es necesaria [PDF ] para garantizar la innovación y la justa remuneración por el trabajo realizado, sino todo lo contrario: está siendo perjudicial.

El estudio que reseña el New York Times dice expresamente que …

The two researchers have analyzed data from 1976 to 1999, the most recent year with complete data. They found that starting in the late 1990s, publicly traded companies saw patent litigation costs outstrip patent profits.

Llegados a este punto, es claro que la propiedad intelectual no funciona y que argumentar de un modo cuasi-religioso a favor de ella es una actitud irresponsable. Parece claro también que no debemos aferrarnos al status quo defendiendo un mecanismo que genera más problemas de los que pretende resolver. Por estos motivos (éticos y económicos), apoyo la abolición de la propiedad intelectual.

Principales referencias:

• Against Intellectual Monopoly; David Levine, Michael Boldrine
• Do patents work?; James Bessen, Michael J. Meurer

Leyendo un post de La pastilla roja me siento un poco defraudado. Un blog que es uno de mis referentes… y que en este caso es tan poco riguroso.

Lo principal que uno debe conocer cuando se enfrenta a su estudio, es que la propiedad intelectual es un mecanismo estatal que pretende incentivar la innovación y recompensar al creador. Nada más, pero tampoco nada menos. Y en eso se equivoca Sergio Montoro en este post. Él le otorga categoría de derecho natural. Y no. No es eso cierto. Dejémoslo claro.

La propiedad intelectual no forma parte del derecho natural ni mucho menos, sino que forma parte del derecho positivo. Es decir, es una medida puesta por el Estado en aras de mediar entre los intereses públicos (que existan más y mejores medicamentos, programas de software, cultura, …) y los privados (la justa remuneración de los creadores).

Pero “las relaciones jurídicas y sociales dan forma a lo posible hasta convertirlo en lo real“. Y ése es el centro del debate. ¿Son adecuadas las relaciones jurídicas heredadas del industrialismo para la era de la información?

Desde esta base es desde la que podemos empezar a discutir… ¿qué ocurriría si ese mecanismo ya no fuese válido? ¿qué si ya no sirviese para la labor para la que fue creado?

El debate serio que debemos tener es ése, y no otro cualquiera cuasi-religioso. Porque lo que está en discusión es un sistema de propiedad intelectual adecuado a las condiciones del siglo XXI, no al del XIX.

Es tan necesario como debe ser riguroso, porque no es trivial el resultado del debate ni el mundo que se configura en torno a él.

Estoy aprovechando las vacaciones para finalizar mi trabajo final de asignatura. En la materia de introducción del máster se han tocado varios temas de soslayo, muchos de los cuales me interesan enormemente, por lo que me ha costado realizar la propuesta. Finalmente tuve que descartar otros 2 que tenía en mente:

Si hasta los títulos tenía.. pero de igual modo que en las películas, uno es esclavo de sus palabras y tiene el derecho a permanecer en silencio… aunque pocas veces yo lo ejerza xD

Me explico. Veréis, durante una de las clases, Gregorio nos presentó un paper sobre el copyright de Debian a lo largo del tiempo. El estudio formaba parte de la nueva rama de investigación que quiere iniciar la gente de Libresoft y que trata de responder a la pregunta: ¿cómo las comunidades de usuarios y las compañías colaboran en el desarrollo de software libre?

Este estudio en concreto, consistía en analizar el copyright de todos los paquetes incluidos en debian con el objetivo de determinar a quien pertenecía. Los resultados son claros: el porcentaje de código con copyright de las empresas era del 14% en la Debian Hamm (1998) y supone un 20% en la Debian Sarge (2005), una cantidad no despreciable pero tampoco demasiado relevante con respecto a la producción individual (en torno al 60%).

Este resultado podría dar a entender que la presencia de las empresas en la comunidad (como desarrolladoras de software) es muy limitada y que se están especializando en otras tareas, por ejemplo: márketing, comercialización de producto, integración, etc.

Fue entonces cuando me erigí en defensor de las empresas como desarrolladoras (Roberto, luego de nuestra experiencia con la empresa CAD… todo ha cambiado! ;D). Como decía, me erigí en defensor de la producción empresarial diciendo algo como:

Me parece que la participación de las empresas está distorsionada por la naturaleza del estudio.

Si -tal y como supongo- la distribución del tamaño de los paquetes en Debian sigue una distribución paretiana, es decir, un modelo Long Tail, existirán muchos paquetes muy pequeños creados por un sólo desarrollador individual, concentrándose la participación de las empresas en los paquetes de mayor tamaño.

Creo que si realizamos el mismo análisis para el 20% de los paquetes de mayor tamaño (por seguir la ley de pareto), el copyright en manos de las empresas aumentará notablemente y superará al copyright de personas individuales. Esto dará una medida de la participación más realista, ya que los paquetes mayores suelen ser más críticos: el kernel, el entorno de escritorio, el sistema de ventanas X11, etc. Se podría argüir así todo lo contrario: la participación de las empresas en el desarrollo de software es crucial.

Y claro, uno no puede tirar una piedra de este calibre ante los libresoft y esconder la mano. Así fue cómo surgió mi trabajo. Por lo que, en estas vacaciones, me toca realizar análisis del copyright de Debian que demuestren -o tiren abajo- mis hipótesis.

Como además estamos en Navidad, la gente de Libresoft me ha cedido amablemente los datos recopilados en su estudio para que pueda jugar con ellos (gracias chicos!). Ahora mismo me siento como un niñito con zapatos nuevos… jugando con su copyright

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