Proyecto Harmony considerado dañino

Una cesión de copyright que carece de garantías reales

Antes que nada, casi la mitad del Proyecto Harmony se trata de acuerdos de asignación de copyright (©AA por sus siglas en inglés). La asignación de copyright cede completamente el trabajo a alguien más. Una vez que el ©AA está firmado, el trabajo deja de pertenecer al asignante. Es como si el trabajo en realidad hubiera sido hecho por el asignado. Admitido, hay algún valor en la asignación de copyright, particularmente cuando los desarrolladores quieren asegurarse que la GPL u otra forma de copyleft es debidamente protegida en su trabajo pero no tienen el tiempo de hacerlo ellos mismos. (Aunque los desarrolladores también pueden designar un agente de ejecución que lo haga en su nombre sin tener que asignar el copyright, así que esa necesidad es limitada.)

Uno debe tener una confianza inmensa en la organización asignada. Personalmente, yo sólo he asignado algunos de mis copyright a una sola organización en toda mi vida: la Free Software Foundation, porque la FSF es la única organización que he encontrado que está institucionalmente comprometida a hacer lo correcto con los copyrights de forma similar a mis creencias morales personales.

En primer lugar, como he escrito antes, los ©AA de la FSF hacen toda suerte de promesas al asignante. En segundo, la FSF está institucionalmente comprometida con la GPL y en hacer cumplir la GPL de forma de avanzar la militancia sin fines de lucro de la FSF por la libertad del software. Toda esta actividad está contenida en mis principios morales, por lo que no he tenido problema en firmar los ©AA de la FSF.

Aún así, he conocido muchos desarrolladores que se niegan a firmar los ©AA de la FSF. Mientras muchos de ellos aprueban la GPL, no necesariamente acuerdan con las posiciones morales de la FSF. En efecto, en muchos casos, estos desarrolladores se oponen completamente a asignar el copyright a nadie, sea la FSF o cualquier otro. Por ejemplo, Linus Torvalds, fundador de Linux, ha declarado repetidas veces que “nunca quis[o] hacer asignaciones de copyright, por varias razones: personalmente piens[a] que son sucias y erróneas, odiaría hacer todo el papeleo y piens[a] que actuaría como detractor del modelo de desarrollo”.

Obviamente, mi posición no es tan radical como la de Linus; pienso que los ©AA pueden ser apropiados en ciertas ocasiones. Pero también creo que los desarrolladores nunca deberían asignar su copyright a una compañía u organización cuya filosofía moral no cabe en la suya propia.

La FSF, por su parte, se expide sobre su posición moral en sus ©AA mismos. Como mencioné en otra parte, y como Groklaw recientemente cubrió en detalle, los ©AA de la FSF realizan varias promesas con validez legal a los desarrolladores que las firman. Mientras, los ©AA del Proyecto Harmony ponen unas pocas opciones que parecen vagamente aceptables (aunque tienen problemas propios que discuto más abajo), no las hacen obligatorias. Yo mismo he señalado en varias ocasiones a los que escribieron los borradores de Harmony que los términos que la FSF ha propuesto deberían ser obligatorios en cualquier ©AA de una compañía con fines de lucro, pero se han negado a incorporar estas garantías como un requisito de sus acuerdos. (Noten que tales garantías también deben incluirse en las opciones de los CLA; ver debajo para más detalles.)

Por último me gustaría señalar que la FSF no requieren ©AAs para todos los paquetes GNU. Esta confusión es tan común que me gustaría llamar la atención sobre ella, aunque sea un punto tangencial a este contexto. Los ©AA de la FSF son obligatorios, según mi conocimiento, si los paquetes GNU fueron (a) desarrollados por empleados de la FSF en sus primeras versiones o (b) los desarrolladores originales le pidieron a la FSF que realice una asignación de copyright cuando su proyecto se unió a GNU. En todos los demás casos, la asignación a la FSF es opcional. Algunos proyectos GNU, como GNOME, tienen sus propias posiciones sobre los ©AAs que difieren radicalmente de las de la FSF. Dudo seriamente que las compañías que adopten los acuerdos del Proyecto Harmony lleguen a ser tan flexibles en cuanto a la asignación de copyright como lo es la FSF, o que alguna de las opciones posibles que el Proyecto Harmony provea sean aceptables para la política actual de GNOME.

