Un dictamen sobre el proyecto de licencia pública de marca
Un buen amigo me pidió realimentación para el proyecto de licencia pública
de marca que promueve el gobierno de Brasil.
De ahí que hiciera algunas disquisiciones al respecto y he aquí algunos
resultados. Creo que su lectura será sugestiva al menos.
El análisis SOOS
He repasado los contenidos de http://www.softwarepublico.gov.br
y he comprendido que la mayoría de mis conclusiones actuales no encajan
en el proyecto de la «licencia pública de marca». Mis
indagaciones
están concebidas para tratar de identificar y resolver «las
ineficiencias del software». En ese sentido hemos trabajado mucho
en
desarrollar un, llamémosle, punto de vista «SOOS». La aplicación de un «análisis SOOS»
genera mucha información sobre los
problemas del software y apunta a nuevas líneas de trabajo para
resolverlos[1] [2] [3].
Es muy interesante descubrir muchos puntos de encuentro entre ambas
iniciativas, LPM y SOOS. Por activa o por pasiva
aparecen nuevos problemas que realmente siempre han estado ahí. Y un
caso
muy interesante es el problema que generan las marcas
al mundo del software en general y al FLOSS en particular. Me ha
alegrado mucho saber que en
Brasil se ha decidido trabajar en ello.
El principal problema que generan las marcas, desde el punto de vista SOOS,
es que son una terrible, y en la práctica infranqueable, barrera
contra
la convergencia. ¿A qué convergencias me refiero? En realidad todas
las
posibles, puesto que a más convergencia, más productividad, en el
sentido de la ley
de metcalfe. Como es sabido, la práctica en
el mundo del software —ambos abierto y privativo— es la de la más absoluta
divergencia/forking/fragmentación. Me atrevo a decir que en una enorme cantidad de los casos la divergencia se infiere a partir del principio de mercadotecnia
de la diferenciación, del que el concepto marca es el epítome.
En este dictamen mi problema es que no veo que el proyecto de «licencia pública de marca» sea
capaz de minimizar las divergencias del software. Desde mi punto de vista eso se
explica porque hay una relación 1:1 marca:producto.
Al márgen del análisis SOOS
Por otro lado hago el esfuerzo de olvidar todo el análisis SOOS
que realmente tanto me apasiona y mi impresión es que realmente la iniciativa LPM puede
proponer una solución legal reutilizable para un problema que no es el
más llamativo pero sí claramente recurrente. Está al orden del día saber la mayoría de las organizaciones de desarrollo de
software abierto importantes han necesitado escribir sus propios reglamentos y
licencias para la creación, uso y explotación de sus propias marcas:
En este sentido parece razonable hacer un esfuerzo de formulación y
crear un esquema legal claro, manejable y realista que pueda ser
reconocido y adoptado por cualquiera de estas organizaciones, incluso
sustituyendo sus actuales reglamentos, y sobre todo capaz de ser
adoptado por nuevos actores.
Directa o indirectamente es una ventaja clara para reducir los costes
de adopción del software. Para mi corazoncito SOOS
es una pequeña decepción porque no sirve claramente para maximizar los
efectos de red de metcalfe.
Antecedentes: las asociaciones para estándares abiertos
Me permito llamar la atención de que éste problema de marcas no es
nuevo o exclusivo del mundo del software abierto. Existe exactamente el
mismo en el mundo de los «estándares»[4] y, como decimos en
España,
para ejemplo un botón: el Objet Management Group.
Probablemente haya mucha más información que pueda estudiarse en Consortium Info y el
propio Andy Updegrove pueda ser un gran experto con quien contar.
Conclusión SOOS
La iniciativa LPM nos es interesante en tanto que llama la atención
del problema real de la ineficiencia del software. Pero a priori no
vemos cómo puede servir para la rotunda transformación del sector que
tan urgente nos parece.
Conclusión no SOOS
Dado
que hasta ahora yo no he tenido ocasión de estudiar este tema no puedo
aportar ni validar cuáles deben ser los requisitos que deba cumplir una
licencia pública de marca, o una recomendación legal equivalente, pero
sí me atrevo a sugerir algunas acciones:
- recopilar las soluciones legales creadas hasta ahora por
los colectivos más importantes de creación de software abierto y de
estándares;
- caracterizar las condiciones de licenciamiento,
y en ese sentido el trabajo de Ken Kretchmer para identificar las condiciones para ser abierto es
extremadamente inspirador;
- replicar la práctica de Creative Commons de crear un esquema
legal
abstracto, que en este caso imagino debe contemplar tanto la licencia en sí
como alguna clase de reglamento que la acompañe, capaz de ser traspuesto a los sistemas legales de cada país, a menos que se
demuestre la certeza de que hay suficiente compatibilidad legal internacional;
- considerar que tal vez sea necesario replicar el sistema CC
de
varios grados de licenciamiento diferentes para responder a diferentes
realidades; en la práctica ocurre exactamente igual con el
licenciamiento de software en el sistema combinado GPL/LGPL/BSD;
- validar la propuesta a través de socios comprometidos, idealmente
aquellos que pertenecen al primer punto de esta lista;
- idealmente,
mantener un comité de expertos que puedan evaluar la compatibilidad de
los esquemas de licenciamiento de terceros con el esquema del punto 2 y
la licencia del punto 3.
Syndicated 2010-01-28 16:16:00 from Ismael Olea
