Reading the articles on PRM as the next step by Ed Felten, about how the reasons put forward to justify DRM-related laws have shifted, I started reasoning about what such a law should look like. So, here I present some thoughts on what a law regarding DRM, that really considers the general public (society) and potential new authors, should look like.

Basically, people are used to make things in certain way. The problem DRM poses is that it has the potential to force a change in the way people can do things, without ever telling anybody about it until it is too late. This is why the “trusted computing” has been rephrased as “treacherous computing”: it effectively deceipts the general public into beleiving what it is told (better quality of some “content”) as being the only consequences of the new technologies. But the most important characteristics are kept quiet and do not surface until the users have already made their choices, the market has accepted some technology under false premises and there is no turning back.

In order to avoid this treacherous method of forcing certain technologies to unsuspecting users, the users should have all of the information before choosing, which is a very basic requirement by the way. The steps to force this could be the following. In order to distribute a device that enforces DRM, it is necessary for the vendor to:

1. inform exactly and in detail how the DRM solution will work and what the consequences are for end users. (specification)
2. provide ways to verify reliably that the devices effectively work exactly as described in the specification. The best way to do so would be to make the source code available and provide a way to compile the source into the binary that is effectively distributed along with the devices.
3. allow the user to keep the old specification or override (circumvent) the DRM when a change is made to the original specification.

If we assume as a fact that software enforcing DRM will exist in the future, I would rather like to have the code available, and being able to reproduce the compilation exactly as to generate the same binary that has been signed as “trusted”. That way, at least I would have enough information to choose whether I could trust the system enough or not, and this would set abuses on the part of publishers to a minimum. This does not mean that the code should be under the GPL, though. So up to this point there is really no problem.

There are some issues, though, where I’m not so sure about. One phrase in particular states:

“However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.”

I wonder what this implies. Let’s take The GIMP as an example, as it is a useful program, not implementing any DRM schemes and working on the Microsoft Windows platform. Suppose that the GIMP is available under GPLv3 and keeps to be compatible with the MS-Windows platform. What if the next version of MS-Windows implements a DRM scheme in which an application has to be signed before it may access a certain file? This would imply a key generated based on the object code, and thus somebody should make the key available. The question is: who? Apparently, the people distributing (conveying according to the new wording in GPLv3 beta 2) the code. So, as these people have nothing to do with the release of a new MS-Windows version, how on earth are they supposed to distribute the key? Until the existence of that new version, everyting worked smoothly. Now, because of some action of a third party, The GIMP can no longer be redistributed, because the Corresponding Source is impossible to be made available without the collaboration of somebody not related at all (and, probably interested in avoiding the availability of The GIMP)? And by way of the “Freedom or death” clause, if one cannot guarantee every right stated in the GPL, the software cannot be conveyed anymore, to nobody. That just doesn’t make sense to me. Seems to me like the perfect denial-of-service activity in the software development field: create a new feature on a system, and magically it makes some competing software illegal.

If, on the other hand, the case mentioned above resolves to The Gimp being available to anybody, including the ones who use that new DRM implementing MS-Windows version, then the fight against DRM is lost. Because the GIMP will then be subject to the DRM rules and the GPLv3 would have nothing to say against it. In the case of the TiVo, it would not be possible to distribute something which is GPLv3′d and prohibiting the system to run, but only because the system is conveyed as a unit. If the hardware plus the DRM-enabling components (hardware plus software) is distributed by some different party, either we have the case in the previous paragraph, or the GPLv3 would not avoid tivoization. Both outcomes are unacceptable for a free software license that intends to avoid tivoization.

I sympathize with the opponents of DRM technologies. The motivation for them is mainly to extend the established (and in many ways already too wide) rights by adding a technological measure. It doesn’t seem right to use technology to narrow even more the usage you can make of information, and the result is unfair, benefiting the powerful over the weak and/or scattered ones.However, it also doesn’t seem right to impose an ethical view by the usage of software, through the licensing of that software. It would be OK to keep the freedom to use a certain software (avoiding tivoization as Stallman puts it) and thus avoid DRM for that case. But are we certain we aren’t shooting ourselves in the foot?

“I forsee a marked deterioration in American music…and a host of other injuries to music in its artistic manifestations, by virtue—or rather by vice—of the multiplication of the various music-reproducing machines…” -John Philip Sousa on the Player Piano (1906)

“The public will not buy songs that it can hear almost at will by a brief manipulation of the radio dials.” -Record Label Executive on FM Radio (1925)

