[okfn-br] Say NO to DRM in HTML5!
Rafael Pezzi
rafael.pezzi em ufrgs.br
Quinta Maio 16 17:59:40 UTC 2013
Também vou levantar outro ponto contra o DRM no HTML5.
Como citado anteriormente, o DRM foi criado para manter um modelo de
negócio específico de um setor da indústria.
Caso o DRM seja definido no HTML5, todos os desenvolvedores que forem
implementar o padrão em algum projeto terão que fazer um esforço
adicional para tornar o seu projeto compatível com o DRM e isso
significa que estarão trabalhando de graça para aqueles que precisam de
DRM, que por sua vez não precisam contratar ninguém para fazer plugins e
software-clientes para que vendam seus produtos.
Na prática, pode acontecer de muitos se recusarem a implementar esta
porção da especificação em suas soluções, como alguém sugeriu aqui nesta
lista e iria acabar surgindo uma série de soluções não completamente
compatíveis com HTML5.
Rafael
Em 13-05-2013 12:19, Felipe Sanches escreveu:
> Existem, entretanto, outras razões para se refutar o DRM (dentro ou
> fora do HTML5).
>
> Uma razão menos legalista que a exposta no meu email anterior a este,
> mas não por isso menos válida, é o fato de que para serem efetivos os
> mecanismos de DRM pressupõem implementações proprietárias. Explico:
>
> Um software possui "features" (em português, "funcionalidades").
> Features são coisas benéficas para os usuários do software, coisas que
> fazem o software ser melhor do que era antes das features serem
> introduzidas por uma nova versão.
>
> Mecanismos de DRM são features de um software, do ponto de vista do
> detentor dos direitos autorais de uma obra restrita pelo DRM. Por que
> servem o propósito do detentor. Entretanto, mecanismos de DRM são uma
> "anti-feature" (ou "desfuncionalidade") do ponto de vista do usuário
> final. Por que quando um usuário quer fazer algo e o mecanismo de DRM
> o impede de fazer, obviamente há um sentimento de frustração, dado que
> o software não atende às expectativas do usuário. O software seria
> considerado melhor para o usuário se ele não tivesse essas
> características introduzidas pela "anti-feature" de DRM.
>
> Uma das grandes importâncias do movimento do software livre para a
> sociedade é justamente a realização da idéia de que o usuário deve ter
> a palavra final sobre o funcionamento dos softwares que ele utiliza.
> Ou seja, se o usuário está descontente com alguma característica de um
> programa, ele **tem que ter** o direito de poder alterar o programa de
> modo que passe a atender suas expectativas. Seja por meio de
> intervenção direta no código fonte livre (caso o usuário seja um
> programador) ou seja por meio da ajuda um amigo que tenha o
> conhecimento técnico para tal, ou até mesmo por meio da contratação de
> um programador profissional que lhe preste o serviço de customização
> do software em questão. De todo modo, a idéia central do sw livre é
> que adaptar o sw deve necessariamente ser possível de alguma forma,
> para que o usuário não seja refém de restrições impostas
> (intencionalmente ou por acidente) pelo programador original do sw.
>
> Sendo assim, se um mecanismo de DRM for implementado em software livre
> (ou seja, software que respeita os usuários), o usuário pode
> simplesmente remover a desfuncionalidade em questão e, se for um cara
> legal, até mesmo compartilhar com o mundo a versão sem DRM do
> programa. Portanto, para DRM funcionar de forma efetiva, pressupoe-se
> que será implementado como software proprietário, de modo a
> impossíbilitar sua remoção. E, com isso, não só a característica de
> DRM, mas todas as características do software passam a estar cravadas
> na pedra e o usuário está mais uma vez preso de mãos atadas.
>
> Felipe Sanches
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
>
>
Mais detalhes sobre a lista de discussão okfn-br