Re: [mmox] Permissions

Jesrad <jesrad@gmail.com> Mon, 23 February 2009 10:10 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 9CE383A6AC4 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 02:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.584
X-Spam-Level:
X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6]
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 2rs7CX6LONfn for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 02:10:00 -0800 (PST)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id E7FEB3A67C1 for <mmox@ietf.org>; Mon, 23 Feb 2009 02:09:59 -0800 (PST)
Received: by fk-out-0910.google.com with SMTP id f33so1448871fkf.5 for <mmox@ietf.org>; Mon, 23 Feb 2009 02:10:15 -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=CUO/sH5rrPl+9zJgGIuLKdgcL7I49IRcU1kj+k4pmEE=; b=VDru4MJwVcEX4ubG0GVUoXt4ic3k1M6YqMqspne+XAP61/cQXNLCufuazGQQXncGbe ACMGXJ2pmzVLIbOOZ9b1ZUX901XlgQYtSz8oxfIyj8iiwyPjbuQHFXFSbVmlAtymNneQ xZgjarcaR/Ke+X049zBrg0yJW7wsrqiv5f2Sg=
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=W/C5wK7lxgPhReM7v//92rO8Rx7RBsVqiYt5NbDT7LGmjZxusXeJncKexAcBSdupyJ gwEjbGTcIkPsCWwEKSw8CPB7Z5CTmsBR7yJqnjoPU4MRcEa5Y2JIdYKSATOioDO0AC4b V0yj54HOiRNLY4cqyy51gR3ExoCDoHqApYZkg=
MIME-Version: 1.0
Received: by 10.180.214.15 with SMTP id m15mr1471846bkg.78.1235383815505; Mon, 23 Feb 2009 02:10:15 -0800 (PST)
In-Reply-To: <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com>
References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com>
Date: Mon, 23 Feb 2009 11:10:15 +0100
Message-ID: <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com>
From: Jesrad <jesrad@gmail.com>
To: Gareth Nelson <gareth@litesim.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] Permissions
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 10:10:01 -0000

> Some people are going to insist on the DRM or not allow their content
> to be transferred at all

And some people like me will insist that there is a way to do it that
cannot be prevented by third-party permissions system like this.

> I am absolutely NOT advocating DRM as a good thing, what I am
> advocating is a system similar to DRM which simply tells you what you
> are legally allowed to do. If you choose to ignore the permissions and
> thus violate the copyright, that is between you and the courts

I disagree. There is a very obvious situation where it is not only
legal to ignore permissions, but also illegal to have such
restrictions in place, and that is precisely the situation I am in
with regards to virtual world content. Where in your proposal do I
have the possibility of restricting further owners from restricting
further owners from copying, transferring, transferring for cash, etc.
? And even if you carve up more specs for this case, then what about
the case where the creator wants to restrict further owner from
restricting further owners from restricting further owners from
copying/selling/giving etc. ?

I hope you see where this is going.