¿Regalar tus derechos para que las compañías sientan mariposas en la panza?

El Proyecto Harmony, sin embargo, proclama que la parte importante no son los ©AAs, sino los Acuerdos de Licencia del Contribuidor (CLA por sus siglas en inglés). Para considerar brevemente la historia de los CLAs de Software Libre, hay que notar que el CLA de Apache fue probablemente el primer CLA usado en la comunidad del Software Libre. La Apache Software Foundation siempre ha estado fuertemente influenciada por IBM y otras compañías, y tales compañías generalmente han sentido “mariposas en la panza” al lograr que cada contribuidor asienta a firmar un documento legal complejo que afirma varias garantías respecto al código y da ciertos poderes a la compañía.

El punto principal de un CLA (y hasta cierto punto válido) es asegurar que los desarrolladores han verificado su derecho a contribuir código bajo la licencia de copyright del proyecto. Tanto el CLA de Apache como los CLA del Proyecto Harmony llegan a extremos de longitud y verborragia para requerir que los desarrolladores acuerden que saben que la contribución es suya. De hecho, si un desarrollador firma uno de estos CLAs, realiza un contrato formal con la entidad (usualmente una compañía con fines de lucro) en el que reconoce que la contribución se licencia bajo la licencia del proyecto. ¡Y entonces el desarrollador asume toda responsabilidad si ese hecho es incorrecto o se pone en disputa!

Por supuesto, mover toda la responsabilidad sobre los orígenes del código produce muchas “mariposas en la panza” a los abogados de la compañía. Esos abogados saben que ahora pueden fácilmente demandar a un desarrollador individual por incumplimiento de contrato si el desarrollador se equivocó en el código. Si la compañía distribuye el código de un desarrollador y termina recibiendo una demanda por infracción por la que paga millones de dólares, pueden fácilmente darse vuelta y demandar al desarrollador.¹ La compañía argumentará en la corte que el desarrollador rompió el contrato. Si este desenlace posible no te preocupa inmediatamente en tanto desarrollador individual cuando firmás un CLA del Proyecto Harmony por tu contribución libre, debería.

La “Elección de Ley” y los Arreglos Contractuales embarran los reclamos de copyright

El CLA de Apache no posee una cláusula de elección de ley, lo que es preferible en mi opinión. La mayoría de los abogados aman una cláusula de “elección de ley” (“choice of law” en inglés) por varias razones. La más grande es que significa que las reglas que se aplican sobre el acuerdo son las más familiares a los abogados y la jurisdicción para las disputas será la jurisdicción local de la compañía, no la del desarrollador. Adicionalmente, los abogados a menudo eligen jurisdicciones particulares que son muy favorables a su cliente pero no lo son para los otros firmantes.

Desafortunadamente, todos los borradores del Proyecto Harmony incluyen una cláusula de “elección de ley”.² Espero que los que escriben los borradores argumentarán en respuesta que la jurisdicción es una variable de configuración. No obstante, el problema es que la compañía es la que decide el valor de esa variable, que casi siempre será la que no prefiera el desarrollador individual. Probablemente el término no sea negociable en ese punto, aunque haya podido configurarse en la plantilla.

