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

"dyerbrookme@juno.com" <dyerbrookme@juno.com> Mon, 23 February 2009 14:38 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 114283A69B1 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 06:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level:
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.236, 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 LIKnoE3GKu1a for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 06:38:35 -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 2762D3A6802 for <mmox@ietf.org>; Mon, 23 Feb 2009 06:38:35 -0800 (PST)
X-UOL-TAGLINE: true
Received: from outbound-bu1.vgs.untd.com (webmail05.vgs.untd.com [10.181.12.145]) by smtpout04.vgs.untd.com with SMTP id AABE4FPHGABF84A2 for <mmox@ietf.org> (sender <dyerbrookme@juno.com>); Mon, 23 Feb 2009 06:38:30 -0800 (PST)
X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNytwfAH1WVBr7CyLcWfT7/w==
Received: (from dyerbrookme@juno.com) by webmail05.vgs.untd.com (jqueuemail) id N94F673M; Mon, 23 Feb 2009 06:37:43 PST
Received: from [68.161.198.3] by webmail05.vgs.untd.com with HTTP: Mon, 23 Feb 2009 14:36:58 GMT
X-Originating-IP: [68.161.198.3]
Mime-Version: 1.0
From: "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Date: Mon, 23 Feb 2009 14:36:58 +0000
To: jesrad@gmail.com
X-Mailer: Webmail Version 4.0
Message-Id: <20090223.093658.9303.0@webmail05.vgs.untd.com>
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Type: text/plain; charset="ISO-8859-1"
X-ContentStamp: 6:3:3586795210
X-UNTD-Peer-Info: 10.181.12.145|webmail05.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com
Cc: mmox@ietf.org, dyerbrookme@juno.com
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111
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: Mon, 23 Feb 2009 14:38:36 -0000

>Trustworthiness of a given grid is better left to the full
appreciation of the grid caretaker because there is no way to make an
automatic validation of the DRM implementation in some distant machine
(but that's really the most basic reason of all), so the entire debate
about what constitutes a trusted grid or not WRT copyright is out of
scope.

Well, there's lots of things you can't reach out and confirm on a remote machine, but hey, interoperability isn't an extension of the Wild West, is it? It should be a regime of standards, not un-standards. If there wasn't the allergy to DRM in advance as something evil music companies impose on people who want to rip music for a variety of their gadgets or friends, then there might be more breadth of perception about this matter and the need for *diversity and choice*.

DRM implementation may well be the basis for a system to determine trustworthyness. Why not? Nothing but ideology to stop you there.

>I actually wrote that mandating the implementation of DRM on top of
any permission/copyright metadata transmission mechanism would severly
reduce the number of grid systems that comply with the protocol.

No, you said not to stream the permission at all, that it would take up resources, that it shouldn't be streamed if you can't mandate DRM within the streaming process. Why not let that be up to the participating grids that want to mandate DRM? Why preclude that option from them at the dawn of interoperability among virtual worlds? Again, no reason, but an ideological one.

>I earn significant money from making full-perm content in Second Life,
so these assertions sound empty to me. I'm also a fiercely
individualistic capitalist (of the jusnaturalist kind), but you do not
have to believe me.

Again, this is an *ideology* and a belief about *a* type of commerce but isn't a scientific fact for all types of commerce just because they are e-commerce. E-commerce doesn't become opensource e-collectivism just because you say so. The e-commerce in interoperable virtuals worlds shouldn't be hobbled in advance because of some ardent ideological belief in Kevin Kelly's "8 Generatives" as the only option for digital content. Someone "making their living off full-perm items" is a) making a living off "obfuscation," i.e. the script or code or item is so complex, that it needs to have consulting services sold on top of it, even if it is "free and open source" or b) making a living from customization which is very much of a niche market and cannot be conceived as a solution for all commerce or c) putting out a tip jar. CC is basically the putting out of a tip jar at best, and a collectivist induced share at worst. It's not a robust permissions regime with copyright enabled for commerce on the basis of original continent, which should definitely be a choice in advance for the metaverse, not precluded, and not merely added on as a module.


____________________________________________________________
Need cash? Click to get a cash advance.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFRKCJy0PLklxCTx1v0QHf147OxPFPhZM7jLy0Btr8dokukPABky8/