Exports and imports and permissions

Recently, there's been an increase in misinformation surrounding the export of objects from Second Life. Part of the upsurge is because the Singularity viewer's latest release includes the ability to export a linkset as a COLLADA .DAE or Wavefront .OBJ file, which can then be fed to things like Blender for hacking on and eventual reimport as mesh objects.

The baseline for this discussion is paragraph 2.b of the Third Party Viewer Policy, which says:

You must not use or provide any functionality that Linden Lab’s viewers do not have for exporting content from Second Life unless the functionality verifies that the content to be exported was created by the Second Life user who is using the Third-Party Viewer. Specifically, before allowing the user to export the content, the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported, including each and every primitive or other content type, is the same as the Second Life name of the Third-Party Viewer user. This must be done for all content in Second Life, including content that may be set to "full permissions."

That's pretty simple. If you didn't create it, you can't export it, even if it's full permissions. (Much full-permission content in SL is licensed only for use within SL.) This applies to prims, textures, scripts, and anything else.

Exporters have been around for a very long time. They predate the Emerald viewer. The first copybot tools predate even the open-sourcing of the viewer code. LL had been trying unsuccessfully to get a handle on them for as long as they'd been around, and the Third Party Viewer Policy finally gave them some leverage.

Exporters are good things for some content. While any animations, textures, and the like you create, you should have on your local computer already, there are other things that get created that don't exist outside of SL unless you export them. Some, like scripts, are easy to export with a simple copy and paste. You can't copy and paste a prim, though, much less a full linkset (an object made out of multiple prims, from a chair to a full castle) with all of the complexity that goes with it (texture parameters, scripts, colors, you get the idea).

Emerald and Phoenix had an exporter. With their demise, though, there's a void in the content creator's toolset. We've been working for quite a while on adding export capability to Firestorm. Techwolf Lupindo has written an exporter, designed to be rigorously accurate and to honor the TPVP to the letter, while still giving meaningful capabilities to the user. There's a whole framework involved for selecting what's to be exported, checking the creator of every component and only exporting those components that are created by the user, and getting the data out and back in. The point is to allow a creator to back up and restore whole creations so that they could be replaced if an inventory corruption or account problem destroyed the originals, as well as permitting copying things to other grids.

It got disabled in Firestorm at the last minute because it didn't pass QA. Cinder Roxley is working hard on fixing the problems so we can enable it in 4.5.1.

Meanwhile, Singularity's Latif Khalifa wrote a function to export linksets to mesh files, and included it in the latest release. I haven't tried it myself, but I think it's a good thing overall. It lets a creator prototype in prims in SL and then refine the result into a nice mesh object. We've asked for, and gotten, permission to include it in Firestorm, though Cinder's reworked it a bit to integrate it seamlessly into the existing exporter framework.

There's been some confusion recently about having export capability and what it does to content security in SL. The biggest claim is that all it takes is removing two lines of code and it's a free-for-all. That's always, always been true in SL, ever since the viewer was open sourced. Textures, in particular, have always been vulnerable. Scripts aren't, simply because they're never sent to the viewer unless the user has the ability to edit them. (They execute on the sim host, not in the viewer.) The exporter doesn't add anything new here.

Another claim is that the mesh exporter will export any mesh object. I wish it did, actually; there's an item that's freely available and uploadable, but can't be edited in Blender, that I'd love to let SL export in a form that Blender can work on. (No, there are no licensing restrictions that would prohibit this.) But no, nobody's got an exporter that will do mesh objects. Edit: I was incorrect. Singularity's exporter, and therefore Firestorm's, will indeed export mesh objects. They will not export rigging information, however, so rigged mesh clothing and the like would have to be rerigged by any putative copybotter.

At one point, it was claimed that the Firestorm exporter was in violation of 2.b because it allowed export of a linkset that wasn't entirely created by the user. Siana Gearz even went to LL to complain about it. Since Firestorm does not export any component that was not created by the current user, and the policy says "the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported", LL agreed that we're following the letter and spirit of the TPVP.

This is ironic, because Singularity's exporter will happily export a sculpted prim with a sculptmap that was not created by the current user. We will, of course, fix that in Firestorm.

So, to sum up, the exporters in Firestorm and Singularity don't add any ways to steal content that didn't already exist in other forms. (I'm certain Singularity will fix that one hole I just mentioned.) They do add capabilities for content creators, and that's a Good Thing. No need to get alarmed.