Thursday, March 4, 2010

Are CDS users planning to go social with their vigilantism?

As I got home from work today and brought up my Twitter stream, I came across this tweet from Ann O'toole which made my heart sink like a rock:
we need one of them oauth thingies to tweet copybot network detections so everyone will see the rate of shoplifting in #Secondlife
So, it's not enough that they're perma-banned everywhere Gemini CDS is used,  their info kept in a database forever labeled as "potentially dangerous"; now you want to add the internet equivalent of public stoning as a feature?


I do expect Ann to be a bit controversial, but this is beyond the pale. I could see this "feature" being implemented in one of two ways: on detection it either tweets to the user's Twitter account with a hashtag to enable CDS users to find all detections twittered, or detections get twittered to a specific account for the purposes of publicly browsing names. This idea throws the possibility of innocence or false detection even further out the window while extending the networked vigilantism beyond SL.

Here's a couple of questions that I would like to ask CDS users and Skills Hak if this idea were to get implemented:
  1. If it were implemented as to tweet to the user's Twitter account, will there be a way to automatically delete the tweet if an accused avatar successfully appeals, or will they have to make their case with the CDS user or Twitter itself?(The question is similar regarding the second implementation, just replace "CDS user" with Skills Hak).
  2. If you're so fed up with the Lab's "refusal to deal with the copybot anarchy", then why not involve the Department of Justice? Why turn to networked vigilantism when involving authorities higher than LL may get a better outcome(DOJ gets wind of rampant "copyright infringement" in SL, DOJ investigates and finds LL lacking in enforcement, DOJ threatens to sue on behalf of copybot victims, LL wakes up and gets strict on enforcement thanks to DOJ legal threat, everybody's happy)?
  3. What will you do if a falsely accused avatar(or a group of falsely accused avatars) decides to sue the entire CDS system on grounds of defamation of character and vigilantism(The entire CDS system refers to the individual users all the way up to Skills Hak)?
Again, I'm not defending copybotters at all here, I'm pointing out the vigilantism and escalation being encouraged by this system and it's users, and it's clear potential to harm innocents and the falsely accused. If this idea were to make it into CDS, then it has the potential to make the JLU scandal look trivial in comparison.

Caveat emptor, folks.

Monday, March 1, 2010

The External Grid Selector script, version 0.3

This new version of the grid selector script no longer detects any third-party viewers, because virtually all major third-party viewers now have a built-in grid manager. The only viewer that does not have it is the official one, including Viewer 2.0. So this version will only detect versions of the official one, including Snowglobe.

Without further ado, here's the script:

========================
#!/usr/bin/env bash

#Second Life Grid Selector and Client Launcher
#A simple grid manager for the official Second Life viewer
#(C) 2010 Jose A. Agudo aka Second Life resident Antonius Misfit
#Licensed under the terms of the GNU General Public License v3 or at your option any later version

viewer=$(zenity --list --title="Viewer Chooser" --text="Choose a viewer:" --column="Viewers" $(find SecondLife*/secondlife Snowglobe*/snowglobe))

#retrieve grid "database" which is simply a bash array variable sourced from a file
if [ -e $HOME/.grids.db ];then
source $HOME/.grids.db
else
cat > $HOME/.grids.db << EOF
#Feel free to add grids here
grids=("Second_Life" https://login.agni.lindenlab.com/cgi-bin/login.cgi "Localhost" http://127.0.0.1:9000 "3rdrock" http://grid.3rdrockgrid.com:8002/ "OSGrid" http://osgrid.org:8002/ "InWorldz" http://71.6.142.199:8002/)
EOF
source $HOME/.grids.db
fi

main()
{
action=$(zenity --list --title="SL Grid Launcher" --text="Choose a grid:" --column="Grids" --column="Login URI" --print-column="2" ${grids[@]:0} "Exit" "Exit")
case $action in
Exit) exit;;
*) $viewer --loginuri=$action;;
esac
}
main

========================

How Third-Party Viewer Developers are going to feel the pain

In my previous post, I described exactly how inter-grid content creators are going to become walled out of Second Life. But the Second Life® Terms of Service and third-party viewer policies will also bite third-party developers, hard.

In particular, the ToS and third-party policies place restrictions on GPL usage and distribution for viewers that connect to Second Life, as I've blogged about it before. Also, Section 2(b) of the third-party viewer policy will affect the major third-party viewers(Emerald, Meerkat, Imprudence etc) because they all have content export capability. If a third-party viewer developer wants their viewer to comply with the policies, then they will have to somewhat cripple that functionality(no full perm export, creator-only), despite legitimate use cases that warrant it.

A third-party viewer developer now has this hard choice to make: either cripple certain functionality and accept restrictions on usage and distribution, or rewrite their viewer as "not for Second Life use" and as a result lose much of their current user base in Second Life.

From the discussion going on in the opensource-dev mailing list, it seems virtually all third-party developers are going to take up the latter choice. But that may wind up to Linden Lab's disadvantage in the long run, because that means those viewers' innovations will be re-geared to benefit Second Life's biggest competitor: OpenSim-based grids.

Sunday, February 28, 2010

Second Life about to wall up content

Ann Otoole calls out Linden Lab in her latest blog post, spelling out how Second Life is about to become a completely walled-up garden starting on April 30, 2010. She frames the discussion in the context of textures, but her argument also applies to objects, clothing/body part items and scripts(to a much lesser extent).

From April 30th onward, the Lab will be vigorously enforcing Section 2(b) of the third-party viewer policy, which also happens to be a part of the Second Life® Terms of Service.

In the opensource-dev mailing list, Lindens are suggesting content creators who wish to allow inter-grid use of their content should host it outside of the Lab's grids and services. The implication of that is that Second Life is unsuitable as a host or distribution channel for such content. For LSL scripts, that's not much of a problem because if a script's code can be viewed in-world, it's simply a matter of copy/pasting text, the Lab can't really stop that. But for other types of content(especially prim and sculpty-based objects) made for inter-grid use, the policy and the ToS combine to form a content license trap.

For example, let's say I'm creating a prefab house that I wish to be used in both Second Life and other grids. I create and host the content on my own server, by using a third-party viewer to export it to a zipped archive. I create a specific license allowing inter-grid use(or use an open license). Someone who wants to use my content logs into Second Life and imports the content in-world. Now, here's the big question:

When my licensed content is imported into Second Life®, what happens to the license for that specific copy? According to the ToS and TPV policy as it is today, my license(parts of it at least) no longer applies to that copy and can only be used within SL and it's rules. In effect SL becomes a content trap and a walled garden, both for permissively-licensed content(Creative Commons, open source, public domain etc) and proprietary content with inter-grid use allowances. So to preserve the license and the rights to my content, I must have a clause in my license that prohibits import to grids whose policies or ToS conflict with my license, otherwise the importer loses the right to use my content.

That kinda sucks, right? Well, not all hope is lost and in my next post I'll detail the painful choices third-party viewer developers and their users may have to make in the wake of the third-party viewer policies, and how this ties to content creators.