Month: March 2010

Third Party Viewer Policy – Further update

Posted on by Inara Pey

LL have quietly slipped out a revised Third Party Viewer (TPV) Policy.

While its heart was most definitely in the right place, the initial draft was flawed in several areas, as commented on by myself and others at the time.

Pretty much everything that appeared to run against common sense seems to have been fixed – with the passable exception that LL still insist of laying claim to the word “Life”. In particular Part 1h is gone from the document (good!) and Point 6a(ii) has been revised so that personal information such as rl name and address will not be published in the Viewer Directory. A minor niggle here is that it should be spelled out clearly in the Policy itself, but it is clarified in the accompanying FAQ.

Point 7a has been also  been cleaned-up. The original stated:

You are responsible for all uses you make of Third-Party Viewers, and if you are a Developer, you are also responsible for all Third-Party Viewers that you develop or distribute.

This was a dangerously ambiguous statement and one that could be taken to read that the original developer will be held to account for each and every use their Viewer is put to – even if modified by others outside of their control. As such, this one statement, more than any other, served to potentially undermine the entire policy: who in their right mind would agree to such a clause when knowing full well anyone could maliciously seek to download, alter and use their code?

In the revised document Point 7a now reads:

You are responsible for all uses you make of Third-Party Viewers. If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute.

The difference is subtle, but it is there; The reference to features, functionality and code allow a distinction to be drawn between being a developer being held accountable for their “original” code and being responsible for modifications to said code made outside of their control. This should in theory be enough to allay fears in this direction.

Only it doesn’t. Many are still up in arms about the Policy, largely due to the manner in which Section 7 has been re-cut.

The problem here seems to be part technical and part social – and frankly, it is the Lab’s fault that the two issues have become confused inasmuch as they have chosen to draft a policy that intertwines the technical development of a Viewer and its means of distribution with its social use (Section 7, “Your Responsibility for Third Party Viewers” is actually now sub-titled “If You are a user or Developer of Third Party Viewers”).

The specific point that has upset some Viewer developers is Point 7d: You assume all risks, expenses, and defects of any Third-Party Viewers that you use, develop, or distribute (my emphasis).

The mixing of use with development and distribution of third-party Viewers creates an unfortunate ambiguity wherein this statement could be taken to mean that third-party Viewer developers could still be held accountable for the uses to which their code is put once it has passed beyond their control. This is clearly unfair.

While it could be argued that a user taking an established Viewer and tweaking it for malicious purposes could be regarded as “development” of the Viewer, the fact remains that such issues should really defined within the Terms of Service, which a) themselves relate to the use of both the Second Life service and the tools used to connect to it; and b) are actually likely to be read by users.

Both as a part of this blurring of use and development, and as a matter in its own right in terms of overall technical liability, several raising objections to Point 7d have done so specifically in terms of “GPL violations”. I have to admit, I don’t fully buy-in to their arguments, and I’m not absolutely certain any court would agree with their black/white view of the text of this Point because:

  • Linden Lab have sought to clarify the Policy with a FAQ, where the meaning of various clauses in the Policy are spelled out in lay terms. As a supporting document, complete with explanations given by Linden Lab themselves and presumably approved by their lawyers, the FAQ does have bearing in a court of law. As such, were Point 7d to result in a Viewer developer being held unduly to account for the use of their code, the FAQ could be used to counter any action
  • More importantly, no legal document stands in isolation. There is the established precedent of law and the forbearance of pre-existing agreements and understandings. As such, a court is unlikely to go against a Developer who has acted fully and completely both with the spirit of the GPL and this policy, simply on the basis of point 7d. In fact, in many respects, it is hard to see such a case reaching court
  • On the wider, more controversial front, many view GPL as automatically granting immunity under the terms of the agreement. This is actually not the case. Clause 16 of the GPL broadly absolves the developer from liability, it does so with the caveat of unless required by applicable law or agreed to in writing (my emphasis). Thus, and while some developers may howl and scream at me for saying so, LL are technically within their rights and within the spirit of the GPL to introduce whatever clauses they deem fit into their policy. While this is a cause for concern – as this is how LL are adding the onus of liability – it doesn’t prevent developers in turn limiting the extent of their exposure with an EULA that includes a mandatory agreement as a part of the Viewer installation process.

