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 > [email protected] > http://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br > > _______________________________________________ okfn-br mailing list [email protected] http://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
