Welcome to the sixth installment of "Under The Grid", an irregular look at the mechanics underneath Second Life. This time, we're looking the announced release of simulator code.

The announcement that the simulator/server code would be released open source came at the same time as the announcement that the viewer source-code would be - both took place almost exactly two years ago, in September 2005.

Philip Rosedale, in his talks at SLCC this year, estimated that server-side simulator software would be open sourced within approximately twelve more months. Development staffers whom we have spoken to inworld and who have spoken on the matter on the development mailing list around the same time are estimating 1-2 more years.

There are a number of interesting blocking issues involved in opening up the server software.

The first is that the codebase is said to be quite monolithic. A large, single code-base where many components overlap and are not particularly well distinguished from each-other. Hampering some efforts to eliminated dead and unused code from the Second Life viewer is the simple fact that some of that code is used - but by the simulators, not the viewer itself.

Extracting the key portions of the code-tree to release as the Second Life viewer was a difficult and time-consuming process, according to Linden Lab staffers, and there seems little expectation that the extraction of other code for release from the original code-base will be any less difficult.

Why not just release the whole lot? Well, that's not a part of the plan, we gather. There are parts of the system that Linden Lab will be wanting to keep to itself for rather longer - whole chunks of the code don't even make any sense for use outside of Linden Lab itself. Much of the code that drives the asset system, for example, would be of little use to any third party, being tailored for very specific (and extraordinarily expensive) custom hardware installations at Linden Lab's colocation facilities.

Other issues involve connection trust. When a viewer asks for something, the server systems check to see if it is something that the requesting party should be allowed to have or to do. When a server asks for something, it gets it, or it gets done. Linden Lab trusts all the servers, because all the servers are under the sole control of Linden Lab. In the future that won't be the case.

How, what, and where all that authentication, validation and permissions checking will take place, and what matters of performance and policy that brings up - well, those are questions that Linden Lab says have not only not yet been answered, but many of those questions have yet to be asked internally.

Ultimately what will be being released, so far as we have been told so far, is the basic software that runs on the simulators. Not the asset system or user management or other things like that. The ability to install the software onto a Linux system of your choice, and pay for interconnection to the Second Life grid.

One of the chiefest concerns in the minds of users and community developers when it comes to third-party simulators is content protection, and trust. Any content rezzed on a third-party simulator can be trivially copied by the server owner. That just plain isn't preventable. In the DRM (Digital Rights/Restrictions Management) versus Content Cloning wars, DRM has so far lost every single battle. Despite billions of US dollars being pumped into DRM over the years since Superdistribution in 1983, DRM has never won a single battle in the war. Nor, at this stage, does is it seem likely to win one in the foreseeable future.

That opens up a whole raft of issues right there. The simulator operator can, of course, read your chat, your IMs, and duplicate your content (with permissions better than you yourself had), live or after the fact (just as it is with web-sites). You have to trust them or stay away. This issue has come up again and again. Expect it to continue coming up repeatedly for some time. There are ways of securing IMs from examination by any third-party, but at the expense of reduced performance (Public Key Cryptography for the win).

It's not even clear yet what the assorted licensing issues will be for certain pieces of technology. Havok comes immediately to mind, as does Endorphin. It is possible that any third-party technology like that may have to be licensed by a simulator operator out of their own pocket. Between licensing costs for third-party tech, grid-interconnect fees and bandwidth costs (a simulator can consume a ferocious amount of bandwidth - far more than most DSL/cable connections are able to provide) that operating a public simulator may prove to be a more expensive proposition than paying Linden Lab for one.

At this stage, however, the primary issues revolve around the interconnectedness and lack of functional separation in the code-base and the way the grid handles server trusts. If Linden Lab released one hundred percent of the source code that runs on a simulator today - right now - you would most certainly not be able to connect that simulator to the grid. In fact, it's unlikely that you could even get it to run at all, locally, without a significant number of man-hours from skilled programmers to fill in the blanks, create support infrastructure and additional tools.

Whatever the outcomes and answers to most of these issues, it is clear that there is a long road ahead before the first third-party simulators start to appear on the Second Life grid. Some smaller pieces have begun to appear, but it would be nothing short of astonishing to see substantive amounts of code anytime soon.