Y no sólo eso, imaginá un escenario mucho más probable para ese CLA: la compañía falla en usar la licencia saliente que prometieron. Por ejemplo, supongan que prometieron a los desarrolladores que sería AGPL para siempre (¡aunque ninguna opción como esta existe en el Proyecto Harmony, vean más abajo!), pero entonces la compañía lanza versiones propietarias. Los desarrolladores que firmaron el CLA todavía detentan copyright, por lo que pueden ejercer sus derechos bajo la ley de copyright que, por sí misma, puede lograr que los desarrolladores hagan cumplir la licencia bajo la ley en cualquier jurisdicción que les parezca (asumiendo que la infracción sucede en esa, por supuesto).

Sin embargo, al firmar un CLA con la clásula de “elección de ley”, los desarrolladores acordaron mantenerse bajo la jurisdicción establecida en el CLA. El CLA convierte lo que de otra forma hubiera sido una demanda de infracción de copyright mundana operando solamente bajo la reglamentación de copyright local al desarrollador en una disputa contractual entre los desarrolladores y la compañía bajo las leyes de la jurisdicción elegida. Obviamente ese acuerdo incluiría la AGPL y/o GPL por referencia, pero el reclamo por infracción de copyright hecho por violación de la GPL está ahora embarrado por el contrato CLA que los desarrolladores firmaron, y donde cedieron algunos derechos y permisos a la compañía que van más allá de la GPL.

Aún peor, si el desarrollador realiza la demanda en su propia jurisdicción, esa jurisdicción se ve forzada a interpretar las leyes de otro lugar. Esto lleva a resultados altamente variables y confusos.

Problemas para hacer cumplir el copyright individualmente contra terceras partes

Además, aún cuando los desarrolladores individuales retienen sus copyrights, los CLAs del Proyecto Harmony garantizan muchos derechos y permisos transferibles al receptor del CLA (otra vez, usualmente a una compañía). Aún si las razones para requerirlos fuesen nobles, introducen un manojo de permisos extra que pueden ser pasados a otras entidades.

De repente, lo que una vez fuera una simple demanda para hacer cumplir el copyright hecha por un desarrollador que descubre una violación del copyleft se convierte en una pregunta: “¿Recibió de alguna manera esa entidad violatoria permisos especiales de esta otra entidad colectora del CLA?” Los violadores van a moverse rápidamente a este tipo de defensa. Aunque la defensa pueda no tener mérito (por ejemplo, el receptor del CLA ni siquiera conoce al violador), introduce confusión. La mayoría de los procedimientos legales que involucran software ya son suficientemente confusos para las cortes debido a la compleja tecnología involucrada. Agregar algo como esto sólo causará problemas y demoras, agregando más peso a nuestros mínimamente financiados esfuerzos por hacer cumplir el copyleft de la comunidad.

Entrante=Saliente es todo lo que necesitás

Mientras tanto, la pregunta sobre el CLA es esta única consideración fundamental: ¿Necesitamos esto? La respuesta del Proyecto Harmony es clara: sus defensores claman que existe una confusión masiva sobre los CLAs y ninguna estandarización, por lo que el Proyecto Harmony debe proveer un set estándar de acuerdos que encarnen todas las opciones usadas típicamente.

Aun más, el Proyecto Harmony ha rechazado a propósito ofrecer la opción más simple y popular de todas, que mi colega Richard Fontana (un abogado de Red Hat que también se opone al Proyecto Harmony) ha llamado el año pasado “entrante=saliente”. Específicamente, el acuerdo por defecto en la abrumadora mayoría de los proyectos FLOSS es simplemente esta: cada contribuidor acuerda licenciar cada contribución bajo la licencia de copyright específica del proyecto (o una licencia compatible).

