How is it possible to import a BVH-File (BVH-Animation) into Blender? If i just go to Import and want to import one, Blender is creating a new “Blender-Armature”.
But how to use the animation in the SL-Armature so i can export it later?

The second issue is purely technical. Although my suggestion (as Jacek somehow implies) did not require a manual review of the code (which, indeed, would take months given the amount of code in the SL viewer), but a more simple certification process of the developers, tied to a key exchange between LL, the developer, and the user with a “certified client” (which would have a certification issued based on a checksum of the binary; this can be done online and would take an amount of time equal to uploading a 50 or 60 MByte file — which takes several minutes or an hour, depending on the developers’ upstreaming bandwidth — but not more than that: the key idea was an automatic process).

This three-party method can, however, be reasonably easily forged or intercepted assuming one has the source code for the bits doing the validation. My assumptions were the following:

- the developer gets certified by Linden Lab. This means that there is a special relationship between LL and that particular developer. That’s not an extraordinary requirement. For instance, testing the Open Grid Protocol with LL was limited to a number of people who had to provide minimal data to LL; being part of the Registration API network requires a bit of effort (and LL manually activating certain capabilities on your avatar), but it’s also not very hard to do; whereas enrolling for the Risk API is, indeed, not easy. Age validation can go from purely automatic to manual faxing of documents to LL. So, overall, LL is already used to deal with “enrollment procedures” for special kinds of developers — this would be just a new one. Residents eager to join “special services” are also reasonably used to a few extra procedures.

“Certification” in this context meant mostly access to a LL-hosted site that accepts, in a trusted form, the avatar login from a certified developer, and gives an upload option (of the SL client binary), emitting a digitally-signed certificate for it, which is tied to that specific client’s checksum

- developer now distributes the certified binary with the digital certificate

- user downloads both, and logs in to SL. At this point, the SL client presents its credentials (the signed certificate) and is checked for validity. If it’s valid, SL will display only content that is flagged as “anybody can view it”; the rest will be invisible (either per parcel, or universally, etc. as per my many suggestions)

So where are the major flaws of this method?

The first problem is how the client sends its checksum (so that on LL’s side, they can check if it’s the same as in the certificate presented to it). As Jacek and others pointed out, there is no way to avoid that a malicious client doesn’t present a fake checksum with a valid certificate. Granted, once LL finds out about that particular certificate, it could revoke it immediately, but Jacek is right: revoking the certificates for LL’s own clients (which would be the prime candidates) would be a mess.

The alternative would, of course, be a release of a closed-source application running on your computer (effectively, a DRM agent) that validates the checksum for the client. This is basically what many applications out there (including Windows, but also almost everything from Adobe or Autodesk) do. Naturally, this would mean that LL would have to develop a DRM agent for all platforms and operating systems, existing and future ones (i.e. if someone ports the SL client for the iPhone, LL would have to develop a DRM agent for the iPhone too). It’s unmanageable. Also, like everybody knows, it can be compromised, too.

I was stumped to find a solution for this issue, and that was the technical argument for not pursuing my idea any further. Granted, you could place the burden on the side of the developer: each developer would create their own DRM mechanism, and hold out “license keys” for each connection. This would work the following way: when logging in, the SL client would contact a developers’ web service and get a license key, signed with a certificate emitted by LL to the developer. Then it would present that license key to LL’s grid servers, who would accept it if they could validate the developers’ signature.

The way how each developer emits licenses would be up to them. They could use a checksum thingy embedded in part of the code that would not be open source, but it would be up to them. LL would simply accept signed license keys, and that would be all. It would be up to the developer to make sure that their license keys were not abused. So it’s really pushing the blame elsewhere. The advantage? Each binary would not be required to be uploaded for validation by LL (they would simply trust the signed license key) and development would never be “stifled” that way. Naturally enough, LL would provide, with their own SL clients, the appropriate DRM agent.

The weak spot would then be on the developers’ side — figuring out a way to prevent their system to be hacked or compromised by a malicious user; because on LL’s side, once a developer starts handing out licenses for malicious use, they’d simply revoke that developer’s certificate, and none of those malicious clients would work.

Pushing the DRM issue on top of open source developers is, however, a hard strain on them :) For the libertarians among them, this would be swallowing a very bitter pill :) And, yes, I also don’t see a way how you could release open sourced code including the DRM code without having it easily subverted by a third party.

The second problem (interception) is, however, impossible to deal with. Due to the Analogue Hole with all digital content, tools like GL Interceptor will always work (even if the cache & stream contents were encrypted, which they’re not). At the very least, textures will always be easy to copy (although once you just have mesh data on the VRAM, I don’t see how you could extract “prim data” from it, meaning that at least objects would be safe).

There are no “technical flaws” with a DRM system (assuming that nobody’s claiming that it’s 100% safe, because it will never be); there is, however, an ideological flaw for some developers, and while I’m fine in discussing technical issues, I’m not interesting to discuss the merits of a proposal that gets a part of the development community itchy because of their ideology, principles, and moral stance regarding DRM. It would be not only unwise, but even unfair, to stubbornly push an issue because of that — it would be like “demanding” that Richard Stallman endorses DRM on the FSF projects because some of them are being used for illegitimate or even illegal purposes. It would be completely worthless — a fight not worth fighting, or rather, not even worth thinking about it. DRM is a dirty word in the open source community, and thus any proposal that mentions it would ultimately fail. That might be the best reason why LL has never ever suggested it in public.

So, I’ll take Jacek’s advice and focus on content theft detection and effective social enforcement instead of “magic tools” to make content theft very hard but ultimately never impossible. And like McCabe so well put it, fortunately, the number of CopyBot sellers and related sites are small, mostly due to the ethical conscience of most developers, who want nothing to do with content theft.

BTW, Dale, my apologies if your comment was deleted by mistake on my blog. Sometimes they go into the spam queue for no particular reason and I press the “delete” button too quickly before realising that there were a valid comments there :( I’m sorry! It doesn’t happen often, but sometimes it does.

Acquiring and keeping cuttlefish is *much* more involved and complicated than keeping a cat or dog. It’s more like keeping a rare tropical fish: you need a properly sized aquarium, which you must clean regularly, with water kept at the right salt level and temperature, and plants and rock structures for them to hide in, etc. And cuttlefish like to hunt their food, so you’d be giving them live, creepy crawly crayfish-like things, not boring old food flakes or pellets. The whole process is not for the faint of heart or people with only casual interest.

But, if after that warning you’re still genuinely interested in having some pet cuttlefish, here’s a good place to get more information:

http://www.thecephalopodpage.org/Sepiabandensis.php

Or if you’re having second thoughts, you can just do what I do: watch cool cuttlefish videos on YouTube! :D

http://www.youtube.com/watch?v=zjycOCyUZ1c