[Opensim-dev] Interrelated difficult problems related to asset portability

[Diva Canto]

Interesting idea.
But you don't need to place this in people's viewers. The viewer would incur
in a big performance penalty to correlate assets. 

However, what you're proposing suggests a monitoring system that could be
achieved by other means, for example, by using libsl to develop a system
specifically designed for detecting asset clones. (Clone detection is a cool
nerdy thing to do for lots of purposes :-)

In other words, there's an opportunity for developing crawlers that roam
around looking for specific items that people want to protect. It would be
the good twin sister of copybot, let's call it copyrightbot :-) 

This monitoring can be done on the web too, but I guess people don't bother
to do it. In virtual worlds, they might bother to do it, because there may
be people willing to pay. Maybe. There's certainly a [small] market for
clone detection in source code and other artifacts that are time-consuming
to produce.

Yeah, this might be a reasonable way of addressing this issue. Much more
doable than DRM. 

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Kyle Hamilton
Sent: Thursday, May 22, 2008 5:40 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Interrelated difficult problems related to asset
portability

The idea is basically an outgrowth of the "many eyes make bugs
shallow" concept... since viewers/clients are the ones that actually
get the data to display (assetservers stream to regionservers, which
stream to viewers), the viewers are the ones in the perfect position
to identify infringements.

If the same asset data shows up in two different places under two
different UUIDs, a client that has seen both will know it.  If
metadata is available for those UUIDs (including 'if you see a
duplicate, please send the UUID and the region you're connected to, as
well as the hashes that you know how to generate on the data, to this
URL' squawker addresses), then the client can simply notify all
squawker addresses associated with all the UUIDs and grid/locations of
the duplicate asset data.

Some of this will be licensed use.  Some will not be.  However, it
makes it possible for copyright owners to know where things are, and
determine if it's worth sending a C&D or filing a full lawsuit over.
(i.e., it makes it much more possible for the copyright owner to
determine when his/her rights have been infringed, which makes it
possible to use pre-DMCA copyright contours to litigate/enjoin/recover
from.)

It relies on code being put into the viewer.
It relies on code being put into the server.
It relies on additional fields being put into the inventoryserver.
It relies on modification of the asset-retrieval protocol.

It can't really happen without the cooperation of Linden, because
Linden writes and distributes the official viewer.  Most people don't
compile their own viewers, so the 'official' viewer (with the squawker
behavior compiled in) becomes the default, and when someone who uses
the official viewer goes to a private grid where there's a lot of
infringement going on it all comes out.

It also can't detect non-bit-perfect copies.  (unless, say, animation
data was parsed and then deparsed, and the hashing done on the
deparsed rendition of the data.  But that ignores the ideas of the
primitives and the textures involved.)  This is, by the by, why DRM is
very bad for this scheme -- if two people unwrap DRMed data via the
analog hole, it's not going to be a bit-perfect copy.

But regardless, there's additional things that can be done with this
idea -- such as Google or other content indexers, squawking on content
they see multiple times at multiple URIs.

And in any case, it's certainly a lot more than we've got now.

-Kyle H

On Thu, May 22, 2008 at 5:12 PM, dan miller <danbmil99 at yahoo.com> wrote:
>> Next, the problem of asset ownership.  DRM is a long, dark,
>> ugly road
>> to nowhere; however, this does not mean that nothing can be
>> done.  I have an idea
> ...
>> I'll be writing another email on this.
>
> do tell!
>
> -danx0r
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev