Traducido para Rebelión por Ricardo García Pérez
Ya he escrito en otras ocasiones lo escéptico que soy acerca de los verdaderos motivos de la defensa y exigencia que hace Canonical Ltd. de la cesión de derechos corporativos a empresas lucrativas sin que las empresas tengan que prometer adherirse al sistema de copyleft . He pedido a menudo a algunos empleados de Canonical, entre los que se encuentran Jono Bacon , Amanda Brock , Jane Silber , el propio Mark Shuttleworth y ( por los comentarios que aparecen en este otro blog ) Matt Asay , que expliquen (a) ¿por qué exactamente exigen en sus proyectos que se les cedan los derechos , en lugar de limitarse a pedir a los colaboradores que suscriban formalmente una GNU Licencia Pública General de GNU [GNU GPL] ? (al modo de proyectos como Linux) y, b) ¿por qué cuando un colaborador cede los derechos a Canonical Ltd. esta se niega a prometer que mantendrá la condición de copyleft del software y no lo convertirá nunca en software propietario? ( La Fundación del Software Libre [FSF, Free Software Foundation] , por ejemplo, siempre ha hecho esto último con las cesiones). Cuando planteo estas preguntas a los empleados de Canonical Ltd. siempre cambian astutamente de tema.
De hecho, llevo formulando estas preguntas al menos un año y medio, pero empecé a preocuparme de verdad a principios de este año, cuando Mark Shuttleworth afirmó falsamente que «el sistema de cesión de derechos de Canonical Ltd. no se diferenciaba en nada del de la FSF». El acontecimiento me dejó claro que ya estaba en marcha alguna clase de trabajo de venta: Canonical Ltd. estaba tratando de vender a la comunidad algo que la comunidad no quiere o no necesita y, para conseguirlo, tratando de aprovechar el buen nombre de otras personas y organizaciones.
Desde aquella entrevista del mes de febrero Canonical Ltd. ha lanzado un producto denominado de forma manipuladora «Proyecto Armonía» [«Project Harmony»]. Lo comercializan como una especie de «cumbre» sobre algo: concebida para que no tenga ninguna otro contenido específico más que «debatir» la cuestión de los contratos de los colaboradores y la cesión de los derechos y alcanzar al respecto el «consenso de la comunidad». No obstante, su objetivo se limitaba a conseguir que los miembros de la comunidad presten su buen nombre al proceso. Canonical Ltd. ha tratado incluso de utilizar con frecuencia la participación de personas reputadas para que parezca que hay mucha gente que respalda su proyecto comercial. En realidad, La FSF se ha desmarcado hace poco del proceso a causa de las acciones de Canonical Ltd. en este aspecto. Y Simon Phipps también se había desvinculado de forma similar con anterioridad.
Sin embargo, al parecer, Canonical Ltd. cree ahora haber triunfado con la labor de venta porque ahora confiesa el verdadero motivo. En una sesión de chat, (2) Shuttleworth reconoce por fin que su objetivo es incrementar el volumen de actividad «Open Core». Concretamente, Shuttleworth afirma lo siguiente a las 15:21 (y más adelante):
[C]omparemos la biblioteca multiplataforma Qt con la Gtk. Qt está hecha con un contrato de colaboración; Gtk, no; durante algún tiempo, en la época de la burbuja, Sun, Red Hat, Ximian y muchas otras empresas metieron dinero en Gtk y creció y mejoró con rapidez pero, luego, perdieron el interés y se estancó. Qt era propiedad de Trolltech, era de código abierto (GPL), pero gracias al contrato de colaboración tenían muchas alternativas, incluida la de convertirlo en una licencia propietaria, que para mí está muy bien además de la GPL, y luego, como eran propietarios absolutos de Qt, se convirtieron una adquisición atractiva para Nokia, En resumen, el ecosistema Qt ha salido beneficciado [sic] y el ecosistema Gtk, no.
Es preciso analizar con cuidado la situación para descifrar qué pasa aquí. En primer lugar, Shuttleworth resta importancia a mucha historia muy compleja sobre Qt. La biblioteca multiplataforma Qt empezó con una licencia no libre (QPL), que más adelante, se convirtió en una licencia de software libre incompatible con GPL. Al cabo de unos años de esta extraña licencia de libertad de software propia de la proliferación de licencias, Trolltech dio con el modelo «Open Core» (inspirándose seguramente en la empresa de software MySQL AB), y cambió a GPL. Cuando Nokia adquirió Trolltech, la propia Nokia descubrió que el «Open Core» en exclusiva era malo para el conjunto de códigos fuente y (como presagié en su momento) volvió a amparar el conjunto de códigos fuente en LGPL (la misma licencia que emplea Gtk). Pocos meses después de aquello… ¡Nokia eliminó por completo la cesión de derechos para Qt! (es decir, Sutthelworth simplemente se equivoca de plano en este aspecto.) De hecho, en lugar de sustentar su argumento a favor del modelo Open Core, Shuttleworth en realidad aportaba la muestra principal de la lección aprendida con el caso Nokia/Trolltech: «no firmes acuerdos de colaboración al estilo Open Core, o te arrepentirás». (RMS también ha publicado hace poco un buen artículo al respecto).
Además, Shuttleworth también ignora por completo infinidad de angustia histórica de comunidades enteras que dependen de Qt, que a menudo tuvieron dificultades para conseguir parches no convencionales y encontraron obstáculos semejantes cuando manejaban una biblioteca «Open Core» gestionada con ánimo de lucro. (En realidad, esas eran algunas de las razones que Nokia adujo en mayo de 2009 para cambiar de política). Aun cuando el negocio de recalificar una licencia de software libre a propietaria sea lo que convirtió a Trolltech en una adquisición tan lucrativa para Nokia, ¿por qué abandonaron el modelo de negocio por completo al cabo de cuatro meses de la adquisición?
Pese a todo, el comentario de la «adquisición lucrativa» señalado por Shuttleworth tiene cierta validez. Por ejemplo, el modelo «Open Core» hace la boca agua a grupos acaudalados y con afán de lucro (por ejemplo, comunidades virtuales). Mientras tanto, la gente como yo, como Simon Phipps, como Chris Kemp (de la NASA), John Mark Walker, Tarus Blog y muchos otros mostramos, o bien mucho escepticismo hacia el modelo «Open Core», o bien firmemente en contra. La razón por la que encuentra tanta oposición es que el modelo «Open Core» es un modo amistoso con las comunidades virtuales de controlar todos los «activos» del copyright mientras simula perseguir el objetivo de forjar una comunidad de Código Abierto. Como es natural, el verdadero objetivo del modelo «Open Core» es realizar un movimiento de posicionamiento para la captación. (Los detalles al respecto exceden el ámbito de esta entrega y se reflejan de forma adecuada en los enlaces a otras páginas que he señalado aquí.)
Por lo que se refiere a la tesis de Shuttleworth sobre el estancamiento de Gtk, después de haber acudido el verano pasado a la Conferencia Europea de Usuarios y Desarrolladores de GNOME [un entorno de escritoro] (GUADEC, GNOME User and Developer European Comference), estoy casi convencido de que la comunidad GNOME goza de una salud extraordinaria. De hecho, como muestra el Censo GNOME de Dave Neary, los conjuntos de códigos fuente de GNOME son fruto de una colaboración adecuada de diversas entidades corporativas y (lo que es más importante) voluntarios. A la gente de las empresas lucrativas, como Shuttleworth y sus directivos, no les suelen gustar las comunidades donde un agente sin ánimo de lucro (en este caso, la Fundación GNOME) dirige un proyecto y mantiene a raya los múltiples intereses lucrativos. En realidad, a él le disgusta tanto que cuando hace poco GNOME documentó sus tradicionales políticas sobre el copyright envió a Silber al Consejo Asesor de GNOME (la primera y única vez que Canonical Ltd. envió a una persona de semejante nivel al Consejo Asesor) para que argumentara contra la predilección tradicional de la comunidad GNOME por la cesión de derechos en sus proyectos. (3) El argumento principal de Silber era que parecía poco razonable que los colaboradores individuales pidieran siquiera conservar sus derechos, puesto que Canonical Ltd. deposita la mayor parte del trabajo en los proyectos que requieren la cesión de los derechos. Dicho de otro modo, su argumento en favor de la igualdad era contrario a la libertad de software: una empresa lucrativa es más valiosa para la comunidad que un colaborador individual. Por fortuna, la Fundación GNOME no se lo tragó, y continuó su trabajo con Intel para liberar el conjunto de códigos fuente de Clutter de las cesiones de derechos (y después de aquello la labor ha tenido éxito). También resulta particularmente irónico que, pocos meses después, Neary demostrara que la misma compañía que esgrimía ese argumento contribuye un 22 por ciento menos en el conjunto de códigos fuente de GNOME que los voluntarios acerca de los cuales Silber sostenía antes que «no aportan lo suficiente para justificar que se mantenga su copyright«.
Entonces, ¿por qué Shuttleworth y su equipo han emprendido una campaña de un año para convencer a todo el mundo de que suscriba el modelo «Open Core» y renuncie a todos los derechos que les proporciona el copyleft? Bueno, en el mismo foro que he citado más arriba (a las 15:15), Shuttleworth reconoce que le queda «algún» trabajo que hacer para que Canonical Ltd. sea rentable. Y ahí está la conexión: Shuttleworth reconoce que la rentabilidad de Canonical Ltd. es un objetivo principal (cosa posiblemente obvia). Luego, en su siguiente respuesta, expone por extenso lo rentable e importante que es el modelo «Open Core». Shuttleworth sostiene que debemos aceptar el modelo «Open Core» simplemente por lo importante que es que Canonical Ltd. sea rentable.
El argumento de Shuttleworth me recuerda una historia que Michael Moore (conocido por el documental Roger and Me pero que, desde entonces, ha hecho otros) refirió en un acto de firma de libros de mediados de la década de 1990. Moore decía (ahora cito de memoria del canal de televisión australiano BTW):
Es inevitable que acabe subiendo a algún avión junto a algún directivo de empresa. Siempre me miran unas cuantas veces y dicen: «Eh, yo te conozco, tú eres Roger Moore [carcajadas del público]. Lo que yo quisiera saber es qué demonios tienes tú contra el ánimo de lucro? ¿Qué tiene de malo el lucro, de todas formas?». La respuesta que les doy es sencilla: el lucro no tiene absolutamente nada de malo. Lo que pregunto es: ¿hasta dónde hay que permitir que se obtengan beneficios? Todos coincidimos en que no podemos aprovecharnos del trabajo infantil u otras cosas, aun cuando sirva para aumentar los beneficios. Pero antes, hace mucho, este tipo de prácticas espantosas eran aceptables para las empresas. De modo que lo que digo es que todavía hacen falta más cambios para equilibrar el ímpetu del afán de lucro con lo que es correcto para los trabajadores.
Cito con toda esta extensión para dejarlo sobradamente claro: no me opongo a que Canonical Ltd. obtenga beneficios apoyando la libertad de software . Me alegra que Shuttleworth haya contribuido con una parte nada banal de su riqueza personal a crear una empresa que da trabajo a muchos desarrolladores excelentes de software libre (e incluso que a veces les permita trabajar en proyectos a contracorriente). Pero la verdadera pregunta es: ¿vale la pena abandonar los valores de la libertad de software simplemente para que Canonical Ltd. obtenga beneficios? ¿Debemos aceptar sin más que los servicios de redes propietarias como UbuntuOne , integrados en casi todos los menús de los escritorios, son razonables simplemente porque podrían ayudar a Canonical Ltd. a ganar unos cuantos billetes? ¿Creemos que debemos abandonar las garantías de trato justo para todos que ofrece el copyleft y otorgar poder absoluto a las empresas lucrativas para que conviertan en propietario el software bajo GPL simplemente porque pueden contratar a unos cuantos desarrolladores de software libre para que trabajen, sobre todo, en proyectos que no van contra la corriente?
No lo creo. Suelo ser muy crítico con Red Hat, pero una cosa que hacen bien en este aspecto es fomentar de manera saludable que sus desarrolladores inicien, colaboren y mantengan proyectos a contracorriente que viven en la comunidad en lugar de en el seno de Red Hat. La compañía Red Hat permite en la actualidad que sus ingenieros conserven su copyright y los autoriza bajo cualquier licencia que utilice el proyecto no convencional de que se trate, obligándolos a cumplir las condiciones de la licencia de copyleft (cuando el proyecto no convencional en cuestión se ampara en ella). Para los proyectos nacidos en el seno de Red Hat, y después de probar con el tipo de contratos de cesión para colaboradores de los que me estoy quejando , aprendieron del error y lo enmendaron (aunque, por desgracia, Red Hat no ha corregido el problema de forma universal ). En su mayor parte, Red Hat favorece que los colaboradores externos cedan sus derechos bajo la licencia de salida que Red Hat haya escogido para sus proyectos (algunos de los cuales también se amparan en el copyleft ). Las políticas más recientes de Red Hat tienen algunos defectos (cuyos detalles exceden la posibilidad de analizarlos en esta entrega), pero lo que utilizan ahora otras compañías, como Canonical Ltd., son los órdenes de magnitud de la cesión de derechos, y no tácticas de intimidación.
De modo que no permitamos que nos vuelva locos un nombre amable como «Harmony». Nuestra comunidad dispone de cierta infraestructura esencial, como el propio copyleft , que nos mantiene de hecho en armonía. Los contratos de colaboración no están hechos todos iguales y, por tanto, debemos oponernos a la idea de que el colaborador y los contratos de cesión se deben ajustar al mínimo común denominador que permita que una empresa lucrativa se apropie de ese territorio que Shuttleworth y otros defensores del modelo «Open Core» pretenden ocupar. También aconsejo con vehemencia a las organizaciones e individuos que ayudan a Canonical Ltd. a alcanzar su objetivo a que dejen de hacerlo de inmediato, sobre todo ahora que Shuttleworth ha anunciado sus planes «Open Core».
Actualización (18-10-2010): En algunos de sus comentarios, mucha gente ha expuesto con acierto que no he demostrado que Canonical Ltd. tenga planes de consolidar una estrategia «Open Core» con sus productos copyleft realizados mediante cesión de derechos de colaboradores. Esos comentarios están en lo cierto; pretendía que este artículo fuera un texto de opinión, no una demostración lógica. Además, estoy de acuerdo en que sin una prueba concluyente , el título de esta entrada es una exageración. (No lo he cambiado porque después de hacerlo habría parecido que antes era falso).
En todo caso, para ser más claro, lo único que la secuencia de sucesos expuestos más arriba demuestra es que Canonical Ltd. Pretende que el modelo «Open Core» sea una posibilidad para el futuro. Esa parte es una trivialidad: si no quisieran reservarse esa posibilidad, simplemente anunciarían la anulación de la promesa hecha con la cesión de mantener el software como Software Libre . La única razón para no anular la promesa como la FSF es que uno quiera reservarse la posibilidad de recalificarlo como software propietario.
Mientras tanto, aun cuando no puedo construir una demostración lógica, sigo creyendo que la única explicación posible para esta campaña de marketing de más de un año que he expuesto más arriba es que Canonical Ltd. está desplazando hacia el modelo «Open Core» esos proyectos de cuyos derechos son titulares exclusivos. He pedido a otras personas que me ofrezcan una explicación alternativa de por qué Canonical Ltd. lleva a cabo esta campaña: Estoy de acuerdo en que tal vez exista otra explicación lógica diferente de la que he expuesto. Si alguien puede darme una, me alegraría incluir aquí un enlace a ella.
Por último, si Canonical Ltd. presenta una declaración de que en sus contratos de cesión va a pasar a utilizar la cancelación de la promesa de la FSF, me alegrará reconocer que estaba equivocado. El resultado que busco es que los desarrolladores individuales reciban un trato justo de las empresas que controlan determinados conjuntos de códigos fuente; preferiría cien veces que sucediera eso antes que acertar con mis opiniones.
___________________________________
Notas
(1) En inglés, «núcleo abierto». Modelo de negocio para la comercialización de productos, habitualmente software , que consiste en distribuir de forma gratuita la versión básica de un programa y permitir el acceso a extensiones o funciones avanzadas mediante pago. (N. del T.)
(2) Originalmente atribuí a OMG Ubuntu la publicación de los comentarios de Shutleworth en forma de entrevista. El hecho de que cambiaran el formato me mantuvo en el error durante algún tiempo y pensé que le habían hecho una entrevista. Quiero dar las gracias a @gotunandan, que dejó claro este extremo.
(3) Curiosamente, la discusión no tenía nada que ver con ningún conjunto de códigos fuente de Canonical Ltd., dado lo escasas que, en todo caso, son sus aportaciones al conjunto de códigos fuente de GNOME (el 1 por ciento). El debate giró en torno a la situación del caso Clutter/Intel, que se resolvió después de aquello.
Fuente: http://ebb.org/bkuhn/blog/2010/10/17/shuttleworth_admits_it.html