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

"dyerbrookme@juno.com" <dyerbrookme@juno.com> Thu, 19 February 2009 06:49 UTC

Return-Path: <dyerbrookme@juno.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C1B3A6A18 for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 22:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkyvkBgCMVhp for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 22:49:14 -0800 (PST)
Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 10A713A6984 for <mmox@ietf.org>; Wed, 18 Feb 2009 22:49:14 -0800 (PST)
X-UOL-TAGLINE: true
Received: from outbound-bu1.vgs.untd.com (webmail04.vgs.untd.com [10.181.12.144]) by smtpout05.vgs.untd.com with SMTP id AABE34AGZA59J5XS for <mmox@ietf.org> (sender <dyerbrookme@juno.com>); Wed, 18 Feb 2009 22:48:55 -0800 (PST)
X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNQRGcstB/kx2B4BP6d7WeEA==
Received: (from dyerbrookme@juno.com) by webmail04.vgs.untd.com (jqueuemail) id N9RBQH3F; Wed, 18 Feb 2009 22:48:08 PST
Received: from [10.181.11.34] by webmail04.vgs.untd.com with HTTP: Thu, 19 Feb 2009 06:47:58 GMT
X-Originating-IP: [10.181.11.34]
Mime-Version: 1.0
From: "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Date: Thu, 19 Feb 2009 06:47:58 +0000
To: mmox@ietf.org
X-Mailer: Webmail Version 4.0
Message-Id: <20090219.014758.23973.0@webmail04.vgs.untd.com>
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Type: text/plain; charset="ISO-8859-1"
X-ContentStamp: 3:5:2244444052
X-MAIL-INFO: 5d83ba77ba3fcfcf87ef0777ef2aaa277b7bbfd7131f0a7b4e4e6f4e8f2b2bda2b3be3fa0ecf877e772e733787beba938b17a31e9a0b5f575fae0f0f8e6eeb576efe0a13dede73abb36a3ade93936393c3b7b702b71ec70e5b0f8e7a5717fb278ee75f3b87cf077e8f7733f7339fbebe7e2aaaf72adf3ab32b2bfb671ababf2b3b3b4e3b2ea7a78aa7ef375be3be7ed3f7cfea137e97331eae270fee
X-UNTD-Peer-Info: 10.181.12.144|webmail04.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 06:49:15 -0000

>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/