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

From: "[email-masked]" <[email-masked]>
Date: Thu, 19 Feb 2009 06:47:58 GMT

>If, for some reason, the sharing of content through interoperability is against someone's wishes as a creator, then I would assume that some platforms would implement platform-specific means to prevent content from being shared over the interoperability channel, and users who cared about interoperability would choose not to purchase that content. Creators would then choose their platform, and their specific use of that platform, according to how they feel would best serve their interests. I don't think that needs to be mandated in an 
interoperability specification.

Jon, let's start with the fact that "interoperability" is not a goal being driven by the actual masses of users of SL and other virtual worlds, broadly speaking, who are not even informed of the IP and social/political issues involved. Nor, narrowly speaking, is it a goal of the content-creators of Second Life. They haven't gotten to decide whether they want "interoperability" (which has its extreme points of view already articulated here on this last) or not. They haven't gotten to have an opt-out or an opt-in. It is a matter being decided by a handful of people at Linden Lab, IBM, OpenSim, and various members of the "Architectural Working Group" who have shown up to take over the topic. There is no broad user demand for interoperability; it is a concoction.

So in that forced-march context, you have to look at what you are saying here. What platform-specific means to prevent content from being shared would be implemented in OpenSim, which has no intention of implementing the copy/mod/transfer regime of Second Life? It seems a contradiction in terms to expect that a platform eagerly seeking interoperability with another platform is then going to introduce "platform-specific means to prevent content from being shared.

At one point, some AWG members introduced a JIRA (feature proposal wiki) motion to have a check-off box on SL-made objects offering consent or non-consent for an object to travel to other grids. There was a heated discussion about this and the author withdrew the proposal, regrettably:
http://jira.secondlife.com/browse/MISC-1272

There then followed a recasting of the matter as a call for policy clarification that in fact we've never gotten:
http://jira.secondlife.com/browse/MISC-1277

therefore prompting my JIRA asking that interoperability not be taken to the IETF where it will not face a democratic vote of stakeholders:
http://jira.secondlife.com/browse/MISC-2313

You're also suggesting that users who "care about interoperability" should "choose not to purchase that content" -- i.e. you're essentially demanding that creators share their content into grids that do not protect their IP, or face boycotts if they don't go along with this forced march. What's that all about?

By *not* mandating the terms of copy/mod/transfer (or not) into the object transferring across grids, you have in fact copylefted the object by default. *Not* mandating is in fact mandating. You've also set up a social dynamic whereby you've created a false paradigm: if a creator refuses to go along with the interoperability mandate and refuses to free his content for endless copying, he is seen as "not progressive" or "not cooperative" or "not evolving into the future" (Creative Commons follows much the same logic, making it possible to opt for a license to offer your creations to be copied for credit, but not opt for a license to copy for cash, and urging everyone to give away content for free, and not making a mechanism to get paid for content, i.e. integrating micropayments with content distribution as SL does).

I fail to see why you can't add the checkoff boxes copy/mod/transfer when implementing interoperability. Why do you oppose it? We all get that hackers can get around such regimes. So what? It's a serviceable deterrent and an eminently simple and effective marker of intent. A trusted grid *is* a grid that can uphold copy/mod/transfer both as a marker and as a coded implementation that at least deters theft. No one expects a 100 percent implementation.

I'd also like the Lindens on this list to speak up about why they would not uphold copy/mod/transfer as an inherent, coded, non-negotiable implemented feature of interoperability with other worlds. If they fail to do that, then they need to explain why they continue to uphold it in their own world. If it is good enough for Second Life, why is it not good enough for the Metaverse? If it is no good for the Metaverse, why is it being upheld in Second Life?

Prokofy Neva

____________________________________________________________
Receive quick, concrete numbers on your VA mortgage benefits.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIqrtYcr4kM3HgKIvVna5gT7JKRNrVjPD6pKVML0pUCN3LvLlSvkb/

---

From: Jesrad <[email-masked]>
Date: Thu, 19 Feb 2009 11:57:47 +0100

Just a few remarks:

> http://jira.secondlife.com/browse/MISC-1272

I expect that interoperability/conversion of content from one grid to
the other will be limited by technical constraints so it won't apply
broadly and suddenly, but the point remains that some way to prevent
that conversion on behalf of the owner of it should exist. Though here
we disagree philosophically on exactly who this owner is and how,
that's something I can fully get behind. I certainly wouldn't like it
if my newest model of airship was disclosed with full-permissions and
copied over to a third-party sim simply because someone from the
OpenGrid TPed to my sim and had a look (that includes looking through
a sim border) while I was working on it.

> You're also suggesting that users who "care about interoperability" should "choose not to purchase that content" -- i.e. you're essentially demanding that creators share their content into grids th…

I think this was more a statement of fact than one of ideological
position, really. The resident chooses what client software runs on
his/her machine and how, it cannot be trusted to respect
legal/contractual bounds by technique, and that's got nothing to do
with how the server software works - and the point here I think is
that the same applies to server operation with regards to
interoperability protocol. This is akin to international agreements
between sovereign states: neither side has the authority to reasonably
enforce them over the other. And merely stating that they should
ideally limit themselves to bounds they are eager to respect is not
the same as saying that all international agreements are to be
considered void from the get-go.

That said, yes, welcoming visitors from third-party grids and selling
them things, that should be and remain the resident's ultimate choice.
But that's an implementation detail for LL to build into their code,
so it's probably out of the scope of this discussion list.

