Subject: Re: [mmox] Permissions (Gareth Nelson)

From: William George <[email-masked]>
Date: Mon, 23 Feb 2009 15:25:53 -0500

Nice first step, but it's not clear how this would handle composite objects:
objects that have two different creators and/or permissions settings. The SL
convention of using the root prim's permission for the entire object leads
to restrictions concerning the reuse of "no mod" sub assemblies in a larger
assemblies.

---

From: Gareth Nelson <[email-masked]>
Date: Tue, 24 Feb 2009 06:40:49 +0000

Essentially, you'd need to look at each sub-component and then
evaluate what the restrictions are, applying the restrictions on
sub-components to the collected whole (since they're part of the
whole).

Or you could ignore it. Ask your own sense of ethics and your lawyer
what the right thing to do is.

I'll restate again that this proposal was NOT aimed at a solid
implementation of something which can actually be enforced, but as a
very expressive means of indicating the license terms in a
machine-readable form. Following discussions, it appears that the
general attitude is that there is other previous work in this area so
i've actually withdrawn my proposal.

On Mon, Feb 23, 2009 at 8:25 PM, William George
<[email-masked]> wrote:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 23:49:03 -0800

> what the right thing to do is.

I believe that we can, and should, enable the metadata that allows 
service providers to provide strong DRM. This means that the acceptable 
DRM scheme/schemes must be identified in the metadata, and a provider 
can then choose not to provide a resource to some peer that has not 
signed on to that DRM scheme. The actual mechanics of how the service 
verifies that the peer is signed on to that same scheme does not need to 
be treated by the standard; that's up to each DRM provider to figure out.

If we do that, then the DRM worlds and the open worlds will be able to 
compete for the favor of the content creators and the users. Creators 
who don't like the open practices of some open provider, will simply 
gravitate towards the protected practices provided by the protected 
providers, and vice versa.

Meanwhile, I think that the set of bits we've identified 
(view/copy/use/transfer/modify/derive) and the semantics for each bit 
(allow-change, deny, allow-once and allow-always) could and should be 
part of a required minimum schema -- i e, the service providers will 
publish what they attempt to enforce, and incompatible semantics means 
that no transfer of assets happen. That's just common sense.

Note that this doesn't require the open grids to do or understand about 
DRM, or even to protect anything, for the benefit of their users. 
Meanwhile, it allows those who want to operate 
protected-but-interoperable grids to do so, for the benefit of their 
creators. Everybody wins.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Tue, 24 Feb 2009 07:59:45 +0000

"Strong DRM" of the kind that involves silly schemes such as sending
the content in an encrypted form AND the encryption key should not be
part of any standard. "Machine-readable licenses" are a reasonable
thing, and this can all be lumped into a field in the metadata.

On Tue, Feb 24, 2009 at 7:49 AM, Jon Watte <[email-masked]> wrote:
> I believe that we can, and should, enable the metadata that allows service
> providers to provide strong DRM. This means that the acceptable DRM
> scheme/schemes must be identified in the metadata, and a provider can then
> choose not to provide a resource to some peer that has not signed on to that
> DRM scheme. The actual mechanics of how the service verifies that the peer
> is signed on to that same scheme does not need to be treated by the
> standard; that's up to each DRM provider to figure out.
>
> compete for the favor of the content creators and the users. Creators who
> don't like the open practices of some open provider, will simply gravitate
> towards the protected practices provided by the protected providers, and
> vice versa.
>
> (allow-change, deny, allow-once and allow-always) could and should be part
> of a required minimum schema -- i e, the service providers will publish what
> they attempt to enforce, and incompatible semantics means that no transfer
> of assets happen. That's just common sense.
>
> Note that this doesn't require the open grids to do or understand about DRM,
> or even to protect anything, for the benefit of their users. Meanwhile, it
> allows those who want to operate protected-but-interoperable grids to do so,
> for the benefit of their creators. Everybody wins.
>
> Sincerely,
>
> jw
>
>

---

From: Morgaine <[email-masked]>
Date: Wed, 25 Feb 2009 07:18:29 +0000

Gareth, although you've withdrawn your proposal, it addresses interesting
issues so I'd like to make a brief comment on your last point:

> sub-components to the collected whole (since they're part of the

While such examination is just about feasible at interop time in SL's
non-hierarchical scheme for objects, it is totally impractical for the
hierarchical objects that would be the norm in a world without those highly
SL-dependent restrictions on object composition.

An object will in general be composed of an arbitrary number of other
objects arranged in an arbitrary tree, just like objects are composed of
smaller components in the real world.  This is the basis of engineering and
the key to riding on the shoulders of giants.  "Arbitrary number" could be
hundreds for virtual objects with current-day levels of complexity, or
thousands or more as our means of object production improve.

Consequently, such piecemeal examination of permissions cannot be done
realistically at interop time, but must be done at object construction time
instead, propagating permissions up the composition tree as required.  All
we then need to do at interop time is to look at the root of the object tree
and no deeper.

Hierarchical objects are rather central to the success of the virtual object
concept in VWs, and they are a linch-pin for the expansion of virtual
economies with more complex technology too, so they're coming.  More on this
from the SL perspective is available here:
https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy .

Morgaine.

---

From: William George <[email-masked]>
Date: Wed, 25 Feb 2009 12:41:25 -0500

Morgaine,

  Yes..but..my comment was in reference to the idea of permissions, mainly
so I could buy a "no-mod" object, tack my mods on it, make it modifiable,
but still protect the sub-assemblies' object creators intentions.

SL has effectively disabled this aspect of the time honored yankee tradition
of re-tasking objects for things they weren't orginally intended to do. My
better mousetrap shouldn't need to be constructed from scratch.

I'm guessing the the object hierachy as described will work well for the
permission attributes of sub-assemblies.

Waka