La mayor parte de la discusión en relación a la nueva versión de la GPL (versión 3) está en su intento por evitar el uso de Software Libre en cualquier esquema de DRM. Mi interpretación de la licencia es que en realidad sólo se evita un cierto tipo de sistemas de DRM, que por lo demás han dado suficiente evidencia que no funcionan (ver lo que ha escrito Felten al respecto para detalles). Es más, Bruce Schneier incluso postula que ningún sistema de DRM va a funcionar, incluyendo los basados en hardware, argumentando que sería como intentar que el agua no moje. Pero aunque no funcionen, el término de “efectivo” en la legislación es bastante curioso: aunque no funcione, sigue siendo “efectivo” y al menos continúa siendo ilegal eludir esas medidas “efectivas”.
Ahora, de la misma manera en que no todos los usos de redes P2P son para crear copias ilegales, tampoco todos los usos de DRM son para reprimir y abusar de los consumidores. DRM es una herramienta que bien usada puede ser útil, y mal usada puede causar daño; no es la encarnación del diablo.
Supongamos que es perfectamente posible tener un sistema de DRM que funcione de la siguiente manera:
- La llave no forma parte del programa
- No es necesario tener una llave para instalar el programa en el sistema
- Se requiere una llave especial para poder decriptar un contenido específico que un programa bajo GPLv3 pretende desplegarle al usuario
- La llave del punto 3 es entregada por el sistema al programa, siempre y cuando el sistema “confíe” en el programa.
Un sistema así, independiente de si es implementado en hardware o software, tiene varias ventajas y se puede prestar para diversos usos, dependiendo de quién controle cómo el sistema decide si entregar o no la llave al programa. Si es el usuario quien controla cómo se entregan las llaves, puede firmar diversos programas “confiables”, lo cual puede incluir o no el software licenciado bajo GPLv3. Obviamente no incluiría spyware ni otras formas de atentar contra su privacidad, y así los documentos y materiales bajo DRM no podrán ser utilizados por los que lograron instalar ese spyware o convencer al usuario de ejecutar algún progama malicioso, pero si por los programas que el usuario se encargó de firmar.
Veamos un ejemplo concreto: un simple MUA que permite recibir correo electrónico encriptado. Para decriptarlo, el MUA debe tener acceso a la llave. Si la llave está guardada en el sistema (o fuera de él, en una smartcard o token) pero fuera del programa, algo o alguien decide si entregarla al programa. Si la GPLv3 acepta eso, entonces no hace nada contra un esquema de DRM en general, solamente contra esquemas DRM donde la llave está incluida en el programa. Para poder evitar el uso de DRM, lo que la GPLv3 debiera regular es el criterio con el que se decide si entregarle la llave a ese programa o no. Es decir, quien decide si un programa tiene acceso o no a una llave es la licencia (ergo, el “fabricante” que decidió usarla), no el usuario. Y todo eso en pos de la libertad del usuario. Suena a contradicción para mi gusto.
Supongamos entonces que la GPLv3 permite al usuario decidir si entregarle la llave a un programa o no. Entonces ese usuario puede delegar la decisión a algún subsistema que forma parte de una “protección tecnológica efectiva”, y ese subsistema le entrega la llave al programa solamente si existe una firma “autorizada” del binario del programa y puede verificar que el binario en ejecución corresponde al firmado. Así, cualquiera puede modificar el código, pero al hacerlo ya no se le entregará la llave al programa y por ende no podrá desplegar el contenido bajo DRM.
Mi opinión es que no vale la pena el esfuerzo de meter esas restricciones en la GPL, considerando que los sistemas que podrían, potencialmente, verse afectados de todas formas no van a funcionar. Tampoco se lograría evitar que un software libre se use en un sistema que implementa DRM, así que cuál es el punto? Acelerar la adopción de mejores sistemas de DRM?
Por último, sería el primer caso donde una licencia es aceptada por la FSF (como Software Libre) y no por la OSI (como Open Source), por no cumplir con el punto nueve de la Open Source Definition (“License Must Not Restrict Other Software”) si se prohibe al usuario delegar la decisión de entregar la llave en un software que no controla.