Theo writes: > I would argue the opposite. I think that our best defense is to try as > hard as possible to make a blocking mechanism impossible. > [quoting an essay on eff.org:] > "A file-sharing technology provider such as > Freenet that is incapable of blocking access to users or disabling files > because of its architectural design, seems to be at a legal advantage to > systems such as Napster under the ruling."
I'll respond to this one briefly because it is marginally on-topic for development issues. There is nothing in Freenet that makes it architecturally incapable of blocking files. The copyright holders would specify the keys they want blocked, whether CHKs representing the actual content, or KSKs (or whatever) representing the names of their files. On request, node operators would have to remove the content and block future accesses to that key. If people re-submit the material under new keys, those would have to be blocked if and when the copyright owners learned about them and complained. It's true that there is nothing in the code base now which does this, and the developers may not want to add any such thing. But after all, there is nothing in Napster's code that does that, either. Yet the court is going to force them to run code that adds blocking features. The court could do the same thing to Americans running Freenet. Any developer can judge for himself the difficulty of adding a block list similar to what was done for the OpenNap project a few days ago. I'll leave it at that. Hal _______________________________________________ Devl mailing list Devl at freenetproject.org http://www.uprizer.com/mailman/listinfo/devl