“But now we are faced with a new and very troubling assault on our fiscal security, on our very economic life and we are facing it from a thing called the videocassette recorder.” -MPAA on the VCR (1982)

“When the manufacturers hand the public a license to record at home…not only will the songwriter tie a noose around his neck, not only will there be no more records to tape [but] the innocent public will be made an accessory to the destruction of four industries.” -ASCAP on the Cassette Tape (1982)

Seen via El Diablo en los Detalles and Arstechnica.

]]> http://www.hardings.cl/blog/2006/06/23/the-same-argument-over-and-over/feed/ 0 http://www.hardings.cl/blog/2006/01/30/objetivos-de-gplv3-con-respecto-a-drm/ http://www.hardings.cl/blog/2006/01/30/objetivos-de-gplv3-con-respecto-a-drm/#comments Mon, 30 Jan 2006 16:21:54 +0000 Jens Hardings http://www.hardings.cl/blog/2006/01/30/objetivos-de-gplv3-con-respecto-a-drm/ Ricardo Galli, en un intento por explicarme los objetivos y la forma en la cual el draft de la GPLv3 ataca el DRM, repite los objetivos de las cláusulas y cómo se espera que funcionen. No tengo dudas con eso, lo que yo planteo es que los objetivos no se cumplen, porque las cláusulas no funcionarán. Me hubiese gustado que se refiriera al ejemplo que planteo en el post que motivó su respuesta, así que replanteo los temas:

• Me imagino que un sistema que entrega llaves para decriptar contenido (como un e-mail encriptado) a un programa en base a algún criterio, y si no cumple con ese criterio (por ejemplo, confianza en que no reenviará ese e-mail decriptado a toda la dirección en la agenda) no se le entrega la llave, debiera poder licenciarse bajo GPLv3.
• Un criterio bien puede ser que exista una firma del binario por alguien que certificó el programa, sea el usuario mismo o alguien externo.

Si parece aceptable un esquema así, entonces es aceptable que ese programa esté en un sistema de DRM, y con eso no se logra el objetivo de desincentivar el uso de software libre en sistemas con DRM. Pero supongamos que no se considera aceptable el esquema. En tal caso, tampoco sería aceptable el sistema de manejo de mails encriptados que describí en el artículo anterior. Eso limitaría el campo de acción de cualquier programa derivado de código GPLv3, que es una consecuencia poco afortunada por decir lo menos.

Veamos entonces en qué nos afectaría la redefinición de “código fuente”. El sistema que menciono en el post anterior permite que se instale cualquier programa sin necesidad de una llave. 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. Por lo tanto, el objetivo de “evitar el recorte de las libertades por mecanismos de hardware” no se cumple, y tampoco se cumple el “desincentivar sino impedir el uso de software libre en sistemas con DRM”.

Lo que nos resta es entonces que cualquier esquema de DRM no puede contener directamente ningún código que esté licenciado bajo GPLv3. Cualquier fabricante tendría por lo tanto que desarrollar su propio driver y software de manejo de claves para poder utilizar DRM, y sobre eso instala sin problemas software GPL. Vale la pena el costo que se está asumiendo solamente para obligar a algunos fabricantes a desarrollar su propio software? Sobre todo considerando que es muy poco probable que esos fabricantes ocuparan software GPL para eso, me parece que no.

Cuál es el costo del que hablo? Pues que muchos evitarán utilizar esa versión de la GPL por no estar de acuerdo. 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. 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”, “no se puede utilizar para generar documentos con errores de ortografía” o “no se puede utilizar para publicar ideas que vayan en contra del gobierno chino”?

]]> http://www.hardings.cl/blog/2006/01/30/objetivos-de-gplv3-con-respecto-a-drm/feed/ 7 http://www.hardings.cl/blog/2006/01/27/gplv3-no-evita-el-uso-de-drm/ http://www.hardings.cl/blog/2006/01/27/gplv3-no-evita-el-uso-de-drm/#comments Fri, 27 Jan 2006 15:23:20 +0000 Jens Hardings http://www.hardings.cl/blog/2006/01/27/gplv3-no-evita-el-uso-de-drm/ 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:

1. La llave no forma parte del programa
2. No es necesario tener una llave para instalar el programa en el sistema
3. Se requiere una llave especial para poder decriptar un contenido específico que un programa bajo GPLv3 pretende desplegarle al usuario
4. 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.

]]> http://www.hardings.cl/blog/2006/01/27/gplv3-no-evita-el-uso-de-drm/feed/ 4