<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
+1 a la ingesta de batracios... a veces no queda otra.<br>
<br>
¿Que pasa si Mozilla no toma este paso? ¿Realmente creemos que esto
va a generar un movimiento de indignados clamando por ver Netflix
sin DRM? ¿O simplemente la gente va a ir a usar el browser donde lo
que quiere ver le funcione?<br>
<br>
s2<br>
<br>
~Carlos<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/16/14, 2:41 PM, Alejandro
Vartabedian wrote:<br>
</div>
<blockquote
cite="mid:CAOSst85FbnO=g5OtkdS-6tYGzdbqkoXfDOBCdEzgeS2cjN3LkA@mail.gmail.com"
type="cite">
<p dir="ltr">Los equilibrios como tales se dan por la existencia
de un opuesto de igual peso o intensidad, por lo que creo que
gracias a entidades o posturas como la FSF los puntos de
equilibrio aún están en posiciones digeribles por la gran
mayoría de nosotros. <br>
Si el extremo opuesto a DRM fuera otro, el punto de equilibrio
seguramente sería otro.<br>
Es entendible la posición de Mozilla.<br>
Esta es una batalla que se debe ganar en los hechos y desde
adentro, a veces tragándose un sapo.<br>
Saludos y gracias Eduardo por el feedback.</p>
<div class="gmail_quote">El 15/05/2014 17:41, "Marcelo Zunino"
<<a moz-do-not-send="true"
href="mailto:marcelo.zunino@gmail.com">marcelo.zunino@gmail.com</a>>
escribió:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jue 15 May 2014 11:37:03 Eduardo Trápani escribió:<br>
. Hola,<br>
.<br>
. Creo que sí o sí hay que leer lo que dice
Mozilla al respecto[1] "DRM y<br>
. el desafío de servir a los usuarios". Es
realmente comprensible lo que<br>
. están haciendo y cómo intentan hacerlo[2] y las
alternativas que han<br>
. ofrecido durante este tiempo (hay que recordar
que esta batalla se libra<br>
. en la W3C y, una vez sea adoptada allí tendrá el
mismo valor que,<br>
. digamos, HTML5).<br>
.<br>
. Si tuviera que explicarlo yo diría: imagínense
que para ver ciertos<br>
. videos hay que usar otro navegador. Piénselo
como usuarios, tienen un<br>
. navegador X que muestra todo, un navegador Y que
muestra todo menos<br>
. ciertos videos, ¿cuál van a usar? Hay un perfil
de usuarios que utiliza<br>
. simultáneamente varios navegadores, pero para la
mayoría se trata de<br>
. elegir el "navegador por defecto" y ahí se van a
quedar.<br>
.<br>
. Entonces, queremos cambiar la web, volverla y
mantenerla abierta,<br>
. devolverle/darle el control al usuario, ¿a
partir de dónde? ¿De un<br>
. navegador que no permite acceso a contenido
importante para los usuarios<br>
. y que finalmente nadie usa? Esa estrategia
podría andar, pero tiene<br>
. claramente un componente suicida.<br>
.<br>
. Fíjense que hasta la propia Apple defenestra
Flash *después* de tener la<br>
. alternativa HTML5 en YouTube. El video HTML5 ya
estaba listo y los días<br>
. de apogeo de Flash terminándose. ¿Por qué
esperar hasta la madurez de<br>
. video HTML5 y seguir permitiendo Flash hasta
entonces? Porque hay<br>
. ciertas cosas que un sistema/navegador no puede
dejar de hacer si no<br>
. quiere desaparecer y mostrar videos en la web es
una de ellas.<br>
.<br>
. Pero Mozilla no se queda en el "me obligan a
hacerlo". No. Parte de la<br>
. resistencia a que esto siga así viene en el
"cómo hago lo que me obligan<br>
. a hacer". Y eso, el cómo, es MUY IMPORTANTE[2].
En ese enlace hay<br>
. algunos detalles técnicos sobre la
implementación. Dos cosas a<br>
. mencionar: les va a preguntar antes de usar la
tecnología (porque sigue<br>
. tratándose de que el usuario esté en control) y
va a correr la parte<br>
. cerrada del código de manera de poder controlar
y monitorear los accesos<br>
. que realice.<br>
.<br>
. Ofrezco otro punto de vista, para entender a
Mozilla: Distribuciones de<br>
. Linux y módulos cerrados. O una visita al área
de firmware del kernel[3]<br>
. (el detalle de las licencias, acá[4]). El propio
Debian, sacando todo lo<br>
. cerrado del kernel afuera de la distribución,
pero a una agregada de<br>
. repositorio y apt-get de distancia.<br>
.<br>
. FSF puede "condenar" (término usado solamente en
el título, al mejor<br>
. estilo sensacionalista, porque leyendo lo que
dicen es bastante más<br>
. liviano y centrado, de hecho están "muy
decepcionados"). También puede<br>
. condenar y etiquetar a Linux, a Debian y de
hecho lo ha hecho y hace.<br>
. Pero por favor, hay que contextualizar esa
condena. Estarán<br>
. decepcionados con Mozilla por esto, pero
seguramente no con todo lo que<br>
. constante y consistententemente han hecho por el
software libre y la web<br>
. abierta. Podrán enojarse con Linux por
distribuir código cerrado en su<br>
. repositorio público, pero sería muy tonto negar
que el sistema ha sido<br>
. el motor del movimiento. Y meterse con Debian
por tener un repositorio<br>
. non-free (no incluído por defecto) es
comprensible.<br>
.<br>
. Ojo, es un día triste para la web abierta, se
perdió una batalla, pero<br>
. en un mundo con EME[5] vamos a seguir estando
mucho mejor con Firefox<br>
. (elijamos instalar EME o no) que en los otros
navegadores. Y sino ...<br>
. siempre se puede hacer un fork.<br>
.<br>
. Dejo un pasajecito interesante de Steve Jobs en
"Thought on<br>
. Music"(2007)[6]. El artículo en general habla
justamente de lo que<br>
. pasa(ba) con la música en la tienda de Apple:<br>
.<br>
. > The third alternative is to abolish DRMs
entirely. Imagine a world where every online store sells
DRM-free music encoded in open licensable formats. In such a
world, any player can play music purchased from any store, and
any store can sell music which is playable on all players.
This is clearly the best alternative for consumers, and Apple
would embrace it in a heartbeat.<br>
.<br>
. Lo mismo se aplica a los videos y creo que ese
pensamiento lo<br>
. compartimos los usuarios y Mozilla y la FSF y es
eso, la libertad, la<br>
. web abierta y el control de usuario, lo que nos
mueve. No paremos. El<br>
. final de ese documento[2] creo que es bien claro
en lo que se quiere, lo<br>
. que se puede y el futuro que incluye para
Mozilla detalles importantes,<br>
. como librarnos de los plugins.<br>
.<br>
. Eduardo.<br>
.<br>
. [1]<br>
. <a moz-do-not-send="true"
href="https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/"
target="_blank">https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/</a><br>
. [2]<br>
. <a moz-do-not-send="true"
href="https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/"
target="_blank">https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/</a><br>
. [3]<br>
. <a moz-do-not-send="true"
href="http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/firmware/"
target="_blank">http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/firmware/</a><br>
. [4]<br>
. <a moz-do-not-send="true"
href="http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/firmware/WHENCE?id=HEAD"
target="_blank">http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/firmware/WHENCE?id=HEAD</a><br>
. [5]<br>
. <a moz-do-not-send="true"
href="https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html"
target="_blank">https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html</a><br>
. [6]<br>
. <a moz-do-not-send="true"
href="http://web.archive.org/web/20070207234839/http://www.apple.com/hotnews/thoughtsonmusic/"
target="_blank">http://web.archive.org/web/20070207234839/http://www.apple.com/hotnews/thoughtsonmusic/</a><br>
<br>
<br>
Gracias Eduardo. Pensé antes de poner una respuesta que dijera
sola mente<br>
"gracias" o "+1" o ... "estoy de acuerdo" o "en contra".
Coincido con vos, la<br>
propuesta de Mozilla es razonable y es válida, aún desde una
perspectiva<br>
muy FSFera, como la mía.<br>
<br>
Es claro que también entiendo la actitud de la FSF. Son
ingredientes obligados,<br>
sin ese punto de vista, sin esa referencia, cosas como las
explicaciones o<br>
aclaraciones de Mozilla, quizá no fueran una necesidad. Y es
muy bueno que<br>
Mozilla lo haga, es sano y es libertario (por decirlo de algún
modo)<br>
<br>
Las definiciones son imprescindibles, con total independencia
de quién lo haga.<br>
En este sentido es circunstancial que sea FSF quién lo venga
haciendo desde<br>
hace mucho tiempo. El corpus de principios, el fundamento
filosófico y base<br>
jurídica del software libre, en tanto concepto no es
espontánea, debe ser<br>
realizada, y no es una tarea que puedan desempeñar las
empresas o entidades<br>
como "el mercado".<br>
<br>
Por suerte alguien lo hace como principal tarea. Por suerte
con una orientación<br>
clara, sin marchas y contramarchas.<br>
<br>
Los Mozilla, los Apache, las OSI, las Redhat, Suse, android y
larga lista son<br>
componente fundamental en la difusión, en el alcance, en el
equilibro, y<br>
particularmente en la *diversidad* de la comunidad de software
libre.<br>
Es fuente elemental de la riqueza y es base de la fortaleza de
nuestra comunidad.<br>
<br>
Cómo sea, es gracias Eduardo, especialmente por el rigor, la
seriedad, la<br>
honestidad intelectual y el respeto que tenés hacia quienes
leemos esta lista.<br>
<br>
Saludos.<br>
Marcelo.<br>
<br>
_______________________________________________<br>
Uylug-varios mailing list<br>
<a moz-do-not-send="true"
href="mailto:Uylug-varios@listas.uylug.org.uy">Uylug-varios@listas.uylug.org.uy</a><br>
<a moz-do-not-send="true"
href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy"
target="_blank">http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Uylug-varios mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Uylug-varios@listas.uylug.org.uy">Uylug-varios@listas.uylug.org.uy</a>
<a class="moz-txt-link-freetext" href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy">http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy</a>
</pre>
</blockquote>
<br>
</body>
</html>