No importa de qué lado mires al Proyecto Harmony, los otros problemas contractuales descritos arriba vuelven imposible un verdadero entrante=saliente porque el receptor del CLA nunca está legalmente obligado por la licencia del proyecto. Mientras tanto, y aún bajo su mejor configuración, el Proyecto Harmony no puede aproximarse adecuadamente a entrante=saliente. Específicamente, el Proyecto Harmony intenta limitar el licenciamiento de saliente en su sección 2.3 (llamada “Licencia saliente”). Sin embargo, todas las versiones copyleft de esta plantilla incluyen una cláusula que dice: “Nosotros [los receptores del CLA] acordamos licenciar la Contribución […] bajo los términos de las […] licencias que Nosotros estemos utilizando a la Fecha de Envío del Material”. Pero no hay forma de que el contribuyente verifique con seguridad cuáles licencias usa en privado la entidad que recibe el CLA. Si esa entidad ya tiene un modelo de negocio de relicenciamiento propietario a la Fecha de Envío, entonces el contribuyente concede su permiso para tal relicenciamiento en esa contribución nueva, aún si el resto de la sección 2.3 le promete copyleft. Esto no es hipotético: ha habido muchos casos donde no está claro si la compañía estaba o no estaba involucrada en relicenciamiento propietario, para más tarde descubrir que lo habían estado haciendo en privado durante años. Tal como está escrita, por lo tanto, cualquier configuración de la sección 2.3 del Proyecto Harmony es inútil para prevenir la apropiación propietaria.

Aunque ese bug sea arreglado, lo más cercano que el Proyecto Harmony va a estar de entrante=saliente es restringiendo sus CLA a “la lista de la FSF de licencias copyleft recomendadas”. Sin embargo, esta categoría no hace ninguna distinción entre la AGPL y la GPL, y en última instancia le permite a la FSF el poder de relicenciar (ya que la FSF puede cambiar su lista de copyleft recomendadas a voluntad). Si los contribuyentes son serios sobre la AGPL, entonces el Proyecto Harmony no puede asegurar que sus cambios permanezcan bajo esta licencia. Aún más, los contribuyentes deben confiar en la FSF a perpetuidad, aún más de lo que actualmente necesitan en las opciones “… o subsiguientes” de las licencias de la FSF en existencia. Estoy de acuerdo en confiar en la FSF en la mayoría de los casos. Sin embargo, ya que prefiero sólo AGPLv3 o subsiguientes para mi código, el Proyecto Harmony es completamente incapaz de acomodarse a mis preferencias y aproximarse a un entrante=saliente que sea AGPL (aún si ignoro los numerosos problemas ya discutidos).

Mientras tanto, la normal, mundana y extendida práctica entrante=saliente es simple, efectiva y no mezcla sus complicadas disputas contractuales y estructuras de control con la gobernanza del proyecto. En esencia, para la mayoría de los proyectos FLOSS, la licencia de copyright del proyecto sirve como su Constitución y no le mezcla ninguna otra complicación. El Proyecto Harmony busca darle maripositas a los abogados a expensas de tirarles el fardo legal y molesto a los desarrolladores.

Los Hackers de Linux han fijado ingeniosamente entrante=saliente

Hace casi 10 años atrás, recuerdo haber asistido a un sesión del USENIX 2001 Linux BoF. En esa sesión, Ted T’so y yo tuvimos un acalorado debate; yo afirmé que el ©AA de la FSF aseguraba certeza legal sobre el código GNU, pero que Linux no poseía tal seguro. (Por cierto, incluso yo estaba confundido en esos días y pensaba que todos los paquetes de GNU requerían un ©AA de la FSF.) Ted explicó, en la manera clara y brillante habitual, que tales métodos duros no eran necesarios para darle certeza legal a la GPL y que la comunidad de Linux quería encontrar una alternativa.

Me fui sacudiendo la cabeza escépticamente. Recuerdo haber pensado: “Ted no entiende”. Pero estaba equivocado; él sí entendía. De hecho, muchos de los desarrolladores clave de Linux lo hacían. Tres años después de esa conversación pública con Ted, el Certificado de Origen del Desarrollador (DCO por sus siglas en inglés) se convirtió en la forma oficial de manejar el “problema de los CLA” en Linux y sigue siendo la política oficial al día de hoy. (Ver el item 12 en el archivo Documentation/SubmittingPatches de Linux.)