Thus, while there are problems with Section 7, I don’t actually believe they are insurmountable.

Ideally, the issue of confusing Viewer use with Viewer development would best be dealt with through Linden Lab simply redrafting the section to clearly differentiate between the responsibilities of the Developer and the responsibilities of the user (for example, have Point 7a list the responsibilities of the Developer as enumerated items (i, ii, iii, etc), followed by Point 7b giving a enumerated list of responsibilities for the user). Doing so would probably account for around 98% of the gnashing of teeth and wailing currently being evidenced.

That said, and failing any re-write of the TPV, developers still have recourse to the use of an EULA, as mentioned above. If I understand things correctly, doing so would not be in violation with the GPL. Such an agreement / licence statement would likely supersede  statements such as Point 7d in the TPV policy, given that by allowing such a Viewer to connect to the grid, Linden Lab are tacitly acknowledging the developer’s own Licence Agreement with their users.

One also wonders whether Linden Lab will actually be pro-active in blocking Viewers from accessing SL where the developers have not signed-up to the TPV.

That said, at the end of the day, the TPV seems less a matter of legal action and far more a matter of public perception. Take away the inadvertent ambiguity and the rest, and the Policy really hinges on two thing in order to “succeed” in its aim of reducing the risk of malicious Viewers connecting to the grid:

  • The unwillingness of people behind such Viewers to provide proof of identity to LL.
  • The unwillingness of users to go beyond the list of “compliant” third-party Viewers and use a Viewer which might be perceived as being malicious and result in their being banned from the system as a result.

As such, if both of these goals are achieved, or perceived to have been achieved, then the Policy can be regarded as a “success” – even if it does (sadly) come at the cost of some developers continuing with their efforts to provide better and more stable means for users to experience Second Life.

Scripts limits announced

Posted on by Inara Pey

Jack Linden – possibly as a part of his new role as Executive Director, Consumer Products today blogs about the upcoming server-side scripting limits.

These have been the source of much hype, debate, guesswork and outright misinformation (not, I hasten to add, from Linden Lab) for a while now; while it is still somewhat early days, Jack’s post is welcome as it does much to set out LL’s table on the matter, and start the flow of information very positively – allowing for the fact that much still appears to be in a state of flux.

Of course, there are concerns with the approach. While scripting limits are perfectly acceptable and may well help improve sim performance on overworked servers (allowing for the virtual nature of sims themselves), the planned roll-out of the new controls does lend itself to a lot of potential misunderstandings and confusion. In this respect, I certainly hope that Jack and the team keep Phase 1 of the project – Information – uppermost in their minds.

In summary:

  • Linden Lab will be rolling out the project in three broad phases: Information – and Jack’s post can in some ways be seen as the first post in this effort, even though there have been earlier general postings on the subject by the likes of Babbage Linden; Tools – see below; and Enforcement
  • Server 1.38, due out in April will start the ball rolling with the release of script monitoring tools
  • Said tools will allow script usage to be monitored on a per parcel basis but the parcel “owner” / renter; additional tools will be provided to the sim owner / estate managers which will enable the return of objects that are taxing the sim in terms of script loads
  • Script “space” in memory will be assigned to sims in a similar manner to prims: there will be a total limit for the sim as a whole, which can then be allocated to parcels as the land is divided up.
  • Additional script space will be allocated per avatar, with an overall “pool” of resources per sim to handle avatars
  • While Jack’s post does not make this entirely clear, it appears that if the script limit for a parcel / sim is reached, additional scripted items will not work; similarly, if all resources for avatars is used, additional avatars entering the parcel / sim will find attachments do not work.