On Mon, Feb 23, 2009 at 10:31 AM, Gareth Nelson <gareth@litesim.com> wrote:
> Some people are going to insist on the DRM or not allow their content
> to be transferred at all, at least if there's a scheme in place like
> this it will reduce headaches (at least until hell freezes over and
> copyright law is overthrown).
> I am absolutely NOT advocating DRM as a good thing, what I am
> advocating is a system similar to DRM which simply tells you what you
> are legally allowed to do. If you choose to ignore the permissions and
> thus violate the copyright, that is between you and the courts, but
> you should at least be able to find out where you stand legally
> without pestering copyright holders every time, and it would help if
> automated systems can aid you.
>
> On Mon, Feb 23, 2009 at 9:18 AM, Jesrad <jesrad@gmail.com> wrote:
>> Imagine for a second that the cross-grid protocol mandate somehow that
>> objects made on one grid be hosted and served to clients from this
>> grid, and not transfered to other grid servers / simulators (though
>> the owner may have the third-party possibility of exporting from one
>> and importing to another so it is hosted multiple times and thus
>> exists in multiple instances).
>>
>> From there any specific policy of "DRM" would purely be a matter of
>> specific grid implementation. I would say that a lot of headaches and
>> flames would be averted, saving us the trouble of directly addressing
>> these matters in the MMOX scope itself and leaving them for
>> grid-caretakers and their own customers to discuss and decide policy
>> about.
>>
>> Please, everyone, let me know what you think of this.
>>
>> On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson <gareth@litesim.com> wrote:
>>> Just been talking to Adam about this and knocked out a very very rough
>>> spec. It may be early in the game to discuss this issue, but it's one
>>> that drives a lot of emotion in people on all sides of the debate.
>>>
>>> So, without further a-do, here's a rough spec for a DSL (Domain
>>> Specific Language) for permissions to discuss (copied and pasted from
>>> my vim session, excuse any formatting weirdness):
>>> Original concept courtesy of Adam Frisby, see
>>> http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/
>>>
>>> Very very rough thinking out loud
>>>
>>> Each asset has a set of metadata fields:
>>>        Author
>>>        Creation timestamp
>>>        Last modified timestamp
>>>        Logs of modifications? (TBD)
>>>
>>> Possible actions:
>>>        Copy
>>>        Modify
>>>        Transfer
>>>        Transfer for cash
>>>
>>> Each action attached to a simple function that returns a boolean value
>>> if action is allowed.
>>> Data types:
>>>        Entity
>>>                Describes a user, organisation, system or network
>>>        Asset
>>>                Describes an asset ;)
>>>        Location
>>>                Describes a virtual location, rather than a physical system
>>>        Time
>>>                Date and time :)
>>>
>>> Entity has these fields:
>>>        Name
>>>        UUID
>>>        Class (person, organisation, system, network)
>>> Optional fields for person entities:
>>>        Agent domain? (TBD)
>>>        System (what system is the user connecting from - may be withheld for
>>> privacy reasons)
>>>        Location (where in the metaverse are they?)
>>> Optional fields for organisation entities:
>>>        Organisation type (nonprofit/commercial/government etc)
>>>        Company type (for corporations: LLC/Ltd/PLC/whatever)
>>>        Address (i.e postal address)
>>>        Technical contact (a person entity!)
>>> Optional fields for system entities:
>>>        Platform
>>>        System hash (hash of various bits of hardware, HD serial and ethernet MAC etc)
>>>        Network
>>>        Current IP address
>>> Optional fields for network entity
>>>        Technical contact (heh, redundant)
>>>        CIDR prefix
>>>
>>> Asset
>>>        Name
>>>        MIME type
>>>        UUID
>>>        Creator
>>>        Creation time
>>>        Last modified time
>>>        Last modified by
>>>
>>> Location
>>>        TBD (Obviously not the SL style Region/x/y/z)
>>>
>>> Time
>>>        You need to ask? ok,
>>>        Day
>>>        Week
>>>        Month
>>>        Year
>>>        Hour
>>>        Minute
>>>        Second
>>>        All integers
>>>
>>> Simple comparision operators to match on what is passed to the functions
>>> !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects
>>>
>>> function prototypes:
>>> copy(Entity src, Location location, Time time, Asset ass)
>>>        src      == the user currently holding the asset who wishes to copy it
>>>        location == the location the requesting user is inhabiting at present
>>>        time     == the time the request was made at (just in case there's
>>> batch processing or serious latency)
>>>        ass      == the asset being copied
>>> modify(Entity modifier, Asset ass, Time time, Location loc)
>>>        modifier == the entity trying to modify
>>>        ass      == the entity they're trying to modify
>>>        time     == the current time
>>>        loc      == where is our modifier while they're trying to modify?
>>> transfer(Entity src, Entity dst, Location loc, Time time, Asset ass)
>>>        Same as copy essentially
>>> sell() is just transfer, but invoked for transfers in exchange for compensation
>>>
>>> The modify() function could probably do with a description (if
>>> possible) of the modification being requested, for example in my own
>>> work i'd want to prohibit modifications to the permissions in order to
>>> enforce the GPL, others may have different requirements.
>>>
>>>
>>> DANGER! DANGER! READ:
>>>        Any system that can be proposed here can only be used to express
>>> intent, it can express that intent very clearly using a DSL as i've
>>> roughly
>>>        spec'ed out above, but it will never be possible to actually
>>> enforce it on systems that do not want to enforce it. I'll note that
>>> personally I
>>>        absolutely hate DRM for the most part, but if it's going to be a
>>> reality it should be done right, and should allow any type of license
>>> to be roughly
>>>        expressed in a way that can be handled by automated systems. If for
>>> no other reason than mere practicality, a decent DSL for specifying
>>> what
>>>        permissions an author of a copyrighted work has granted under
>>> existing copyright law can be useful and saves having to pester the
>>> author.
>>> _______________________________________________
>>> mmox mailing list
>>> mmox@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmox
>>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>