Re: [mmox] Permissions

[Gareth Nelson <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmox
>>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>