Como todos los años, los temas legales fueron un tema candente en el mundo del código abierto en 2017. Mientras estamos en el primer trimestre del año, todavía vale la pena mirar atrás a las principales noticias legales en código abierto el año pasado.
1. GitHub revisa ToS
En febrero de 2017, GitHub anunció que estaba revisando sus términos de servicio e invitó a los comentarios sobre los cambios, varios de los cuales se referían a los derechos sobre el contenido subido por el usuario. Los términos anteriores de GitHub incluían un acuerdo del usuario para permitir que otros “visualizaran y bifurcaran” repositorios públicos, así como una cláusula de indemnización que protegía a GitHub contra reclamaciones de terceros. Los nuevos términos agregaron una licencia del usuario a GitHub para permitirle almacenar y brindar contenido, una licencia de contribuyente “entrante = saliente” predeterminado y un acuerdo del usuario para cumplir con las licencias de terceros que cubren el contenido subido. Mientras se mantiene el lenguaje “ver y clonar”, los nuevos términos establecen que se pueden otorgar más derechos adoptando una licencia de fuente abierta. Los términos también agregan una exención de derechos morales con una licencia de respaldo de dos niveles, la segunda licencia que otorga permiso a GitHub para usar contenido sin atribución y para hacer adaptaciones razonables “según sea necesario para generar el sitio web y proporcionar el servicio”.
En marzo, después de que los nuevos términos entraron en vigencia, varios desarrolladores, especialmente Thorsten Glaser y Joey Hess, plantearon preocupaciones de que eliminarían sus repositorios de GitHub. Como Glaser y Hess leyeron los nuevos términos, parecían exigir a los usuarios que otorguen derechos a GitHub y a otros usuarios que fueran más amplios de lo que permitirían las licencias de terceros, particularmente licencias copyleft como la GPL y licencias que requieren atribución. Además, la licencia de GitHub podría interpretarse como una licencia más favorable en el contenido de los usuarios que la que los usuarios normales recibirían bajo la licencia nominal. Donald Robertson de la Free Software Foundation (FSF) escribió que, aunque los términos de GitHub eran confusos, no estaban en conflicto con el copyleft: “Debido a que es muy poco probable que GitHub tenga la intención de destruir su modelo de negocio y base de usuarios, no leemos el ambigüedad en los términos de otorgar o exigir permisos excesivamente amplios fuera de los que ya otorga la GPL “.
GitHub finalmente agregó una nota que aborda el problema; se puede ver en la versión actual de los términos: “Si carga Contenido que ya viene con una licencia que otorga a GitHub los permisos que necesitamos para ejecutar nuestro Servicio, no se requiere licencia adicional”.
2. Declaración de cumplimiento del kernel
La Sección 4 de GPLv2 habla de la terminación automática de derechos para aquellos que violan los términos de la licencia. En 2006, la FSF había llegado a ver esta disposición como indebidamente dura en el caso de violaciones inadvertidas. GPLv3 modifica el enfoque de GPLv2 a la terminación al proporcionar una oportunidad de curación de 30 días para infractores por primera vez, así como un período de reposo de 60 días. Muchos proyectos de GPL, como el kernel de Linux, continúan bajo licencia bajo GPLv2.
Como escribí el año pasado, en 2016 se condenó públicamente las tácticas de cumplimiento de GPL del ex colaborador de Netfilter, Patrick McHardy. En una reacción posterior a la conducta de McHardy, la Junta Asesora Técnica de la Fundación Linux (TAB), elegida por los desarrolladores individuales del núcleo, elaboró una Declaración de cumplimiento de kernel de Linux, que fue anunciada por Greg Kroah-Hartman en la lista de correo del kernel de Linux (LKML) 16 de octubre de 2017. La declaración, que ahora forma parte del directorio de Documentación del kernel, incorpora el lenguaje de curación y reposo de GPLv3 textualmente como un “compromiso con los usuarios del kernel de Linux en nombre de nosotros y cualquier sucesor de nuestros derechos de autor”. El compromiso, descrito como una concesión de permiso adicional bajo GPLv2, se aplica a las afirmaciones no defensivas de los derechos de GPLv2. La declaración kernel en efecto adopta una recomendación en los Principios de Aplicación de la GPL orientada a la comunidad. Hasta la fecha, la declaración ha sido firmada por más de 100 desarrolladores de kernel. Kroah-Hartman publicó una pregunta frecuente sobre la declaración y una explicación detallada escrita por varios miembros de TAB.
3. Red Hat, Facebook, Google e IBM anuncian el compromiso de cura de GPLv2 / LGPLv2.x
Un mes después del anuncio de la declaración de cumplimiento del kernel en LKML, una coalición de compañías lideradas por Red Hat e incluyendo Facebook, Google e IBM anunciaron su propio compromiso de extender las oportunidades de curación y reposo de GPLv3 a todo código cubierto por sus derechos de autor y licencia bajo GPLv2, LGPLv2 y LGPLv2.1. (La disposición de terminación en LGPLv2.x es esencialmente idéntica a la de GPLv2). Al igual que con la declaración kernel, el compromiso no se aplica a procedimientos defensivos o reclamos presentados en respuesta a algún procedimiento previo o reclamo (por ejemplo, una contrademanda de violación de GPL en una demanda por infracción de patente, como ocurrió en Twin Peaks Software v. Red Hat).
4. EPL 2.0 lanzado
La licencia pública Eclipse versión 1.0, una licencia copyleft débil que desciende de la licencia pública común e indirectamente la licencia pública de IBM, ha sido la principal licencia de los proyectos de la Fundación Eclipse. También ve un uso significativo fuera de Eclipse; por ejemplo, EPL es la licencia de la implementación del lenguaje Clojure y la licencia preferida de código abierto de la comunidad Clojure, y es la licencia principal de OpenDaylight.
Luego de un proceso silencioso de revisión comunitaria de dos años, en agosto de 2017, la Fundación Eclipse anunció que una nueva versión 2 del EPL había sido aprobada por la junta de la Fundación Eclipse y por la OSI. La Eclipse Foundation pretende que EPL 2.0 sea la licencia predeterminada para los proyectos comunitarios de Eclipse.
EPL 2.0 es una revisión de licencia bastante conservadora. Tal vez el cambio más notable se refiere a la compatibilidad GPL. EPL 1.0 es considerado incompatible con GPL tanto por la FSF como por la Eclipse Foundation. La FSF ha sugerido que esto se debe al menos a los requisitos contradictorios de copyleft en las dos licencias, y (más dudosamente) a la cláusula de elección de ley en EPL 1.0, que se ha eliminado en EPL 2.0. Como una licencia copyleft débil, EPL normalmente requiere al menos algún subconjunto de trabajos derivados para ser licenciado bajo EPL si se distribuye en forma de código fuente. FSF y Eclipse publicaron opiniones sobre el uso de GPL para los complementos Eclipse IDE hace varios años. Además del problema de la compatibilidad de licencias, la Fundación Eclipse generalmente prohíbe que los proyectos distribuyan código de terceros bajo GPL y LGPL.
Mientras que EPL 2.0 permanece incompatible con GPL por defecto, habilita al “Colaborador” inicial para autorizar la licencia del código fuente cubierto por EPL bajo una “Licencia secundaria” -GPLv2, GPLv3, o una versión posterior de la GPL, que puede incluir identificadas Excepciones GPL o permisos adicionales, como la Excepción de Classpath: si el código cubierto por EPL se combina con el código licenciado por GPL contenido en un archivo separado. Algunos proyectos de Eclipse ya se han relicenciado a EPL 2.0 y están haciendo uso de esta característica de “Licencia secundaria”, que incluye OMR y OpenJ9. Como observa el FSF, la invocación de la característica de Licencia Secundaria es más o menos equivalente a la licencia dual del código bajo EPL / GPL.
5. Migración de Java EE a Eclipse
Java Community Process (JCP) facilita el desarrollo de las especificaciones de la tecnología Java (solicitudes de especificación de Java, también conocidas como JSR), incluidas las que definen la plataforma Java Enterprise Edition (Java EE). JCP se basa en una arquitectura legal compleja centrada en el Acuerdo de participación de especificación de Java (JSPA). Si bien el gobierno de JCP se comparte entre múltiples participantes organizativos e individuales, el JCP de ninguna manera es neutral para el proveedor. Oracle posee la marca registrada Java y tiene controles especiales sobre el JCP. Algunas reformas de JCP se adoptaron hace varios años, incluidas medidas para imponer licencias de fuente abierta y prácticas de desarrollo de proyectos de fuente abierta para implementaciones de referencia JSR (RI), pero los esfuerzos para modernizar JSPA se estancaron durante la tramitación del litigio de Oracle v. Google.
En agosto de 2017, Oracle anunció que exploraría el traslado de Java EE a una base de código abierto. Tras consultar con IBM y Red Hat, los otros dos principales contribuyentes a Java EE, Oracle anunció en septiembre que había seleccionado la Fundación Eclipse para albergar al sucesor de Java EE.
La migración a Eclipse ha estado en marcha desde entonces. La placa Eclipse aprobó un nuevo proyecto de Eclipse de alto nivel, EE4J (Eclipse Enterprise para Java), para servir como el proyecto general para el desarrollo de RI y kits de compatibilidad de tecnología (TCK) para la plataforma sucesora. El proyecto GlassFish, que consiste en el código fuente de los RI para la mayoría de los JSR de Java EE para los cuales Oracle ha servido como lead de especificación, ha estado principalmente bajo una licencia dual de CDDL y GPLv2 más la excepción de Classpath. Oracle está en el proceso de relicencia de este código para EPL 2.0 con GPLv2 más la excepción de Classpath como la Licencia secundaria (consulte el tema EPL 2.0). Además, se espera que Oracle relicence los TCK Java EE patentados para que puedan desarrollarse como proyectos de código abierto de Eclipse. Aún no se ha determinado el nombre de una marca de certificación propiedad de Eclipse para suceder a Java EE y el desarrollo de un nuevo proceso de especificación en lugar del definido en la JSPA.
6. React: Controversia de licencia
Las licencias de código abierto que abordan específicamente las licencias de patentes a menudo combinan la concesión de la licencia de patente con una cláusula de “defensa de patentes”, dando por terminada la licencia de patente ante ciertos actos de litigio presentados por el licenciatario, un enfoque tomado de acuerdos de estándares. El primer período de experimentación corporativa con licencias de fuente abierta se caracterizó por el entusiasmo por las cláusulas de defensa de patentes que eran amplias (en el sentido de que un rango relativamente amplio de conducta provocaría la terminación). La llegada de Apache License 2.0 y Eclipse Public License 1.0 en 2004 marcó el final de esa era; sus criterios de terminación de patente se limitan básicamente a demandas de patentes en las que el usuario acusa al propio software licenciado de infracción.
En mayo de 2013, Facebook lanzó la biblioteca React JavaScript bajo Apache License 2.0, pero la versión 0.12.0 (octubre de 2014) cambió a la licencia BSD de 3 cláusulas junto con una concesión de licencia de patente en un archivo PATENTS aparte. La idea de utilizar una licencia de fuente abierta permisiva estándar simple con una licencia de patente a medida en un archivo separado tiene un precedente en los proyectos mantenidos por Google y Microsoft. Sin embargo, las cláusulas de defensa de patentes en esos casos tienen un enfoque estrecho de Apache / EPL. El lenguaje React PATENTS dio por terminada la licencia de patente en casos en que el licenciado interpuso una acción de infracción de patente contra Facebook o contra cualquier parte “derivada” de cualquier producto de Facebook, incluso cuando el reclamo no estaba relacionado con React, así como cuando el licenciatario alegó que una patente de Facebook no era válida o no exigible. En respuesta a las críticas de la comunidad, Facebook revisó el lenguaje de la licencia de patente en abril de 2015, pero la versión revisada continuó incluyendo como litigio de patentes de criterios de terminación contra Facebook y litigios de patentes “derivados de” productos de Facebook.
Facebook vino a aplicar la licencia React a muchos de sus proyectos comunitarios. En abril de 2017, se abrió un problema en el rastreador de problemas de “Discusión legal” de la Apache Software Foundation (ASF) sobre si Apache Cassandra podría usar RocksDB, otro proyecto de Facebook que usa la licencia React, como una dependencia. Además de los otros varios proyectos de ASF que aparentemente ya estaban usando RocksDB, una gran cantidad de proyectos de ASF usaron React. En junio, Chris Mattmann, vicepresidente de asuntos legales de la ASF, dictaminó que la licencia de React estaba relegada a la categoría X prohibida, a pesar del hecho de que la ASF ha colocado licencias de fuente abierta desde hace mucho tiempo. con cláusulas de defensa de patente similarmente amplias (MPL 1.1, IBM-PL, CPL) en su Categoría B. En respuesta, Facebook relicensó RocksDB bajo GPLv2 y Apache License 2.0, y unos meses más tarde anunció que estaba relicenciando React y tres otros proyectos con licencia idéntica bajo la licencia MIT. Los cambios más recientes en la licencia de proyectos de Facebook desde el enfoque de React a las licencias convencionales de código abierto incluyen osquery (GPLv2 / Apache License 2.0) y React Native (MIT).
Gran parte de las críticas de la comunidad sobre la licencia de React estaban bastante mal informadas y a menudo parecían ser poco más que un ataque ad hominem contra Facebook. Uno de los pocos ejemplos de análisis sobrio y bien razonado del tema es el artículo de Heather Meeker sobre Opensource.com. Independientemente de los méritos reales que pueda tener la licencia React, la decisión de Facebook de utilizarla sin neutralizar la licencia y sin buscar la aprobación de OSI fueron errores tácticos, como señala Simon Phipps.
7. Relicencia de OpenSSL
La licencia que cubre la mayor parte de OpenSSL es una conjunción de dos licencias derivadas BSD de la década de 1990. El primero se asemeja mucho a una licencia temprana del servidor web Apache. El segundo es la licencia a medida del proyecto predecesor de OpenSSL, SSLeay. Ambas licencias contienen una cláusula de publicidad como la de la licencia BSD de 4 cláusulas. La última frase de la licencia SSLeay, una snipe gratuita en la GPL, respalda una interpretación, endosada por la FSF pero sin duda involuntaria, de que la licencia es copyleft. Si solo por las cláusulas publicitarias, la licencia OpenSSL se entiende desde hace tiempo como incompatible con GPL, como explicó Mark McLoughlin en un ensayo ahora clásico.
En 2015, un año después de la revelación de la vulnerabilidad Heartbleed y la subsiguiente formación de la Iniciativa Core Infrastructure de la Fundación Linux, Rich Salz dijo en una publicación de blog que OpenSSL planeaba relicenciar la Apache License 2.0. El equipo de OpenSSL dio seguimiento en marzo de 2017 con un comunicado de prensa anunciando la iniciativa de relicencia y creó un sitio web para recolectar acuerdos para el cambio de licencia de los varios cientos de contribuyentes anteriores del proyecto.
Un correo electrónico enviado a contribuyentes individuales identificados, solicitando permiso para relicencia, generó críticas, principalmente debido a su frase final: “Si no tenemos noticias suyas, asumiremos que no tiene objeción”. Algunos plantearon preocupaciones políticas y legales sobre lo que Theo de Raadt llamó un enfoque de “consentimiento de fabricación en volumen”. De Raadt se burló del esfuerzo publicando un intento bromista de relicenciar a GCC a la licencia de ISC.
Salz publicó una actualización sobre el esfuerzo de relicencia en junio. En ese momento, el 40% de los contribuyentes contactados había respondido, la gran mayoría a favor del cambio de licencia y menos de una docena de objeciones, lo que equivale a 86 confirmaciones, con la mitad de ellas sobreviviendo en la sucursal principal. Salz describió en detalle los pasos razonables que el proyecto había tomado para revisar esas objeciones, lo que resultó en una determinación de que al menos 10 compromisos requerían remoción y reescritura.
8. Open Source Security v. Perens
Open Source Security, Inc. (OSS) es el vehículo comercial a través del cual Brad Spengler mantiene el parche de grsecurity fuera de árbol para el kernel de Linux. En 2015, citando preocupaciones sobre el incumplimiento de GPL por parte de los usuarios y el uso indebido de la marca registrada de grsecurity, OSS comenzó a limitar el acceso al parche estable a los clientes que pagaban. En 2017, OSS dejó de publicar ramas públicas de grsecurity. El Acuerdo de acceso de parche estable de Grsecurity afirma que grsecurity está licenciado bajo GPLv2 y que el usuario tiene todos los “derechos y obligaciones” de GPLv2, pero establece una política de terminación de acceso a actualizaciones futuras si un usuario redistribuye parches o registros de cambios “fuera de las obligaciones explícitas la GPL a los clientes del Usuario “.
En junio de 2017, Bruce Perens publicó una publicación en el blog que sostenía que el acuerdo de grisedad violaba la GPL. OSS demandó a Perens en el Distrito Norte de California, con reclamos por difamación e intromisión con posibles ventajas. En diciembre, el tribunal otorgó la moción de Perens para destituir, denegó sin perjuicio la moción de Perens de huelga bajo el estatuto anti SLAPP de California, y denegó la moción de OSS para un juicio sumario parcial. En esencia, el tribunal dijo que las publicaciones del blog de Perens no eran difamatorias. OSS ha dicho que tiene la intención de apelar.
9. Artifex Software v. Hancom
Artifex Software licencia Ghostscript gratis bajo la GPL (más recientemente AGPL) y para ingresos bajo licencias propietarias. En diciembre de 2016, Artifex demandó a Hancom, un proveedor surcoreano de software de suite de oficina, en el Distrito Norte de California. Artifex alegó que Hancom había incorporado Ghostscript en su programa de procesamiento de textos Hangul y en el producto Hancom Office sin obtener una licencia propietaria ni cumplir con la GPL. La queja incluye reclamos por incumplimiento de contrato, así como infracción de derechos de autor. Además de los daños monetarios, Artifex solicitó medidas cautelares, incluida una orden que obliga a Hancom a distribuir el código fuente de Hangul y Hancom Office a los clientes de Hancom.
En abril de 2017, el tribunal denegó la moción de Hancom de destitución. Uno de los argumentos de Hancom fue que Artifex no alegó la existencia de un contrato porque no había una demostración de asentimiento mutuo. El tribunal no estuvo de acuerdo, afirmando que las alegaciones del uso de Ghostscript por parte de Hancom, la falta de obtención de una licencia de propiedad y la representación pública de que su uso de Ghostscript estaba licenciado bajo la GPL fueron suficientes para declarar la existencia de un contrato. Además, las alegaciones de Artifex con respecto a su esquema de doble licencia se consideraron suficientes para declarar daños y perjuicios por incumplimiento de contrato. La negación de la moción de desestimación fue ampliamente denunciada y sensacionalizada como un fallo que la GPL misma era “un contrato ejecutable”.
En septiembre, el tribunal denegó la moción de Hancom de juicio sumario sobre la reclamación por incumplimiento de contrato. Hancom argumentó primero que, como cuestión de derecho, Artifex no tenía derecho a recibir indemnización por daños y perjuicios, esencialmente porque el cumplimiento de GPL no exigía el pago a Artifex. El tribunal rechazó este argumento, ya que el valor de una licencia con regalías y una teoría de enriquecimiento injusto podrían servir como la medida de los daños de Artifex. En segundo lugar, Hancom argumentó en esencia que cualquier daño por incumplimiento del contrato no podría basarse en la continuación de actividad GPL no conforme después de que Hancom comenzó a enviar Ghostscript en violación de la GPL, porque en ese momento la licencia GPL de Hancom se terminó automáticamente. Al rechazar este argumento, el tribunal señaló que el lenguaje de GPLv3 sugería que las obligaciones de Gcom de Hancom persistían más allá de la terminación de sus derechos de GPL. Las partes llegaron a un acuerdo en diciembre.
Un agradecimiento especial a Chris Gillespie por su investigación y análisis del caso Artifex.
10. Conflicto de marca de SFLC / Conservancy
En 2006, Software Freedom Law Center formó una organización independiente sin fines de lucro, que denominó Software Freedom Conservancy. Para julio de 2011, las dos organizaciones ya no tenían miembros de la junta, funcionarios o empleados en común, y SFLC dejó de proporcionar servicios legales a TNC. SFLC obtuvo un registro de USPTO para la marca de servicio SOFTWARE FREEDOM LAW CENTER a principios de 2011. En noviembre de 2011, TNC solicitó la inscripción de la marca SOFTWARE FREEDOM CONSERVANCY; el registro se emitió en septiembre de 2012. SFLC continúa siendo administrado por su fundador Eben Moglen, mientras que TNC es administrado por los ex empleados de SFLC Karen Sandler y Bradley Kuhn. Se sabe que las dos organizaciones tienen posiciones opuestas en una cantidad de asuntos legales y de política importantes (ver, por ejemplo, mi discusión sobre el tema ZFS-Linux el año pasado).
En septiembre de 2017, SFLC presentó una petición ante el Tribunal de Apelaciones y Prueba de Marcas Registradas para cancelar el registro de marca registrada de TNC bajo la Sección 14 de la Ley de Marcas Registradas de Lanham de 1946, 15 U.S.C. § 1064, alegando que la marca de Conservancy es confusamente similar a SFLC. En noviembre, TNC presentó su respuesta enumerando sus defensas afirmativas, y en diciembre, Conservancy presentó una moción de juicio sumario sobre esas defensas. El TTAB de hecho negó la moción de juicio sumario sobre la base de que las defensas afirmativas en la respuesta de Conservancy no fueron suficientemente alegadas.
Moglen propuso públicamente una liberación mutua de todos los reclamos “a cambio de un acuerdo férreo para el no menosprecio mutuo”, que incluye “una licencia de marca perpetua y libre de regalías para que Conservancy conserve y use su nombre actual”. TNC respondió en una publicación de blog que no podía “aceptar ninguna oferta de acuerdo que incluyera una licencia de marca comercial que no necesitamos. Además, cualquier licencia de marca comercial necesariamente otorga a SFLC un control perpetuo sobre cómo perseguimos nuestra misión de beneficencia”.
SFLC solicitó autorización para enmendar su petición para agregar un segundo motivo para la cancelación, que el registro de la marca registrada de TNC fue obtenido por fraude. La respuesta de Conservancy argumenta que la enmienda propuesta no establece un reclamo por fraude. Mientras tanto, TNC ha presentado solicitudes de marcas comerciales para “THE SOFTWARE CONSERVANCY”.