El DCO, en efecto, ¡es el único CLA que necesita cualquier proyecto FLOSS! Implementa entrante=saliente en una forma simple y directa, sin darle poderes especiales a ninguna compañía o entidad en particular. Los desarrolladores mantienen su propio copyright y unilateralmente atestiguan su derecho a contribuir y la licencia de su contribución. (Además pueden firmar un ©AA con alguna otra entidad, como la FSF, si quieren.) El DCO también provee una metodología simple (es decir, la etiqueta Signed-off-by:) para realizar ese atestiguamiento.

Debo admitir que me he burlado de la simplicidad (que consideraba naïve) del DCO en comparación al ©AA de la FSF. Desde entonces me he convencido que el DCO de Linux cumple claramente con su trabajo principal a la vez que se ajusta a la forma de trabajo preferida por muchos desarrolladores. Los ©AA tienen su lugar, particularmente cuando los desarrolladores encuentran una organización confiable que se alinea con su código moral personal y se encargarán de defender el copyleft por ellos. No obstante, para los CLAs, el DCO de Linux cumple con este importante trabajo y deja de lado el costado pro-corporativo inútil.

Francamente, si tengo que elegir entre hacer las cosas fáciles para los desarrolladores o hacerlas fáciles para los abogados corporativos, voy a elegir lo primero en todos los casos: los desarrolladores escriben el código; mientras que la mayor parte del tiempo, los departamentos legales de una compañía sólo se meten en el medio. La comunidad de FLOSS necesita cubrirse el culo lo suficiente como para zafar; el DCO muestra lo que es realmente necesario, en oposición a lo que los abogados corporativos desean que hagan sus desarrolladores.

¿Qué pasa con el relicenciamiento?

El DCO de Linux no permite que una sola entidad relicencie el código; esta es la razón por la que el cambio a GPLv3 en Linux será una ardua tarea de procesos públicos por conseguir el permiso para el cambio. Sin embargo, hay que notar que la cultura linuxera cree que la GPLv2 es el fundamento moral y el principio de su comunidad. No es un principio con el que concuerdo; la mayoría de mis lectores saben que mi licencia preferida es la AGPLv3 o superior. Pero este es el punto: entrante=saliente es la forma en que una comunidad FLOSS implementa su moralidad; el Proyecto Harmony busca remover las decisiones comunitarias sobre el licenciamiento de casi todos los proyectos.

Estoy a favor de permitir el relicenciamiento “o superior”; la GPL, la LGPL y la AGPL han dejado la opción a la comunidad ya que la GPLv1 fue publicada a finales de los ’80. Los proyectos se declaran “GPLv2 o superior” o “LGPL o superior”, o incluso “GPLv1 o superior o Artística” (como Perl 5) para identificar su cultura y permisos de relicenciamiento. Aunque a veces sería bueno tener una autoridad en relicenciamiento, el precio es muy caro: el abandono de una claridad comunitaria con respecto a los términos en que se define su cultura de desarrollo.

¿Una parcialidad anti copyleft fuerte?

Lo que es aun peor, es que el Proyecto Harmony se mantiene parcial contra algunas de las más afinadas versiones de la cultura copyleft. Por ejemplo, Allison Randal, quien está muy involucrada en el Proyecto Harmony, argumentó en el episodio 204 de Linux Outlaws que “la mayoría de los desarrolladores que contribuyen bajo una licencia copyleft, estarían contentos de hacerlo bajo cualquier otra, sea AGPL, GPL o LGPL”. Sin embargo existen varias razones bien definidas de por qué los desarrolladores eligirían la GPL antes que la LGPL. Por eso, entregarle a una compañía con fines de lucro (o una sin fines de lucro que no necesariamente comparta los valores de los desarrolladores) el poder unilateral de tomar decisiones de relicenciamiento y convertir un proyecto bajo GPL en LGPL o cualquier otra licencia de copyleft débil es ridículo.