Many have debated the pros and cons of capping scripts, but the fact remains, whether we like it or not, the servers supporting Second Life all have finite resources, and scripts have never really been monitored, and have become one of the causes of server-side lag, simply because of their overwhelming prevalence.

That said, Jack’s post does leave some cause for concern over potential angst / misunderstandings / over-zealousness down the road:

  • Currently, LSL scripts are capped at 16Kb, while  Mono scripts can use up to 64Kb (but can in theory be a lot smaller than this – the average being around 9Kb according to Jack)
  • However, the new tools will initially only report on the maximum amount of memory a script can use. So, if you have four LSL scripts running, they’ll be reported as taking up 64Kb of memory. But…if you have 4 Mono scripts running, they’ll be recorded as taking up 256Kb of memory – even though the scripts may be a lot leaner than this
  • The monitoring tools will be tweaked later in the year so that Mono scripts will be able to report their actual memory usage – but initially, only the maximum 64Kb per mono script will be reported
  • The upshot of this is twofold:
    1. It gives an incorrect impression that Mono is actually more resource-hungry than LSL
    2. It runs the risk of having people single out Mono users unfairly on the basis that (whether or not parcel / sim script limits are being affected)  “they are hogging resources” because their “script usage” is “higher” – much as we witnessed people getting all het up and shouting about ARC and lag…
  • A third possible outcome of this is that when shopping (and assuming memory usage becomes a “feature” of vendors, people will opt for LSL-scripted items because they appear more memory-efficient

There are other concerns that have been raised – such as scripters being able to use the land tools to test the efficiency of their scripts (given than not all scripts own / rent land, but work in places like sandboxes where the tools – to be included on the About Land window – will not be available to them. However, it is probably this issue of actual versus perceived script efficiency that is liable to cause the greatest upset with this change, unless LL work very hard to fully and properly communicate this change to the community as a whole.

And while script limits may well be a good thing for SL overall (I’m hoping they will have the desired outcome as far as is reasonably possible) – we’ve been shown time and again that when it comes to proactive communications with residents, Linden Lab’s efforts seem to repeatedly fall far wide of the mark.

Viewer 2.0: updates and iterations

Posted on by Inara Pey

New Release

LL have released an update to Viewer 2.0. It incorporates some positive actions, but still leaves a lot of issues uncommented on. LL are at least still taking feedback, but I’d venture to suggest that they’ll stick with Tom Hale’s put-down made back on the 23rd Feb that what we’re seeing is pretty much *it* and that large-scale changes (even those that make sense) aren’t going to happen.

Nevertheless, the improvements are somewhat welcome and we’ll hopefully see more tweaks as time goes on.

Of Polls and Surveys

A new survey on Viewer 2.0 has also been released. After the outstanding joke of the original “poll”, as put up by Amanda Linden, this one at least has the appearance of seeking feedback from residents.

The original poll is, sadly, still available on the front page of the Viewer 2.0 forum, where it appears to make glowing reading – 67% of those asked apparently love the new Viewer! It is only when the actual poll itself is viewed that one gets the full measure of the spin involved:

  • Only three responses were obtained before the poll was locked
  • The three options that followed the question, Do you like Viewer 2.0 were utterly skewed towards favouring a “positive” outcome, given they were:
    • “I love it!”  – i.e. overwhelmingly “in favour”
    • “I like most of it” – i.e. still “in favour”
    • “I’m indifferent” – i.e. can be counted as “in favour” as it doesn’t actually say “dislike”
    • “I don’t like it” – i.e. only giving a 25% chance of wholly negative feedback

Many of us took Amanda to task over the poll when published, and this may have influenced the shut-down.

I’m curious as to the new poll on four counts:

  1. Whether the results will be made public – I’ve yet to find a link allowing me to view results.
  2. What degree of spin will be employed on the results should they prove negative (remember, Hamlet Au over at the Herald managed to turn one poll that had a 66% negative feedback into a positive, simply by only mentioning that 33% of those polled were “in favour”  – making it sound as if this was the largest portion of votes received).
  3. How the poll compares to this one, which does include the ability to view the results
  4. Whether LL will even publish the results or simply push them to one side if the feedback tips strongly towards the negative.

Security Worries

One of the new features in Viewer 2.0 that has caused much commentary is shared media. However, the commentary hasn’t been entirely positive, raising issues over security and privacy. So much so that it prompted Samuel Linden to post on the subject.  It was supposed to smooth over the concerns and calm residents.

It didn’t. While it is reassuring to know – as posted in response to the thread – that LL are “working on” the specific issues vis-a-vis potential exploits provided by shared media, which really weren’t addressed in Samuel’s blog post, it is still somewhat worrying that LL were seemingly aware of the risk that resident’s computers may be exploited through the unscrupulous use of shared media and still opted to set Viewer 2.0 to a default of auto accepting shared media.

It’s also worrying that while most web browsers – which seem to be the paradigm for the new Viewer – give the option to turn off things like Javascript support, etc. (or rather, turn them on) – LL’s wisdom was to have them turned on by default, with no option currently included – or originally going to be included – in the Viewer to turn them off.

Samuel states LL will now be providing this functionality in the next Beta release, albeit it somewhat grudgingly:  Obviously disabling JavaScript will severely limit the functionality of websites, and turning off plugins will render Flash inoperable, but these are features that were requested, and we are providing them in the next Beta release.

It is comforting to see that LL are listening and responding to user concerns relating to security around shared media – but it is also worrying that they opted to take such a cavalier attitude towards security in the first place. If nothing else, this again points to the fact that Viewer 2.0 is – primarily – viewed by LL as “business tool” aimed for those whole will (in theory) be using it alongside their SLE product, nice and safe behind a corporate firewall, where fears flash and other tools being hacked are pretty much eliminated.

The First of the Third Party V2.0-based Viewers

Elsewhere, the first of the third-party iterations of Viewer 2.0 has popped up. KristenLee Cinquetti has always had a reputation for producing really top-notch Viewers which incorporate a lot of very useful features. Of all the Viewers out there, hers has always been my favourite simply because of the fact that her custom graphic pipe means that things like dynamic shadows actually work, and her graphics settings allow a whole new level of realism. Sadly, she does not embrace RLV functionality, which means I stick with Emerald – which, admitedlly, is almost there with the shadows.

Her first attempt at a “Viewer 2.0” compliant KLee Viewer incorporates elements that have found their way into the latest Beta update – so some may wonder at the fuss. That her mods were slightly preempted by LL is a shame – but they at least show how things can be done.

The major changes made are:

  • The Sidebar no longer shunts the world view to the left when opening (now in the latest official relase)
  • The Camera controls have been tweaked to something like the old system – both move and rotate are on the same toasty (pop-up). Admittedly, they still vanish if you click elsewhere – which is annoying and the control itself is still overly large, but at least there is no need for painful toggling
  • About Land is back on the top bar as standard – an XML tweak has previously been provided by Alexandrea Fride for Viewer 2.0, and its inclusion here is very welcome and makes the Viewer land management friendly once more
  • Some attempt has been made at making pop-ups, etc., transparent when the focus is moved from them but – frankly –  the interface really doesn’t lend itself to this. While this is hardly Kirsten’s fault, it still renders the effort on her part as almost wasted (transparency has also been somewhat introduced to the official Viewer)
  • Preferences -> Graphics includes an additional tab that allows the more “advanced” user an even greater degree of control over how their SL experience looks and feels – and this is very welcome
  • The Map and Mini Map button have been returned to the bottom toolbar. While both are very welcome additions, the former is huggable, as it means the bloody Sidebar can be totally avoided when trying to use the map!
  • Inventory is also back on the toolbar – so **HUGS** again as the Sidebar can be avoided!
  • Speed – as with all Kirsten’s Viewers, the average fps (for me) is around the 30 mark – considerably faster (and smoother) than the official viewers.

There are some things that are currently missing – but this could be down to the fact that the interface doesn’t (if Tom Hale is to be believed) make for significant changes. The Sidebar, for example, does not turn transparent when left open and the focus moved from it. Again, it may be entirely possible that making it so wouldn’t so much to change the impact it has on the immersive experience but there is a lot of black in the Sidebar, and it would be nice to see some of it “vanish” when forced to keep the bloody thing open. But then, like the official Beta, this is just a first stab at V 2.0.

Overall, I have to say that Kirstenlee’s approach is a major step forward in developing a Viewer that actually addresses two somewhat disparate audiences – the “old” and the “new”. What is more to the point, it goes a long way to ensuring that Viewer 2.0 doesn’t become increasingly annoying to “new” users as they gain grater familiarity with the Viewer and the platform and simply want to enjoy their in-world experience as a 3D experience rather than a 3D background to a clunky interface.

Azure: assurances and questions

Posted on by Inara Pey

Well, it’s official. As of today, MSL (operated by Anshe Chung) now effectively owns Azure Islands.

What does this mean? Well, overall, it means that a single land owning company now controls some 7.5% of private estates. May not sound a lot, but it is a bit of a clouting stick.

For Azure Island residents, it hopefully means that things will continue more-or-less “as is” under the new management, and both the outgoing Azure management and the incoming MSL team have stressed this, while indicating that perhaps some 5% of Azure residents may have to face relocation as MSL move to break up some of the Azure estates to provide “greater privacy and less lag” (to quote the MSL note to Azure residents).

The Azure team themselves are stating the reason for the transfer is simply that they’re in need of a change after some 5 years in the business – and as I previously noted, Adam Zaius does have his OS Grid interests that must be taking up a lot of time.

Change is a natural part of business. While some Azure residents may be adversely affected by the hand-over, it has to be said that while unfortunate, their disaffection doesn’t spell the end of SL or anything else; one can sympathise, but one isn’t going to chastise the Azure management or anyone else for the woo that some may encounter.

To me, the burning questions remain related to the wider implications of this move. While on the one hand, one cannot blame those behind Azure for wanting to move on to new challenges, there is still something deep down about the timing of this  change that concerns me – although what it is, I can’t rightly say.

Then there is the potential impact on smaller private estate owners. MSL / Dreamland is now a very powerful voice in LL’s ear, and one wonders at possible future implications in this. Again, none may be forthcoming, but given Jack’s penchant for behind-closed-doors deals, one has to wonder.

The entire – topography – of land sales and rentals is changing; the Azure move is in many respects “simply” another part of this. Doubtless some will cheer what appears to be another step in Adam Zaius’ departure from SL, while others will point to the sky and claim chunks of it are falling. I don’t think either is the case – but by the same token, I’m glad I’m no longer in the land business myself.

An Azure Dreamland?

Posted on by Inara Pey

It seems one of the major land businesses in Second Life is about to change hands. A comment posted on the SLU forums quotes the following for a notecard apparently circulated to some Azure residents:

We’ve got some fairly big news for the residents of the Azure Islands, as of March 16th, the Azure Islands will be transferring from us, over to a new management team run by Metaverse Services Limited.

If accurate, this is newsworthy on a number of counts. For a start, “Metaverse Services Limited” appears to be the holding company for Anshe Chung (Ailin Graef) of Dreamland fame, Time magazine celebrity and flying penises notoriety. If Azure is going under Anshe’s banner, then it means that from tomorrow, MSL control a huge swathe of estates and land across Second Life and are potentially in even more of a position of power where matters of policy and behind-closed-doors discussions with LL on land benefits, etc., are concerned.

Secondly, it begs the question as to what is happening to the land business overall in Second Life. Adam Zaius (Adam Frisby), primary owner of Azure island has been staunchly involved in SL almost from the beginning – something that has earned him a reputation as being a “pillar” of the so-called Feted Inner Core (FIC) and the devil incarnate by some, whilst simultaneously viewed upon as a fair and committed land owner, businessman and pioneer to others (notably his residents). Whichever side of the coin one happens to view when looking at Mr. Zaius – it cannot be denied he has built a considerable business enterprise within SL – one that goes beyond Azure itself; and has given a tremendous amount to the platform as well.

That he is now apparently selling-off / transferring / pretty much bailing on the SL land business – and taking into account his growing interest in / commitment to the OpenSim environment, which may be playing a part in this decision – tends to suggest that the entire land business, which has for so long underpinned SL as a going concern, is in far worse state than even the most negative of speculations around it have suggested. Even with his preoccupation with OSGrid development, it is hard to see Mr. Zaius abandoning what must be a healthy revenue stream simply for the hell of it. If he really is a “pillar of the FIC”, does he know something other’s are not privy to? Again, Zaius is not alone in running Azure…What of his partner in the venture?

Of course, this all could be grist for the rumour-mill – but I’ll be quite curious as to what emerges tomorrow.

Coming to a splash screen near you – your own MOTD…sort-of

Posted on by Inara Pey

In June last year, people logging-in to SL and who hung around while the progress bar was displayed caught a rather unusual Message of the Day (MOTD), thus:

(with thanks to Ciaran Laval for this image)

At the time it caused a mix of teeth gnashing and speculation. When pressed, there were mutters from some inside the Lab that the Azure MOTD was a “pilot” (or “beta” or some such), and that others would get the opportunity in “the future”.

Well – it seems the future has arrived.

On the surface, it comes across as a reasonable idea – those running businesses in SL can have the opportunity to reach a wider audience by having their very own Message of the Day displayed on people’s Viewer log-in screens. Of course, there have been the inevitable howls about “more advertising” in response to this post – but lets be honest here; LL have taken something of a shellacking of late for the manner in which they’ve used the MOTD to promote their own in-world content (vis-a-vis Linden Homes, etc.) – so one might argue that this is an attempt to redress the balance and put residents on the same footing.

Well yes. Apart from one small detail. Anyone wanting to use this “service” is going to have to shell out a minimum of $1500 for each 11.5 hour block of advertising space they want to book – with the “peak” rate (07:00-18:30 PST) being hawked by the Lab at a staggering $4500 per 11.5 hour block.

(Technically, each block is 12 hours – but LL “reserve” 30 mins in each block for “administrative purposes” – which suggests your MOTD may not be actually displayed during this period.)

Ciaran Laval has rightly called out Linden Lab over these charges from the perspective of the more modest estate owners in SL – as it is fairly obvious that the rates are only likely to be within the reach of the largest land barons. However, and while acknowledging Ciaran’s call on behalf of the smaller estate owners, I’d say the matter goes further than just the ability of estate owners to use the MOTD as a channel to market – the pricing structure virtually excludes all content creators from any participation.

Given this, one can only assume one of three things; either:

  1. LL is increasingly playing to a minority within SL, or
  2. LL is indeed in financial difficulties, and this is an act of desperation to generate income, or
  3. The offer has been skewed by LL’s continued belief that the future of the platform is inevitably tied to the use of the platform by “big business”, and as such, the rates have been set in a belief that they’ll be seen as a “serious” “opportunity” for “big business”.

Inevitably, most will go with (1.). But the FIC theory is all too often rolled out in response to LL’s actions whether or not they make sense.  (3.) has merit in that those who consider themselves “serious” businesses (aka the GSP group) pushing for the ability to market themselves “professionally”, and LL seem to determined to tie aspects of activities on the large grid into their SLE offering.

(2.) Is also possible – and certainly, if one leaves out (1.) and (3.), the “offer” does have more than a whiff of desperation about it.

As I’ve said elsewhere, I’m going to be very interested to see just who takes up the offer.