Re: [mmox] Permissions

Gareth Nelson <gareth@litesim.com> Mon, 23 February 2009 10:17 UTC

Return-Path: <gareth@litesim.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 C9BD13A6874 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 02:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.852
X-Spam-Level:
X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rkIEX8IOlh6E for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 02:17:23 -0800 (PST)
Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.157]) by core3.amsl.com (Postfix) with ESMTP id 76EBF3A67C1 for <mmox@ietf.org>; Mon, 23 Feb 2009 02:17:23 -0800 (PST)
Received: by po-out-1718.google.com with SMTP id b23so6465094poe.4 for <mmox@ietf.org>; Mon, 23 Feb 2009 02:17:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.151.18 with SMTP id d18mr1969919rvo.134.1235384260035; Mon, 23 Feb 2009 02:17:40 -0800 (PST)
In-Reply-To: <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com>
References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com>
Date: Mon, 23 Feb 2009 10:17:40 +0000
Message-ID: <61dbdd7d0902230217s4ec01b1y48eb5a55d536917b@mail.gmail.com>
From: Gareth Nelson <gareth@litesim.com>
To: Jesrad <jesrad@gmail.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:17:24 -0000

"Where in your proposal do I
have the possibility of restricting further owners from restricting
further owners from copying, transferring, transferring for cash, etc.
?"

That is precisely one of my own reasons for wanting a more flexible
system. I know if I release anything under the GPL on SL, people will
go and modify it remove the permissions without a second thought.
Basically, i'm trying to define the things restricted by copyright
law, and then tie them to functions saying whether the author has said
"you're allowed to do this" or "you're not allowed to do this".
Basically, a way for automated systems to do what requires human
intervention right now - humans have to pester copyright holders or
interpret the license document.

Whether or not you actually OBEY the license is up to you and the
relevant legal authorities.

On Mon, Feb 23, 2009 at 10:10 AM, Jesrad <jesrad@gmail.com> wrote:
>> 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
>>>
>>
>