> (Creative Commons follows much the same logic, making it possible to opt for a license to offer your creations to be copied for credit, but not opt for a license to copy for cash, and urging everyone to give away content for free, and not making a mechanism to get paid for content, i.e. integrating micropayments with content distribution as SL does).

I'm not sure what you mean here by "mechanism to get paid for
content". For months already I've been getting paid as an independant
content provider in SL for creating full-perm works. I have the exact
opposite claim to yours: my CC-like license cannot be enforced
correctly due to the permissions system in SL, and that's disrupting
my trade to a fortunately small extent, whenever someone buys stuff
from me then slaps restrictions on it that are illegitimate. To me the
permissions system is hampering the rights-model that I'm becoming
reliant on for earning a living (fortunately the model is robust
enough to severly limit this hampering), and I wish I could "opt-out"
my works from the permissions system to fix that.

---

From: Morgaine <[email-masked]>
Date: Thu, 19 Feb 2009 14:05:41 +0000

On Thu, Feb 19, 2009 at 10:57 AM, Jesrad <[email-masked]> wrote:

For months already I've been getting paid as an independant
> reliant on for earning a living

That is very insightful, and shows just how hard this area really is.

I think we may have to examine permissions propagation from first
principles.  A mechanism that doesn't work properly within even a single
domain is clearly not the right one to endorse across multiple domains.

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 13:33:29 -0800

[email-masked] wrote:
> decided by a handful of people at Linden Lab, IBM, OpenSim, and various members of the "Architectural Working Group" who have shown up to take over the topic. There is no broad user demand for interoperability; it is a concoction.
>
>   

However, we do have customers who are asking for interoperability, and 
are prepared to pay for it. That's why I'm here. If you're thinking of 
interoperability only in the sense of the Second Life grid, using Second 
Life protocols, serving Second Life customers, I don't think that's 
something the IETF should care much about.

> So in that forced-march context, you have to look at what you are saying here. What platform-specific means to prevent content from being shared would be implemented in OpenSim, which has no intent…

As I said, that's up to each platform vendor. The important thing is to 
enable the metadata to travel with the content, and to empower the 
sending side to make determinations about:
a) who they interoperate with
b) what specific content will and won't interoperate
based on local policy. How Linden Labs decides to apply policy to 
content created by Linden Lab users is totally separate from how the 
interoperability specification should treat interoperable content, and 
should not be subject of discussion on this list (just like I won't 
discuss my customer specifics on this list).

> I fail to see why you can't add the checkoff boxes copy/mod/transfer when implementing interoperability. Why do you oppose it? We all get that hackers can get around such regimes. 

I think you have misunderstood my proposal. My proposal is that the copy 
semantics should be explicitly part of the metadata, and should be 
enforced on the sending side, according to the EULA of that sending 
side. If an object is marked "do not copy" then the sending side won't 
send it, and the object won't interoperate. Exactly how each producer 
implements that is beside the scope of any standard, though. For 
example, if Linden Labs decides to apply a default policy of 
"interoperable" to all existing content, or to apply a default policy of 
"not interoperable," is entirely outside of the scope of any standard or 
standards discussion. It's a Linden-specific matter.

In fact, I am arguing that we should enable exactly what you're 
describing! I don't understand how you belive I'm not.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Thu, 19 Feb 2009 14:54:36 -0700

Jon Watte wrote:
>> decided by a handful of people at Linden Lab, IBM, OpenSim, and 
>> various members of the "Architectural Working Group" who have shown 
>> up to take over the topic. There is no broad user demand for 
>> interoperability; it is a concoction.
>>
>>   
>
> interoperability only in the sense of the Second Life grid, using 
> Second Life protocols, serving Second Life customers, I don't think 
> that's something the IETF should care much about.
>
>> So in that forced-march context, you have to look at what you are 
>> saying here. What platform-specific means to prevent content from 
>> being shared would be implemented in OpenSim, which has no intention 
>> of implementing the copy/mod/transfer regime of Second Life? It seems 
>> a contradiction in terms to expect that a platform eagerly seeking 
>> interoperability with another platform is then going to introduce 
>> "platform-specific means to prevent content from being shared.
>>
>>   
>
> As I said, that's up to each platform vendor. The important thing is 
> to enable the metadata to travel with the content, and to empower the 
>> I fail to see why you can't add the checkoff boxes copy/mod/transfer 
>> when implementing interoperability. Why do you oppose it? We all get 
>> that hackers can get around such regimes. 
>
> I think you have misunderstood my proposal. My proposal is that the 
> copy semantics should be explicitly part of the metadata, and should 
> be enforced on the sending side, according to the EULA of that sending 
> "interoperable" to all existing content, or to apply a default policy 
> of "not interoperable," is entirely outside of the scope of any 
> standard or standards discussion. It's a Linden-specific matter.
>

The proposed meta-data for OGP has never been made explicit. All LL has 
said is that they won't violate the existing TOS for intellectual 
property and won't create a system to support the violation for existing 
IP. What future agreements/TOS/IPR LL will use aren't public knowledge.

We've been debating which is the "next step" for OGP interop after 
getting something roughly looking like a permanent identity after 
teleporting between grids. We hit upon 2 main features: appearance and 
Instant Messaging between worlds, especially of the group variety. 
Trying to implement a SL-style group IM for 84,000 concurrent users  has 
proven to be very difficult for LL, almost impossible. Evoking similar 
behavior (or even remotely similar) for avatars in a collection of 
hundreds or thousands of virtual worlds, is beyond comprehension at this 
point.

Consistent appearance between worlds is merely a technical detail by 
comparison, and there are many obvious approaches to solving it (whether 
they are workable or not is another question, of course)

Lawson