Second Life Enterprise and the Business-Oriented Virtual World

Your own isolated virtual world

The next question to ask is, if this is an isolated environment, how does a company get any content into it?

The obvious answer, of course, is that companies will hire metaverse development companies — SL Developers — to create their content for them. They’ll create a set of avatars for the developers, add a few logins on their corporate VPN, and allow them to build-for-hire inside the closed environment of their SLE box.

But the fact is, each company will hire whomever they wish to do that job, since that’s how new content will get into a SLE box: by building it from scratch, using the regular SL Viewer, but connected to a totally separate grid. Content cannot be “copied over” from the SL Grid to a SLE box. There were some rumours and disinformation spread out that SLE clients would get a “special SL Viewer” allowing them to check a box and content would be “magically transported” to their box. This is utter nonsense, since the SLE boxes are not connected to the grid in any way — there is no link, no common resource, no “hidden trap door” that allows the box to somehow access LL’s own central servers. Even the avatar logins are just locally created and have no existence whatsoever beyond the SLE box!

So, yes, content has to be created from scratch inside a SLE box, and anyone can create that content, so long as the box owner gives them access to it. Although LL already included some “standard” content to get things started for the corporate customers, most will wish to create their own. In many cases, they might already have a few talented content creators working as employees, and these will do the work using the same set of tools they’re used to; in others, it’s possible that this work will be outsourced to external developers. But there is no restriction in hiring developers! Companies will obviously pick the ones they feel that can deliver the best content for them, and it’s also possible that in many cases they will establish a binding RL contract with the content developers, since they will have to agree to transfer the ownership of that content to them.

Similarly, content created inside a SLE box is effectively isolated and cannot be “copied” elsewhere: so there is little fear that a malicious corporate customer hires a group of developers and then copies that content indefinitely (even though they will have “God mode” inside their SLE boxes!) and profits from that. This is effectively impossible because content cannot “leave” the SLE box. In fact, even if a customer has two SLE boxes (for a total of 16 regions) they cannot transfer content from one box to the other, even if both boxes are inside their corporate network. Each box is totally isolated from each other, even if they are side-by-side inside a data centre or co-located facility. The only information that might be shared is authentication via a common LDAP server: this means that a company having a network-based authentication service for their internal services (e.g. access to corporate servers, file and printer sharing, etc.) might use that authentication server to provide login data for the SLE boxes, too (avatar names are completely unrestricted inside a SLE box and they have nothing to do with the “rules” of the SL Grid: you can use whatever name you wish, no matter if it is already registered on the SL Grid or not; also, there are no limitations on the choice of a “last name”). Even if a single LDAP server provides authentication for the same avatar in two different boxes, only the login information will be the same. The avatar will be completely different! They won’t share inventory or land ownership or any other SL-specific information at all.

This hopefully should give content developers getting hired to do some work for SLE boxes some peace of mind. No matter how “malicious” a SLE box owner might be, they cannot do much with your content, except use it in their 8 regions on that box. It cannot be saved or moved elsewhere. There isn’t even a “Linden dollar” economy. This naturally means that content developers will use a standard work-for-hire agreement, getting paid in US$ (or, well, any other currency) for developing some exclusive content for that particular customer, and be assured that this content will not be placed anywhere else but on those 8 regions of the very same SLE box where they created it.

What is possible to do is something slightly different. If Linden Lab is shown the proper contracts and licensing agreements, they will allow developers to create some content on the SL Grid and then “transfer” it to the SLE customer. This is a special case, where Linden Lab, after duly certifying that all content in a region has been legitimately used by a developer (that means that they have licensing agreements and contracts with all individuals contributing content to the overall project), make a backup of that region and upload it to a customer’s SLE box.

This has been often misinterpreted as allowing SLE customers to point at a region and tell LL to copy it over. Well, it’s nothing of the kind. Every single prim, texture, script, sound, animation, or any other asset inside the region has to be licensed by the content developer for specific use of the SLE customer, and have the ability to legally prove the ownership of content. We’re not talking about the permission systems here. Content developers cannot simply use freebies or any other content bought in SL, deploy it on a region, and tell LL to copy it over. That’s not how it works at all. Instead, it’s all done via specific contracts in real life, where each content item will have to be validated by Linden Lab to be actually something specifically created (and licensed with a valid contract) for the SLE customer. The allowance to be able to build on the SL Grid than directly on the SLE box is just a question of convenience. Many corporate customers are quite reluctant to give away VPN access to third parties, even under a contract. Others might not have VPN gateways implemented at all and have their corporate network absolutely isolated from the outside world. And in some cases, it might not be practical (or too expensive!) to force developers to create everything from scratch just for that particular customer.

A typical example is having a developed solution for the corporate market, like Rivers Run Red’s Immersive Workplaces. They have a packaged solution that was long ago developed to be deployed on the SL Grid, and recreating it from scratch to a specific customer would take ages and be a waste of their time (and increase the costs dramatically!). So they can just deploy it on an empty sim, present LL all the necessary licensing agreements, show the contract they have with the SLE customer, and LL will then — and only then! — copy it over to the SLE box. This is pretty much what LL has in mind when allowing whole regions of SL to be copied to a SLE box. It’s not the ability to copy any region, but only solutions that have been created for a very specific purpose. And SLE box owners cannot do the copying themselves, they simply have no tools for that. They will always have to go through LL to get that service from them.

So, content developers are quite protected in this regard — even more so than on the SL Grid! There is truly no fear that your lovely trees, being sold for L$50 on your shop in SL, will end up as a US$500 item sold to a corporate customer without your authorisation. Linden Lab will never do that unless you sign a specific agreement, in real life, that allows the corporate customer access to that content. Content developers should thus see this as a new market opportunity, where every content creator, as long as they’re willing to enter real life contracting agreements, will have the chance to sell their content to corporate customers for quite a handsome amount of money.