[Opensim-dev] Legal Issues was RFC Profiles

Tue Mar 31 09:22:20 UTC 2009

Well, you /could/ use hashing to define the license text, but honestly? A URI works better. Really, just making it complicated in order to have a UUID really isn't ideal. 

OpenSim can internally download from a URI and present to the user as a notecard if we wanted, we're not really forced into identifying licenses by UUID. 

If we stick to URIs, it becomes quite possible to identify as either a content hash or a content locator. This gives us a lot more flexibility, plus does not limit us to a finite quanta of licenses preinstalled on the system.

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Andrew Yourtchenko
> Sent: Tuesday, 31 March 2009 1:26 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Legal Issues was RFC Profiles
> 
> My 1.5 eurocents:
> 
> On Tue, Mar 31, 2009 at 5:33 AM, Frisby, Adam <adam at deepthink.com.au>
> wrote:
> > I suggest using a URI here for the licenses, with major license links
> hosted at sites owned by major organisations unlikely to go down (CC,
> FSF, etc).
> 
> Watching the discussion, I thought having a "License library set" of
> notecards with the predefined UUIDs might make it possible to have a
> complete set of licenses. However, this all has one interesting aspect
> - what if the license changes at some point in time ? Does the new
> edition have a new URL or the old one ? It's an interesting single
> point of failure if the latter. At least with UUIDs, the asset system
> is working against it (and, technically the UUIDs for those very
> specific items could be based on the hash of the content. RFC4122
> allows the SHA-1-based generation of the UUID based on namespace ID
> and name - in this case the "name" could be the entire license text.
> 
> I'm not a cryptographer, but I think making a SHA-1 collision *and*
> keeping the entirety of the text legaleze should be reasonably hard :)
> So, as a result we get the unique UUID for each license which will
> protect the text from accidental or malicious modification.
> 
> >
> > For plain SL-viewers, perhaps we could show the licenses as the
> 'description' of the inventory item or something? (maybe a '/license
> <item>' command inworld with the inventory item name returns license
> information?)
> 
> Another idea - if UUID is being used as a license id - would be to
> force-feed the user with the license notecard for the first time, when
> they select the item with the license not yet accepted, and request to
> assign "their friendly name" to this license if they accept it.
> 
> Subsequently send a one-liner into their messages from a
> pseudo-account named "License Reminder" when they select the other
> items for the first time in their inventory (or if they double click
> it?)
> 
> (Of course, overloading a description is nice, but then where does one
> store the description ?)
> 
> A totally out of the blue thought for the textures is to use the
> steganography to embed the license ID + creator name into the texture
> itself, my perception is that the size of the textures that the folks
> would care about would be big enough to allow this. Then this could be
> checked on import and the exceptions reported to the user themselves
> and the sim/grid owner.
> 
> cheers,
> andrew
> 
> >
> > Adam
> >
> >> -----Original Message-----
> >> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> >> bounces at lists.berlios.de] On Behalf Of Michael Cortez
> >> Sent: Monday, 30 March 2009 5:32 PM
> >> To: opensim-dev at lists.berlios.de
> >> Subject: Re: [Opensim-dev] Legal Issues was RFC Profiles
> >>
> >>  >> I'm not sure I would support having Creative Commons be the
> default
> >> though...
> >>  >> while it is an excellent option for some work and I have used it
> >> for
> >> some content
> >>  >> I have developed, it does reduce the creator's rights that are
> >> normally assumed
> >>  >> by the Berne convention or US copyright laws.
> >>
> >> This is true.
> >>
> >> With the four component options available for CC, many scenarios are
> >> covered:
> >>
> >> http://creativecommons.org/about/licenses/
> >>
> >> But not all.
> >>
> >> All of the CC options assume you allow redistribution, but aside
> from
> >> that in most cases "Copy-No Mod" would be equivalent to something
> like
> >> "Attribution No Derivatives" and "Copy-Mod" would essentially be
> >> "Attribution Share-Alike" or "Attribution Non-Commercial."
> >>
> >> What's missing is a "No Distribution" clause.  If the organizers had
> >> the
> >> foresight to be complete, rather then altruistic, the addition of a
> >> non-redistribution clause IMHO would have made for the ultimate
> >> mix/match license.
> >>
> >> An "All rights reserved, you are licensed to use this for personal
> use"
> >> type clause for "No Perms" would be good.
> >>
> >> Lots of ideas, and there will be lots of complexity -- and of course
> we
> >> don't want to start handing out legal advice -- but as others have
> >> mentioned, if we start with some way of adding asset meta data -- we
> >> can
> >> then grow from there.
> >>
> >> Now of course, for specific grids like say <cough>OSGrid</cough> --
> >> where I suspect the admin's aren't really in this to be  IP rights
> >> cops,  and probably don't want people coming after them with
>  lawyers
> >> because some bug  exposed  an exploitable asset copy mechanism, or
> >> because someone connected a hacked region to the grid to suck assets
> >> out
> >> -- perhaps having the default licensing be something like CC --
> which
> >> always guarantees redistribution isn't such a bad thing?
> >>
> >> --
> >> Michael Cortez
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> Opensim-dev at lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev