Subject: Re: [mmox] mmox Digest, Vol 1, Issue 71

From: "[email-masked]" <[email-masked]>
Date: Sat, 21 Feb 2009 07:06:09 GMT

>You seem to be having a beef with Linden Labs. It seems like you don't trust Linden Labs to actually enforce any policy that would be specified in an interoperability standard. Surely there are more appropriate forums for you to discuss these Second Life specific 
things with Linden Labs people.

There is only one Linden Lab, it's not "Linden Labs" -- not yet, anyway.

It's not about any "beef" with LL or any "trust". These are generic issues. If you do not require of each and every interoperability partner or candidate that they follow a minimal set of rules, like implementing c/m/t, then the sender cannot expect that the receiver will feel any restraint whatsoever. If another grid strips out c/m/t or doesn't implement it, sending the object into that environment then seems irresponsible, and it's not specific, it's a generic issue. It's merely that there are now practical examples of this as you can see from this discussion around the opensourcing of the viewer, the hacking up of the viewer to use it to grief, the blocking of log-ons of the viewer, etc.

http://foo.secondlifeherald.com/slh/2009/02/open-life-users-banned-from-second-life.html

>I think a rule of thumb for /this particular list/ should be that if the issue discussed is not applicable at least to eight different technology vendors (for example: 
Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life and OpenSim), then it doesn't belong on this list.

This seems arbitrary, and I think the generic issue remains: will the technology vendors, in their push toward interoperability, respect technical implementations of IP or not, or will they cast it aside as an impossible DRM scheme they are unable or unwilling to implement. This is an important issue to decide early on, now that the cart is before the horse anyway, so that the public can understand sooner rather than later what is likely going to happen to their IP.

>I believe I have clearly stated that it is my position that all content should contain metadata, and one piece of that metadata is copy/reuse/cache/storage rights. The specific forms of those copy/reuse/cache/storage may be c/m/t, or more likely something a little 
richer to cater for situations like copylefted content that has "sticky" semantics.

Are you or are you not for having that metadata not just signalled as an intent, but implemented as a technical, engineering solution on the receiving grid? And it seems to me that for any "copylefted sticky semantics" you already have: c/

Prokofy Neva

____________________________________________________________
Shop and compare the best deals on fruit. Act now!
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFWpKSPl6hH6rVlAcoWiqWrVMHpuvTqfUvld3o6WPZI8iSjdodNBh/

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 01:33:23 -0800

okay.

let me be clear.

if you are upset that a particular second life account was terminated  
for non payment of fees, this is an issue you need to bring up with  
linden lab, not this list.

this is a forum for the technical discussion of the development of  
interoperability protocols for virtual worlds.

please take the discussion of linden's policies elsewhere.

thank you

On Feb 20, 2009, at 11:06 PM, [email-masked] wrote:

>> You seem to be having a beef with Linden Labs. It seems like you  
>> don't trust Linden Labs to actually enforce any policy that would  
>> be specified in an interoperability standard. Surely there are more  
>> appropriate forums for you to discuss these Second Life specific
> It's not about any "beef" with LL or any "trust". These are generic  
> issues. If you do not require of each and every interoperability  
> partner or candidate that they follow a minimal set of rules, like  
> implementing c/m/t, then the sender cannot expect that the receiver  
> will feel any restraint whatsoever. If another grid strips out c/m/t  
> or doesn't implement it, sending the object into that environment  
> then seems irresponsible, and it's not specific, it's a generic  
> issue. It's merely that there are now practical examples of this as  
> you can see from this discussion around the opensourcing of the  
> viewer, the hacking up of the viewer to use it to grief, the  
> blocking of log-ons of the viewer, etc.
>
>> I think a rule of thumb for /this particular list/ should be that  
>> if the issue discussed is not applicable at least to eight  
>> different technology vendors (for example:
> Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life  
> and OpenSim), then it doesn't belong on this list.
>
> This seems arbitrary, and I think the generic issue remains: will  
> the technology vendors, in their push toward interoperability,  
> respect technical implementations of IP or not, or will they cast it  
> aside as an impossible DRM scheme they are unable or unwilling to  
> implement. This is an important issue to decide early on, now that  
> the cart is before the horse anyway, so that the public can  
> understand sooner rather than later what is likely going to happen  
> to their IP.
>
>> I believe I have clearly stated that it is my position that all  
>> content should contain metadata, and one piece of that metadata is  
>> copy/reuse/cache/storage rights. The specific forms of those copy/ 
>> reuse/cache/storage may be c/m/t, or more likely something a little
> Are you or are you not for having that metadata not just signalled  
> as an intent, but implemented as a technical, engineering solution  
> on the receiving grid? And it seems to me that for any "copylefted  
> sticky semantics" you already have: c/
>
> Prokofy Neva
>
>
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 10:28:46 -0800

> There is only one Linden Lab, it's not "Linden Labs" -- not yet, anyway.

Sorry, I didn't include the possessive apostrophe: "Linden Lab's people."
I submit that English is not my first language, and ask for your 
forgiveness for this lapse.

> It's not about any "beef" with LL or any "trust". These are generic issues. If you do not require of each and every interoperability partner or candidate that they follow a minimal set of rules, like implementing c/m/t, then the sender cannot expect that the receiver will feel any restraint whatsoever. If another grid strips out c/m/t or doesn't implement it, 

Do you understand that the IETF has no civil or criminal enforcement power?

We, as a standards community, can specify the mechanism, and the 
intended semantics. Whether a particular implementer chooses to 
implement those or not is beyond the control of any of us individually. 
It seems to me that you're asking for something that simply can't be 
guaranteed, barring action of Congress (and, evenso, that only affects 
the US, not the other 95% of the world).

> This seems arbitrary, and I think the generic issue remains: will the technology vendors, in their push toward interoperability, respect technical implementations of IP or not, or will they cast it…

I can't predict the future, so I cannot answer that question. I can, 
however, say that carrying metadata (including usage rights) with 
content is something I want to see in the specification. Another thing 
that might be useful would be a negotiated trust up front: a system can 
tell another system what kinds of licenses it is prepared to enforce, so 
that an "unrestricted" system would say "I won't enforce proprietary 
licenses, so don't send any of that." This would be useful, because it 
allows the source system to avoid sending data that would be discarded 
on the other end.

However, there is nothing that prevents a malicious or ignorant system 
provider from telling lies. If strong IP protection is important to a 
particular user, then that user will likely gravitate towards a service 
provider that, say, implements a certification scheme for each system it 
decides to interoperate with. This is a business and market decision, 
not something you can solve technically.

> Are you or are you not for having that metadata not just signalled as an intent, but implemented as a technical, engineering solution on the receiving grid? And it seems to me that for any "copylef…

Any system that I personally implement will respect the capabilities. 
Unfortunately, there are other people in the world who will implement 
systems -- most of whom are not even on this mailing list. I can't speak 
for them.

It is my understanding that "c/" just says it can be copied; it doesn't 
say that "if you make a copy, you have to make your copy follow the same 
copyleft license."

Look at how SourceForge lets you choose one of many licenses, with 
subtly different semantics, for any SourceForge project you own. I'm 
imagining something similar, where degrees of left-ism and right-ism are 
enumerated, and the content creator makes a determination at the point 
of object creation. There are many dimensions here: Attribution, 
Modification, Moral Rights, Stickiness, Restriction, Use, Sale, ...

Sincerely,

jw