Re: [mmox] Permissions

[Gareth Nelson <[e-mail]>]

You can't actually prevent the remote grid from doing anything once it
has the data, if I accidentally claimed otherwise slap me with a
hypocrite stick.
The idea is that grids CAN enforce it, but the main point is just to
make it possible to know what's allowed.
However, since explained before this issue is much more complex than
it at first appears and goes wildly out of scope, so consider my
initial proposal withdrawn.

On Mon, Feb 23, 2009 at 1:59 PM, Jesrad <[e-mail]> wrote:
> This amounts to an implementation of some DRM, if I understand it
> correctly. Would it be part of the protocol that grids are to
> machine-read it and enforce it ? I would guess so if there is also a
> section of the protocol addressing asset exchange. In this case the
> problem is still more complex than anticipated (how do I restrict next
> owner or next grid from restricting next owner or grid from
> grid-exchanging the asset, etc.)
>
> Nevertheless, the entire issue is avoided by keeping content hosted in
> its original grid, and the renderview being supplied by multiple
> sources (according to the endpoint identity's credentials, if required
> by the source grid implementation). Isn't it ?
>
> On Mon, Feb 23, 2009 at 2:37 PM, Gareth Nelson <[e-mail]> wrote:
>> Well, the "stuff" was generally recogonised by others as being much
>> more complex than my naive ideas on the subject would make it appear
>> for multiple reasons which i'll point you at today's
>> [e-mail] logs for.
>> I would be quite opposed to actually *mandating* any implementation of
>> DRM, as i've said multiple times the idea is to let automated systems
>> know what is allowed - it's up to the implementers of those systems
>> whether they obey the license restrictions or not.
>> The problem i'm trying to solve here is one where you need to manually
>> ask the copyright holder every time you want to move their work to
>> another grid. Making it machine-readable makes it possible to automate
>> things, while a human-readable license does not.
>>
>> On Mon, Feb 23, 2009 at 1:32 PM, Jesrad <[e-mail]> wrote:
>>> OK, but doesn't that just make this "stuff" a form of content, or at
>>> most metadata ? In this case, it might fall off scope anyway.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> 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, maybe it can be later hijacked for a better end user-worthy
>>> purpose, I guess.
>>>
>>> On Mon, Feb 23, 2009 at 1:44 PM, Gareth Nelson <[e-mail]> wrote:
>>>> Well, talking to a few others it seems the general consensus is "make
>>>> a field on assets for all this stuff and make the scheme extensible".
>>>>
>>>> On Mon, Feb 23, 2009 at 10:27 AM, Jesrad <[e-mail]> wrote:
>>>>> Hmm, "it's not gonna enforce IP technically" was not the point I
>>>>> wanted to make. The actual point is: attempting to define a mechanism
>>>>> for signalling what categories of actions are permitted or not under a
>>>>> specific copyright law (which may or may not be applicable depending
>>>>> on national/sovereign context) is a non-starter because of infinite
>>>>> recursion.
>>>>>
>>>>> This is one of the main reasons I suggest curtaining the issue
>>>>> entirely by adopting a multiple-host approach, where content (but not
>>>>> necessarily the MMOX-layer object reference itself) remains hosted on
>>>>> the originating grid and is not replicated between different grids
>>>>> through the cross-grid protocol. The other reason for following such
>>>>> an approach, is that it's the only one compatible with existing P2P
>>>>> VWs like Solipsis.
>>>>>
>>>>> On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson <[e-mail]> wrote:
>>>>>> On Mon, Feb 23, 2009 at 10:10 AM, Jesrad <[e-mail]> 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.
>>>>>>
>>>>>> But that's besides the point, since doing so isn't going to convince
>>>>>> people to allow the content to move AND this system does not in fact
>>>>>> prevent anything, it's a machine-readable version of the license - the
>>>>>> only force comes from compliant systems and users or the courts.
>>>>>>
>>>>> _______________________________________________
>>>>> mmox mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmox
>>>>>
>>>>
>>>
>>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>