GPL3 y DRM
Hace unos minutos han dejado un comentario que además apunta a un artículo del mismo autor, GPLv3 no evita el uso de DRM. Hay varias interpretaciones erróneas que contestaré brevemente.
La GPL3 establece mecanismos de defensa contra el DRM de dos maneras diferentes: establecer una barrera legal para proteger a los desarrolladores y una redefinición de lo que se considera código fuente para evitar el uso de sistemas de cifrado para impedir la ejecución (trusted computing) de versiones modificadas del software GPL.
Protección
No covered work constitutes part of an effective technological protection measure: that is to say, distribution of a covered work as part of a system to generate or access certain data constitutes general permission at least for development, distribution and use, under this License, of other software capable of accessing the same data.
Esa cláusula de la sección 3 es fundamental contra el DRM desde el punto de vista legal (explicada en el Rationale Document).
Significa sencillamente que cualquier software con licencia GPL3 no es considerado “medida de protección”, por lo tanto no son aplicables las clásulas/penas por “circunvención de métodos de protección” según lo especifican la norteamericana DMCA y la European Union Copyright Directive (EUCD) (lo expliqué antes en Sorprendido con la GPL3.
Objetivo: a) que la ingeniería inversa no sea legalmente penalizable en casos de software con licencia GPL3, b) desincentivar sino impedir el uso de software libre en sistemas con DRM.
Redefinición del código fuente
Aunque no se dice explícitamente, la definición del “código fuente” de la sección 2 también establece condiciones para impedir que se usen sistemas DRM basados en TPM (trusted computing).
Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work’s output.
Esta cláusula hace que no se pueda usar software GPL3 con dispositivos DRM, o que esos dispositivos de claves impidan que el usuario tenga libertad a la hora de ejecutar y obtener los resultados esperados del programa usando la versión original o una modificada.
Algo similar es lo que está ocurriendo actualmente con TiVO. Usan mecanismos DRM/TPM (con software GPL2) que impiden la ejecución de cualquier núcleo Linux que no sea el firmado por la empresa. Obviamente el software firmado por ellos incluyen módulos no liberados ni publicados.
Con la GPL3 TiVO no podría usar software con esta licencia, o debería proveer todas las claves para que un usuario pueda ejecutar y obtener los mismos resultados –módulo bugs– con su propia versión del sistema.
Objetivo fundamental: a) evitar el recorte de las libertades por mecanismos de hardware, b) desincentivar sino impedir el uso de software libre en sistemas con DRM.
Por supuesto, estoy de acuerdo en que el DRM no funcionará. Pero eso no significa que sí se pueda usar legalmente el software libre con propósitos contrarios a su misma filosofía. Tampoco impide que se creen leyes y directivas como la DMCA y EUCD. Ambos casos son tratados por la GPL3 de forma bastante clara.
En realidad eso no responde las inquietudes planteadas en mi post. Nuevamente no funcionó el trackback, mi respuesta en http://www.hardings.cl/blog/2006/01/30/objetivos-de-gplv3-con-respecto-a-drm/
Comment by Jens Hardings Perl — Monday 30/1/2006 @ 17:23
Es que no te entiendo que quieres decir.
“Me imagino que un sistema que entrega llaves para decriptar contenido”ç
¿Qué significa eso? ¿qué tiene que ver con la obligación de entregar al usuario las claves que permitan hacer _funcionar_ a cualquier programa? Si las claves no se entregan al usuario y se le entrega un dispositivo con software GPL3 estaría violando la licencia. La palabra clave es hacer “funcionar”, y si esas claves son definidas como parte del código fuente, deben estar disponibles por los medios “razonables” que especifica la licencia GPL para el código fuente.
Pero repito, no entiendo a dónde quieres llegar.
> Un criterio bien puede ser que exista una firma del binario por alguien que certificó el programa, sea el usuario mismo o alguien externo.
Es lo que hace por ejemplo TiVO… pero no sé tampoco qué quieres decir.
> Tampoco se requiere una llave para la ejecución del software. Simplemente, cuando se ejecuta un software no firmado (o el sistema operativo, o cualquier programa en la cadena, no está firmado), no se tiene acceso a ciertas llaves de decripción.
Eso está explícitamente prohibido por la licencia en el texto que puse en mi post , en la segunda parte (de la segunda sección) y que además puse en negritas.
> Pues que muchos evitarán utilizar esa versión de la GPL por no estar de acuerdo.
Mejor, está claro. Si estás a favor del DRM o te molesta que la GPL3 lo esté, no la uses, ni uses software con licencia GPL3.
> Y de paso, la GPL se estará “ensuciando” al salirse del marco técnico y definiendo qué cosas no se pueden hacer con el software.
La GPL (ninguna) nunca ha sido sólo una “referencia técnica”, ni desde el mismo preámbulo. Léelo y verás. La GPL es una implementación legal de la ética del software libre, que no técnica, sino profundamente filosófica.
> Comenzamos con “no se puede utilizar en sistemas DRM”, pero por favor cuál es exactamente la diferencia con “no se puede utilizar en la creación de material pornográfico”,
Eso es ya es delirar demasiado y casi un FUD irracional. ¿Has visto en cualquiera de las licencias GPL que regule las actividades privadas? No. Tampoco la GPL3, y lo dice _expresamente_. Por eso es una licencia de “distribución”. Incluso puedes _usar_ en sistemas DRM siempre y cuando sea _privado_, y no de distribución a terceros (deberías cambiar la palabra “utilizar” por distribuir, que la estás usando mal o no has entendido la licencia).
El DRM es totalmente contrario a la filosofía del SL, restringe las actividades privadas de los usuarios –además de convertirse en tutor moral–. Por eso se intenta que al menos no puedan usar SL para esas actividades.
Proponer como contra ejemplo uno que es justamente lo contrario –como el de regular actividades privadas– es una falacia (es tan absurdo como argumentar que un sistema democrático no sirve porque los dictadores podrían salir elegidos).
Repito porque eme parece importante: estás confundiendo los términos “distribuir” (propagación en la GPL3) con “utilizar”. La GPL no regula en ningún caso las actividades privadas que hagas con el software, es más, te autoriza expresamente que hagas lo que quieras si no requieres autorización expresa por las leyes de copyright y lo haces (”utilizas”) de forma privada:
To “propagate” a work means doing anything with it that requires permission under applicable copyright law, **other than executing it on a computer or making private modifications.**
…
This License explicitly affirms your unlimited permission to run the Program.
…
This License gives unlimited permission to privately modify and run the Program
Comment by gallir — Monday 30/1/2006 @ 17:44
Con “Me imagino que un sistema que entrega llaves para decriptar contenido” me refiero a un esquema parecido a la encripción de DVDs, pero donde la llave no forma parte del software, sino que sigue un esquema parecido a TCPA. Es decir, el programa para reproducir películas se instala y funciona sin requerir llaves de ningún tipo, por lo tanto no hay ningún problema con la licencia GPLv3. Sin embargo, el sistema operativo decide a quién entregarle la llave para decriptar una película específica, y no se lo entregará a una versión modificada de ese reproductor de películas. Es decir, el reproductor es software libre, se puede usar sin problemas pero finalmente el usuario estará sujeto a las restricciones de un DRM. Ergo, la cláusula no logra proteger al usuario de un esquema de DRM, solamente de algunos puntuales.
Yo puse: “Tampoco se requiere una llave para la ejecución del software. Simplemente, cuando se ejecuta un software no firmado (o el sistema operativo, o cualquier programa en la cadena, no está firmado), no se tiene acceso a ciertas llaves de decripción.”
Respuesta de Ricardo: “Eso está explícitamente prohibido por la licencia en el texto que puse en mi post , en la segunda parte (de la segunda sección) y que además puse en negritas.”
La parte que mencionas (”It also includes any decryption codes necessary to access or unseal the work’s output.”) no logra prohibir lo que describo. El programa reproductor de películas del ejemplo no genera un output encriptado, simplemente decripta un cierto contenido y lo envía a la pantalla (pero no a un archivo a menos que se modifique el programa, de forma que la firma ya no coincidirá). Para decriptarlo, necesita dos entradas: el contenido encriptado y la llave (que está en el programa). Cuando una aplicación externa (definitivamente no GPLv3) no le entrega la llave, entonces el reproductor de películas no es capaz de decriptar el contenido. El programa “funciona”: es perfectamente normal que, al no recibir la llave para decriptar el contenido, me entregue algún mensaje indicando eso, en vez del contenido decriptado. Es lo mismo que si trato de decriptar un e-mail encriptado para el cual no tengo la llave privada: no lo obtengo, y esa es la funcionalidad esperada. Y supongo que no es requisito para distribuir un software bajo GPLv3 asegurar que siempre tendrá acceso a toda llave privada, a pesar que esté fuera del control del usuario y del distribuidor del software. No lo dice la licencia y sería absolutamente ridículo.
El mismo ejemplo se aplica a la situación donde el usuario confía en un sistema al estilo TCPA para que evite que su llave privada sea entregada a programas poco confiables (spyware y demases). Luego, un programa para leer mails, licenciado bajo GPLv3 no podrá recibir las llaves necesarias para decriptar un e-mail y desplegarlo a menos que esté “certificado” por ese sistema TCPA. Es exactamente la misma situación, pero con un matiz menos “malévolo”.
Más abajo señalas que la GPLv3 no restringe el uso privado que se le puede dar al software. Justamente a eso voy: el usuario decide delegar en un software (controlado por él mismo o por la MPAA) a qué programas le entregará las llaves de decripción para ver películas. Eso es un uso privado. Luego, el reproductor de películas (licenciado bajo GPLv3) estaría en la práctica limitando los derechos del usuario final, pero sería perfectamente válido bajo GPLv3, así que el incluir las supuestas limitaciones a la licencia no sirve de nada.
Por otro lado, por qué esa manía de que DRM es lo peor que nos puede pasar, que es necesario evitarlo a toda costa? Hay varias aplicaciones útiles de esquemas de ese estilo. Lo que considero inaceptable es que las llaves sean controladas por instituciones como la MPAA u otras agrupaciones de intereses comerciales, pero si quien controla las llaves es el usuario, o bien la empresa donde el usuario trabaja, puede ser algo útil. Insisto: DRM es una herramienta, que puede ser bien o mal usada. El afán de eliminar esa herramienta de la faz de la tierra le resta seriedad al movimiento de Software Libre. Eliminemos los malos usos!
Comment by Jens Hardings Perl — Monday 30/1/2006 @ 18:47
Lo siento si no has entendido todavía, me parece que llevan un fregado de mucho cuidado con el cifrado y claves.
EL DVD sí es un sistema DRM (chapuza), basado en claves privadas y no la lleva el sistema operativo sino el reproductor y por supuesto no sería compatible con la GPL3.
> Por otro lado, por qué esa manía de que DRM es lo peor que nos puede pasar
Si no has entendido lo del DVD (que es muy fácil de entenderlo, sobre todo después del follón del DeCSS), ni tampoco porqué el DRM es malo y porqué la FSF (y la EFF) se opone, es que no podré convencerte en mi blog, quizás no pueda convencerte nunca.
Recomendación: no uses la GPL3.
Comment by gallir — Monday 30/1/2006 @ 18:55
Hola Ricardo.
Sabes algo sobre el protocolo RMI en Java? da muchos problemas.
Por cierto, al final aprobé/amos la practica de ASO.
Nos vemos el dia 1, ojala el examen sea facil.
Comment by mx — Monday 30/1/2006 @ 19:09
> Sabes algo sobre el protocolo RMI en Java? da muchos problemas.
El Java RMI es una forma de RPC (llamada a procedimientos remotos), algo similar al CORBA. Pero no tengo ni idea como funciona. Er… ¿qué tiene que ver con la GPL3 o DRM? Me perdí.
> Por cierto, al final aprobé/amos la practica de ASO.
Porque no os corregí yo
> Nos vemos el dia 1, ojala el examen sea facil.
Chupado, chupado, hasta yo lo sé contestar.
Comment by gallir — Monday 30/1/2006 @ 19:46
“EL DVD sí es un sistema DRM (chapuza), basado en claves privadas y no la lleva el sistema operativo sino el reproductor y por supuesto no sería compatible con la GPL3.”
He dicho lo contrario acaso? Lo que puse es que se puede perfectamente generar un sistema parecido al DVD en el sentido de que el contenido va encriptado, pero diferente porque justamente la llave no iría en el reproductor, como es el caso del DVD, ni tampoco en el sistema operativo, sino en algún ente externo o en el hardware. Cada vez que se quiere reproducir una película, que no es un DVD, se debe pedir la llave. A veces la llave se entrega, otras veces no, de acuerdo a algún criterio. ¿Entendida esa parte?
¿Estamos claros que no es necesario utilizar llave alguna para instalar o ejecutar un programa de esa naturaleza? El programa tampoco genera contenido encriptado, así que no hay nada en el borrador de la GPLv3 que evite su uso en ese esquema. Sin embargo, el usuario no podrá modificar el reproductor de películas para en vez de mostrarlo en pantalla lo grabe decriptado en un archivo por ejemplo.
Dices: “Si no has entendido lo del DVD (que es muy fácil de entenderlo, sobre todo después del follón del DeCSS), ni tampoco porqué el DRM es malo y porqué la FSF (y la EFF) se opone, es que no podré convencerte en mi blog, quizás no pueda convencerte nunca.”
Si no eres capaz de dar argumentos sino que vuelves a tu veredicto de lo estúpidos que somos los que no estamos de acuerdo con tus interpretaciones, supongo que no tiene más sentido discutirlo. Asumamos entonces que tienes razón y el DRM siempre será algo negativo, independiente que sea el usuario quien tenga control sobre todas las llaves involucradas con su propio hardware.
Pues bien, dado que como bien dices la licencia permite el uso privado del software sobre un sistema que implementa DRM, cómo se evitaría que el usuario quede sujeto a ese esquema de DRM? ¿Qué cláusula del borrador de la GPL tendría ese efecto?
No tengo problemas con usar la GPLv3 si mantiene el texto como está en el primer borrador. El punto es que esa licencia no evitará que se use el software libre en sistemas con DRM. Salvo para algunos esquemas de DRM sumamente limitados y poco efectivos como el que se ha visto en los DVDs.
Comment by Jens Hardings Perl — Monday 30/1/2006 @ 19:53
Por última vez y corto, que estamos en un bucle infinito.
¿Y qué parte de cualquier llave que se necesite para ejecutar el programa y obtener los resultados esperados tiene que ser entregada al usuario como si fuese parte del código fuente para que sea compatible con la GPL no entiendes?
¿O estás buscando la forma legal de no cumplir la GPL3 aún antes que se haya publicado?
Respecto al DVD, es que ni siquiera se puede hacer ningún software que sea libre para reproducirlo. EN USA y gran parte de Europa es ILEGAL. Tampoco es difícil de enteder las dificultades –legales, que no sólo técnicas o de la GPL3–.
> El punto es que esa licencia no evitará que se use el software libre en sistemas con DRM.
Sí que lo hace. No hace falta que me hagas caso a mí, lo dicen todos los expertos en leyes, copyright y licencias, Eben Moglen incluido, que creo sabe bastante más que cualquiera de nosotros dos.
Y si aún dudas, espera y analiza los resultados.
Disclaimer: IANAL.
Comment by gallir — Monday 30/1/2006 @ 20:02
Quizás me doy cuenta de lo que estás pensando.
Las claves deben estar a disposición del usuario para usarlas en cualquier versión del programa/sistema operativo, incluso si está modificado.
Si es así, por definición no es DRM, sino otra cosa, por ejemplo
programas para cifrar/descifrar datos.
Si no es así, ante la mínima restricción o control de qué se está ejecutando, no cumple con la GPL3.
Comment by gallir — Monday 30/1/2006 @ 20:12
Ricardo escribe: “¿Y qué parte de cualquier llave que se necesite para ejecutar el programa y obtener los resultados esperados tiene que ser entregada al usuario como si fuese parte del código fuente para que sea compatible con la GPL no entiendes?”
Eso se puede exigir para el software mismo, pero lo que estoy diciendo es que las llaves no tienen por qué ser parte del software. Mal se puede entonces entregar una llave que no depende ni del creador del software ni del usuario sino del hardware. Y exigir las llaves del hardware en una licencia para uno de los tantos software que correrá el sistema está fuera de lugar. La GPLv3 lo que pide es que el código fuente incluya todas las llaves necesarias para instalar y ejecutar el software. No habla de que otro software, con el cual interactúa el software bajo GPLv3 tenga alguna obligación de entregarle siempre las mismas llaves sin importar si se modifica, y mal podría exigirlo.
Ricardo escribe: “¿O estás buscando la forma legal de no cumplir la GPL3 aún antes que se haya publicado?”
Bueno, de eso se trata justamente, no? Encontrar problemas y corregirlos _antes_ de que la GPLv3 esté terminada y se comience a utilizar…
Ricardo escribe: “Las claves deben estar a disposición del usuario para usarlas en cualquier versión del programa/sistema operativo, incluso si está modificado.” … “Si no es así, ante la mínima restricción o control de qué se está ejecutando, no cumple con la GPLv3.”
De acuerdo a eso, si el programa está instalado en un sistema cuyo hardware le entrega la llave necesaria solamente si no es modificado, debiera ser considerado que no cumple con la GPLv3. Pero qué es lo que no cumple? El Software, el hardware o el usuario?
Si es el software, si ese mismo software se instala en un sistema sin DRM sí cumple? O sea que se restringe el uso privado del software? Si es el hardware, cómo se le podría exigir legalmente algo al hardware en el que va a correr un programa? Si es el usuario el que no cumple, no habíamos quedado en que no había restricción para el uso particular del software?
Comment by Jens Hardings Perl — Monday 30/1/2006 @ 22:13
Aquí hay comentarios de otra persona (bastante respetable por lo demás) que sugiere lo mismo que yo (una forma de cumplir con la GPLv3-draft1 que no impide que el sistema acate DRM): http://lwn.net/Articles/167946/ . Espero que esté mejor explicado. Para ver el thread completo, ver http://lwn.net/Articles/167825/#Comments
Comment by Jens Hardings Perl — Monday 30/1/2006 @ 22:55
Sipes, lo he leído, pero en todo caso Karim presenta un “vacío legal” (loophole) en las palabras usadas y que seguramente será solucionado (además Karim no cree en que la licencia sea el lugar “adecuado” para luchar contra el DRM, pero eso es otro problema). Pero fíjate que habla de usar programas NO GPL3 para acceder al sistema de DRM, como el firmware y empaquetar todo el DRM en aplicaciones individuales. No dice que con software licenciado con GPL3 se pueda hacer eso.
Por un lado es un problema más complejo, pero seguramente será estudiado y desde el principio estás obligando a usar programas que no sean GPL3. Luego podrías llevarte una sopresa en que esos fabricantes tampoco puedan usar muchas de las herramientas que usan, tanto de GNU como otros proyectos, como BusyBox. Ya lo verás
Comment by gallir — Monday 30/1/2006 @ 23:07
Si lees bien, yo digo exactamente lo mismo: el acceso lo determina un programa no GPL, pero en la práctica el programa GPL es quien no podrá desplegar contenido bajo DRM a menos que sea la versión “permitida” por el distribuidor del contenido. Es exactamente lo mismo que dice Karim.
A lo que voy es que si se logra efectivamente prohibir el DRM cerrando ese “loophole”, también habrá otros usos que se verán afectados. Por ejemplo, instalar un MUA bajo GPLv3 sobre alguna futura versión de Microsoft Windows (que seguramente vendrá con DRM que controlará el acceso a las llaves necesarias). O permitir al usuario discriminar por medio de las herramientas DRM que existirán en ese futuro si quiere que a cierto programa GPL se le de acceso a utilizar sus llaves. O que una empresa use software GPL para controlar mediante DRM quiénes tienen qué acceso a documentos confidenciales. Ese tipo de aplicaciones son perfectamente válidas para una gran cantidad de personas que desarrollan software, mucho del cual está bajo GPLv2 ahora. Esos se la pensarán varias veces antes de prohibir esos usos para su software, ya que estarían efectivamente restringiendo la libertad de los usuarios. Además que contradice la libertad de uso que entrega la GPL…
Comment by Jens Hardings Perl — Tuesday 31/1/2006 @ 14:08
Seguramente hay muchos casos en que la GPL3 no podrá hacer nada, pero al menos seguro que se evita que se use “directamente” software GPL para sistemas DRM.
> Esos se la pensarán varias veces antes de prohibir esos usos para su software, ya que estarían efectivamente restringiendo la libertad de los usuarios. Además que contradice la libertad de uso que entrega la GPL…
De nuevo, la GPL3 no limita para nada el uso personal del software, así que difícil podrá limitar la libertad de los usuarios.
Es el DRM el que lo hace, no la GPL3.
Comment by gallir — Tuesday 31/1/2006 @ 14:24
“Seguramente hay muchos casos en que la GPL3 no podrá hacer nada, pero al menos seguro que se evita que se use “directamente” software GPL para sistemas DRM.”
… En otras palabras, la GPLv3 no sirve para evitar que los usuarios de software GPL se vean afectados por DRM (al usuario que no puede acceder al contenido le da exactamente lo mismo si es directa o indirectamente). El que sea directo o indirecto además no hace una diferencia de esfuerzo para el que quiere imponer DRM, ya que de todas maneras el programa no-GPL que define quién tiene acceso no será GPL y probablemente no se dejará que la gente sepa cómo se determinan sus “derechos”.
Entonces, si no es efectivo, para qué se intenta meter en la GPL? Si queremos luchar contra un DRM en el cual son los distribuidores de música y películas los que controlan los dispositivos que todos compramos, hagamos eso. Pero meterlo en la GPL no cumple el objetivo, desperdicia esfuerzo y divide a los programadores.
Comment by Jens Hardings Perl — Tuesday 31/1/2006 @ 15:33
> Entonces, si no es efectivo, para qué se intenta meter en la GPL?
Porque va contra el espíritu de la filosofía del software libre. Y porque los usuarios de software libre no podemos usar legalmente NINGÚN sistema con DRM, DVD incluidos.
Ya te digo, si estás convencidos de los principios filosóficos del software libre, no haría falta explicarte los motivos. Si no estás convencido, como parece ser el caso, no hace falta que te preocupes del tema. Elige otra licencia para tus propios desarrollos, o elige software que no sea GPL3 si necesitas distribuir.
No hay indicios de que el tema de DRM divida a los programadores de software libre (que no el “open source”). Además pueden seguir usando la GPL2, que no tiene vencimiento.
Comment by gallir — Tuesday 31/1/2006 @ 15:52
Da lo mismo si estoy o no convencido. Estamos hablando de una licencia que va a afectar a convencidos y no convencidos. Si simplemente se quiere dar un statement de lo malo que es un esquema de DRM, para qué ponerlo en una licencia que la mayoría de los usuarios no leerán (al menos aquellos que aún no tienen una opinión formada sobre el tema)? Existen muchas otras campañas anti-DRM que tendrán mayor influencia. Personalmente voy a poner mi esfuerzo en esas campañas, sobre todo en las que tienen como objetivo educar sobre qué implica el utilizar tecnologías que mutilan los derechos de los usuarios. Con ello se evitará que muchos usuarios compren esos sistemas para esclavizarse, y se ataca a las instituciones que las impulsan por el único lado que les duele: hacer que no sea lucrativo.
Si realmente te importa tenerlo explícitamente: sí, estoy absolutamente en contra de los sistemas DRM que se pretenden instaurar. Pero estoy conciente que hay potencial en usar sistemas muy parecidos para fines útiles, y sería muy penoso que nos disparemos en el pie por falta de visión.
Comment by Jens Hardings Perl — Tuesday 31/1/2006 @ 19:52