Open-sourcing Second Life is more complicated than you might think
Jan
A fairly mundane post on the official Second Life blog yesterday kicked off a discussion about the merits and practicalities of open-sourcing Second Life (a prospect which we’ve discussed on this blog previously). Unusually, a Linden Lab official chimed in to explain that open-sourcing Second Life is something that they’d still “dearly like” to do, but a number of practical security considerations have to be overcome first.
Whilst I might take issue with the assumption that open-source = untrusted, this is still very encouraging news, especially after the shock did-he-fall-or-was-he-pushed departure of Cory Ondrejka last year.
Thanks to Tari Akpodiete for flagging up this comment thread for us!
Comments
Trackbacks
Use the following link to trackback from your own site:
http://www.machinimafordummies.com/articles/trackback/21313
The security problem isn’t really “open source = untrusted”, but the unsolved problem of Digital Rights Management (DRM). This is already a problem in the viewer - if you send any data to the viewer, it can potentially slip out of your control. At a rudimentary level, screenshots can grab textures, sound cards or microphones can grab music, etc. We saw the havoc that CopyBot spawned, which I think was before open sourcing the viewer code.
Similarly, if you give another simulator all the data that defines an object (including scripts!), that object is no longer in your control. It’s very very difficult to come up with any sort of DRM system that always works.
I think one way to solve this is to simulate “roaming” objects on a “parent” simulator in the “parent” grid, so that an object created in one grid never needs to leave that grid’s control. But this might be too slow.
If you didn’t know already: don’t forget that open sourcing the server isn’t just about the code, but also opening the entire grid - I think they’re eventually planning to create a multigrid platform, where you can bring your own simulator and teleport between grids.
Ah, right. Well, if they’re trying to emplace robust DRM in Second Life, they’re screwed from the outset. To quote Bruce Schneier, trying to make bits not copyable is like trying to make water not wet.
It’s trivial to copy textures from SL, obviously - the same way we created lipsynching in BloodSpell, by intercepting the OpenGL stream. Objects made of primitives may be a bit harder - it’d depend on exactly how the renderer on the viewer side works - but wouldn’t be impossible even if you only have OpenGL access. Scripts are a bugger, of course.
But other than scripts, everything in SL is copyable right now, and it’s going to be brutally hard through impossible to change that.
Keep on blogging, we need you. I’ve got so much useful stuff from your blog and really value you opinion in this stuff.
No worries, we ain’t goin’ nowhere.