[opensource-dev] Stuff from my Lunch Bag

Aleric Inglewood aleric.inglewood at gmail.com
Sat Apr 10 06:33:21 PDT 2010


+100

Aleric Inglewood

This seems to coincide with my remarks added to
https://wiki.secondlife.com/wiki/User:Robin_Cornelius/tvp_mods
where I point out that the mixture of developer and user just
doesn't work (if only because it requires a *different* definition
of "Third-Pary Viewer"). However, my conclusion is that it
makes no sense to refer to "Developer" at all.

On Fri, Apr 9, 2010 at 9:17 PM, Nicholaz Beresford <nicholaz at blueflash.cc>wrote:

> I won't attend the meeting, but here are a few pennies worth of
> suggestions (they would be too detailed and complex to convey in a
> meeting anyway).
>
> First of all, I believe the current TPV is broken beyond repair.  The
> main reason is that responsibilities for users, developers and viewer
> dictionary are mixed into a mess and that many burdens/agreements which
> IMO belong in the category of preferred partners (viewer directory) are
> mushed into other sections.   I'm sure it's confusing to the users and
> it's obvious (by previous discussion here) that it's confusing for
> developers.
>
> Below is a way to structure the TPV which I would have found acceptable
> (fleshed out details nonwithstanding):
>
> 1) Explain what an acceptable TPV is and keep it to the core concerns:
> - protection of copyright (blatant violations of permissions)
> - protection of user accounts (passwords, etc.)
> - protection of the service in general (viewer crashing, server load, etc.)
>
> 2) Make a section which applies to users (anyone who uses a TPV to
> connect to SL) and leverage your main goals through that:
> - prohibit use of viewers which violate the concerns under 1)
> - reserve the right to block access by such viewers
> - reserve the right to request stopping use of those and eventually to
> ban accounts using such viewers
> - instruct that there is no end user support for problems arising when
> using a TPV
> - instruct users that is their responsibility to do their DD when
> choosing a TPV and that they have to deal with the outcome
> - instruct users how to look for acceptable viewers (points listed below
> under 3) and recommend usage of viewers from 4)
>
> 3) Make a section for other viewer developers in general and keep
> requests/agreements to a bare minimum and easy to comply with
> - explain that if developer uses his/her viewer to connect to SL, he/she
> is also  a user under 2)
> - in addition request the following
>  - visible disclaimer about non affiliation with LL
>  - visible notice to end users that usage being governed by the TPV policy
>  - visible notice about account and privacy protection
>  - visible notice about support (i.e. non-support  by LL)
> - make it plain and simple and refrain from requesting a card blanche
> for broad and/or future demands (the whole TOS is transferable, and even
> if a developer would trust LL's good intentions, a potential buyer of LL
> may not be seen to have those).  (See the middle part of the blog post
> from the Imprudence folks, these were mainly my concerns too:
>
> http://imprudenceviewer.org/2010/03/26/an-important-announcement-regarding-the-third-party-viewer-policy/
> )
>
> 4) Make a section for the viewer directory.  Put the more far reaching
> requests into that for those who want to be listed there in order to
> gain exposure
> - naming conventions beyond the existing trademark policies
> - promise of adjustment/removal of features and other nice  (for LL) to
> have cooperation
> - whatever else beyond 3) may be on LL's wishlist
>
>
> These are just from the top of my head and obviously I'm merely speaking
> for myself only and from the armchair in the off even.
>
>
> Nicholaz.
>
>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100410/f772f837/attachment-0001.htm 


More information about the opensource-dev mailing list