En su lanzamiento 1.0, el Proyecto Harmony intentó agregar una opción de “sólo copyleft fuerte”. Por supuesto que no funciona, por las razones discutidas más arriba. Pero aun así, esta solución es sólo una de las muchas y no es requerida por defecto cuando un proyecto ya es copyleft.

Por último, es importante notar que las GPLv3, AGPLv3 y LGPLv3 ya ofrecen una “opción de apoderado (proxy)”; los proyectos pueden nombrar a alguien para decidir cambiar a “o superior” más tarde. Por eso, para aquellos proyectos que estén usando cualquiera del grupo “sólo LGPLv3”, “sólo AGPLv3”, “sólo GPLv3”, “GPLv2 o superior”, “GPLv1 o superior” o “LGPLv2.1 o superior”, sus desarrolladores ya poseen mecanismos para moverse a versiones superiores de la licencia con facilidad al especificar un apoderado. No hay necesidad de un CLA para cumplir tal tarea en la familia de licencias GPL, a menos que el objetivo sea erosionar los copylefts fuertes para convertirlos en copylefts débiles.

Esto no es Creative Commons, pero si lo fuera, ¿vale la pena emularlo?

Los defensores del Proyecto Harmony aman compararlo con Creative Commons, pero la comparación no es particularmente apta. Aún más, no estoy convencido de la que la comunidad FLOSS deba emular al grupo de licencias de CC del todo, ya que algunos aspectos de la estructura de CC son problemáticos al migrarlos al licenciamiento FLOSS.

En primer lugar, Larry Lessig (quien es ampliamente considerado como un visionario) inició el licenciamiento CC para capturar un movimiento por la Cultura Libre que se estaba moldeando a semejanza del movimiento del Software Libre (la cual pasó una década estudiando). Sin embargo, Lessig realizó varios compromisos morales en su intento de construir un puente a la mentalidad “algunos derechos reservados”. Así, muchas de las licencias CC -notablemente las que incluyen las cláusulas NoComercial (NC) o SinDerivadas (ND)- son consideradas demasiado restrictivas y son por lo tanto rechazadas tanto por activistas de la Cultura Libre como por militantes del Software Libre.

Después de una década, esos militantes empezaron lentamente a convencer a los titulares de copyright de evitar las opciones NC y ND de CC, pero la promulgación continua de estas opciones por parte de CC deslegitiman esos intentos. Así, CC y el Proyecto Harmony cometen el mismo error: actúan amoralmente en su intento de construir una estructura de licencias/acuerdos que trata de aunar entendimiento entre una comunidad FaiF (“libre como en libertad”, en inglés “Free as in Freedom”) y aquellos que recién están comenzando a conocerla. Elegí la palabra amoral, como usualmente hago, para denotar una situación donde existen importantes principios morales, pero sus actores principales buscan remover la moralidad de consideración con la excusa de dejar el poder de decisión “a la magia del mercado”. El Proyecto Harmony repite el error de las licencias CC que la comunidad de la Cultura Libre ha pasado una década (y contando) de limpiar.

Conclusiones

Por favor noten que no soy un abogado y que esto no es un aviso legal. Sólo soy un desarrollador tanto individual como comunitario enfocado en políticas de software libre que tiene serias preocupaciones por la forma en que operan los acuerdos del Proyecto Harmony. No puedo proveer un análisis legal refinado, porque francamente soy un amateur cuando se trata de leyes, pero soy un experto en políticas de libertad del software. En esa vena -sin tener en cuenta el apoyo de los abogados corporativos- mi opinión es que el Proyecto Harmony debe abandonarse por completo.

De hecho, la distinción entre experticia política y legal muestra la raíz del problema del Proyecto Harmony. Es un sistema de documentos diseñados por un comité compuesto principalmente por abogados corporativos, aun cuando se muestra como un consenso de desarrolladores FLOSS. En efecto, el Proyecto Harmony fue iniciado por Amanda Brock, una abogada corporativa con fines de lucro de Canonical, Ltd, que aun trabaja en los borradores. Más tarde, Canonical, Ltd. contrató a Mark Radcliffe (un abogado que ha defendido violadores de la GPL) para escribir el borrador de las versiones alpha del documento, y aun continúa haciéndolo. Aún más, el proceso primario de escritura de esos borradores se hizo en secreto en reuniones cerradas dominadas por abogados corporativos hasta que los documentos estuvieron casi completos; el proceso no se hizo público a la comunidad hasta abril del 2011. La versión 1.0 de los documentos poco difiere de los borradores que se lanzaron en abril, y por lo tanto se mantienen como documentos que fueron principalmente redactados en secreto por abogados corporativos que sólo tienen una lejana familiaridad con la cultura del software libre.

He preguntado muchas veces a los defensores del Proyecto Harmony quién está a cargo del mismo hoy, y nadie puede darme una respuesta directa. Uno se pregunta quién toma las decisiones finales y cuál es el proceso que existe para incluir o excluir texto en los borradores. El proceso que una vez fue secreto ahora parece ser caótico porque fue abierto mucho más tarde de lo necesario para resolver sus problemas fundamentales.

Sólo unos pocos desarrolladores están involucrados en el proyecto. Pero el Proyecto Harmony no es algo que los desarrolladores hayan pedido; fue iniciado por compañías que quisieran convencerlos de adoptar pasivamente estos extralimitados CLAs y ©AAs. Para mí, el proceso completo del Proyecto Harmony se siente como una guerra de desgaste para convencer a los desarrolladores de aceptar algo que no necesariamente quieren con un mínimo de disenso. En definitiva, la necesidad del Proyecto Harmony no se ha articulado para los desarrolladores.

Por último, pregunto, ¿qué es lo que está realmente roto? La industria ha estado adoptando GNU y Linux durante años de manera continua. GNU, por su parte, tiene las asignaciones de la FSF para muchos de sus proyectos tempranos, pero los últimos proyectos (GNOME en particular) han sido absolutamente contrarios tanto al uso de ©AAs como de CLAs, o se han mostrado indiferentes y han usado entrante=saliente. Linux, por su lado, usa el DCO, que realiza el trabajo de manejar las partes más urgentes e importantes de un CLA sin ponerse en el camino de los desarrolladores y sin forzarles riesgos legales extra y entregarle las decisiones de licenciamiento (incluyendo las debilitantes del copyleft) a una única entidad (usualmente con fines de lucro).

En definitiva, el Proyecto Harmony es una solución mal diseñada buscando un problema.

Véase también (en inglés)

• El problema con Harmony, Parte I de Richard Fontana

• Los acuerdos Harmony 1.0 de Dave Neary

• Algunos pensamientos sobre la asignación de copyright de Michael Meek

• La asignación de copyright y otras barreras para ingresar de Dave Neary

• El relicenciamiento propietario es el nuevo shareware por mí mismo

• Cuando una compañía te pide tu copyright de RMS

• La FSF y el Proyecto Harmony de Brett Smith

• Hay varios hilos diferentes que pueden encontrarse en identi.ca donde se discuten los acuerdos del Proyecto Harmony. El hashtag “#Harmony” se usa a menudo. El hashtag “#CLA” también puede ser de interés.

• El problema de traer armonía a la asignación de copyright de Jos Poortvliet

• Balanceando transparencia y privacidad de Simon Phipp

• Política de asignación de copyright de GNOME

• Los lineamientos de la Fundación GNOME sobre la asignación de copyright

• El Proyecto Harmony busca mejorar los acuerdos de contribución de Amanda Brock

• Los archivos de la lista de correo del Proyecto Harmony

• Los borradores de los Acuerdos Harmony

• Políticas de contribución de proyectos de código abierto diapositivas de la charla de Richard Fontana.