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

Jesrad <jesrad@gmail.com> Mon, 23 February 2009 14:12 UTC

Return-Path: <jesrad@gmail.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 D89F53A684D for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 06:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
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 gkCo4XthEL1a for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 06:12:53 -0800 (PST)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id CECCE3A67EC for <mmox@ietf.org>; Mon, 23 Feb 2009 06:12:52 -0800 (PST)
Received: by fk-out-0910.google.com with SMTP id f33so1498170fkf.5 for <mmox@ietf.org>; Mon, 23 Feb 2009 06:13:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/JVeafez99ekzCqiR4bqOoRcNXRx2l4ytv1VckiN+mE=; b=ZCWxlLhrZyoNQQ6j1u0Fm7dO0fdK8hCnQoAmKYA2xTPPvrHxmGjiiUPOZ33fg/D/wV 2DlU0ZRXPf7kTRjDKY2fUn5/ciRRqwbqqwpAHCVgsAecOMvJoDdZYX6WLDyXJhYEFlVA W7nrpobfhLzzA3rY3FHG65BKTbcqLKlkdxfz8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YJY/R+uzAC4wnPLyiC4Q1Uai7wXi/XSwLS/tj1tK/rCOkxRvQ2RkM32VMLnW8gx00z vLD8h90JBiPXrzIKnUMci/B0WgM/7Cgx9T57VGr/WDMmBqYieBXz1ToUbWElxxN00L2F LB77lI1m+yeRtWnY1Q+ndUgprKtvpuURkh4wk=
MIME-Version: 1.0
Received: by 10.181.58.9 with SMTP id l9mr1531961bkk.214.1235398389097; Mon, 23 Feb 2009 06:13:09 -0800 (PST)
In-Reply-To: <20090223.084454.24252.0@webmail09.vgs.untd.com>
References: <20090223.084454.24252.0@webmail09.vgs.untd.com>
Date: Mon, 23 Feb 2009 15:13:09 +0100
Message-ID: <53cd6c2e0902230613y6e86f16fyaa841a08db4b86d1@mail.gmail.com>
From: Jesrad <jesrad@gmail.com>
To: "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: mmox@ietf.org
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:12:58 -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.

> I'm glad to hear you confirm, however, what others in OpenSim keep denying, mainly that to transmit metadata about permissions in fact "reduces greatly the possibility of interoperability with OpenGrid.

This is not what I wrote.

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.

> CC is not an economy and not commerce; it's a browbeating to give your content away for free in exchange for name credit only. It is not the foundation for a micropayments scheme.

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.

On Mon, Feb 23, 2009 at 2:44 PM, dyerbrookme@juno.com
<dyerbrookme@juno.com> wrote:
>>Even if it is recognized by consensus as a valid form of data to be
> exchanged between grids, which is reasonable when presented in this
> way, the twin problems of relevance WRT the domestic legal context and
> of relevance WRT the actual implementation of any DRM in the target
> grid make this sort of data irrelevant when it can be entirely
> superseded by any other form of user content associated to the object
> (like, say, a CC license notecard as in SL, or a simple copyright
> notice).
>
> Extraordinary reluctance to transmit information given the usual value of opensource to want information to be free and to move unhindered across frontiers!
>
> Putting a CC license notecard *is not sufficient*. CC is not an economy and not commerce; it's a browbeating to give your content away for free in exchange for name credit only. It is not the foundation for a micropayments scheme. Notecards can also get lost or removed.
>
> If the permissions information is transmitted, and the TOS of the sending platform includes within the concept of trustworthiness that such permissions information must be implemented, then you have a very good ready-made regime for proving trustworthiness.
>
>>To put it differently: if we do not mandate any implementation of DRM
> per protocol specifications, then this sort of data is purely
> "client-side" and is better left to the resident/player-creator to
> make and include in the concerned object. And if we do mandate DRM
> implementation, then this implementation ifalls short of the diversity
> of legal contexts (for example fair-use cases, which vary widely
> between jurisdictions), breaks some models (like mine), and reduces
> greatly the possibility of interoperability with a number of existing
> VWs like the OpenGrid or (AFAIK) Solipsis.
>
> Transmitting metadata about permissions doesn't "fall short" of diversity. It creates the bedrock of diversity for an economy that is based on capitalist commerce and not only on collectivist "sharing" and *that* is what enables diversity.
>
> I'm glad to hear you confirm, however, what others in OpenSim keep denying, mainly that to transmit metadata about permissions in fact "reduces greatly the possibility of interoperability with OpenGrid. Now why is that? Interoperability should give choices of systems, not take them away.
>
> "Fair use" might need some updating or contextual examination and shouldn't be invoked casually merely to defeat commerce. In a virtual world, just because the platform providers already stream all the content, you already have your fair use, and so does everybody else who would like to see an object "for reference"! If you buy a skin or table, it renders for you -- what more "fair use" would you need when the entire thing renders for you always and everywhere, in your copy? If you've rezzed it out or are wearing it, everybody sees the full copy already lol. No, invocation of "fair use" here, as if stopping copyright theft in a VW would hobble fair use seems out of place and out of date.
>
>>If you insist that there is space for this sort of metadata and the
> protocol does not mandate DRM implementation for the server-side to
> enforce, then I can live with it. But I'll still think it a waste of
> resources.
>
> Well, why can't it mandate DRM implementation as a condition of trustworthiness? And...why does the mere passage of information "waste resources"? Tons of data is transmitted, what, you can't spare a few bytes for c/m/t?
>
> ____________________________________________________________
> Click for online loan, fast & no lender fee, approval today
> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIpd4J1s4V5InglOtuqIfdBHGtUTsTbf6ji5kG7PYZqO10VzCMgHu/
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>