I’ve counted Dusan Writer as a friend (or at least a friendly acquaintance) ever since I met him in the course of his UI design contest a year ago. He’s an interesting personality, and generally an intelligent fellow and a thoughtful writer.
So, it’s with some disappointment that I read Dusan’s recent post on Second Life’s permission system. His post is prompted by the progress of VWR-8049, a proposal to allow users to choose the default permissions for new objects that they create.
Dusan comes out strongly against it, and although I’m firmly in favor of it, that’s not the disappointing thing; I don’t mind people disagreeing with me. What disappoints me is that Dusan has bought into the baseless FUD that certain individuals have piled onto the issue.
Alas, not only does Dusan believe the FUD and let it color his entire analysis of the feature, but he also regurgitates it in a most unsavory and uncharacteristic manner, littered with baseless attacks, ranting nonsequiturs, and flawed thinking. I’m usually content to let this sort of thing lie, but it boggles my mind that FUD of this sort could spread when it has so many holes in it.
Isn’t copy/mod/transfer about as close as you can come to an ideal system for allowing people to create stuff, sell it, let others modify it, collaborate on it….all the things that Creative Commons purports to do but, well, doesn’t.
I’ll set aside the baseless (and frankly, irrelevant) jab at Creative Commons, and get straight to the point: No. Copy/mod/transfer isn’t as close as you can come to an ideal system. In fact, SL’s permission system has a variety of identifiable flaws and quirks that have plagued both consumers and creators for years.
- It’s too coarse. Where’s the permission to make prim hair recolorable or resizable, without letting everyone see the prim parameters? Or the permission to allow someone to only transfer an item back to the creator, so it can be fixed, exchanged, or refunded? What about the ability to have a no-copy/transfer gift box with an item inside that becomes copy/no-transfer when you take it out?
- It’s quirky. Did you know that for animations and sounds, the “modify” permission doesn’t actually let you modify them? It just lets you use them in gestures. Weird, right? And that “faux-modify” permission is so firmly established that LL would have to add another modify permission just to let people actually modify them, e.g. to adjust the priority level or hand poses on animations.
And see if you know the answer to this one, without looking it up: If you have a full-perm object with a no-modify script inside, are you allowed to reset the script? How about if the object was no-modify, but the script was full perm? Even after 3 years of building and scripting in SL, I’d still have to check to be sure.
- It’s a hassle. Part of my job is making backup copies of collaborative builds, and this inevitably involves hours of checking permissions and calling in the builders to fix them. In one case involving many builders, the task of getting them all to fix their perms took a week, when the actual work of making the backup took only a few hours. In a few cases, we’ve had to discard entire sections of builds because we couldn’t afford to have it taking up space and prims for several more days while perms were fixed.
You could argue that, being professional builders, they should have been more careful about perms in the first place. But that’s denying human nature: people forget things if they are not reminded. It’s this same human fallibility that Dusan offers as a reason why people must be protected from themselves by restricting their ability to choose their own default permissions. (I, on the other hand, offer it as a reason to have better reminders, and warnings where appropriate.)
Store owners too have to deal with permissions for everything they sell, and they too can make mistakes. Setting the wrong permissions on a product can cause all sorts of headaches. If the permissions are too restrictive (more so than advertised), then customers will complain. If the permissions are too open (particularly if they are copy/trans), the product might “get loose”, being passed around for free or sold by other people, potentially reducing the store owner’s ability to profit from the product.
Despite this issue being so important, it’s only within the past year that tools to more effectively manage permissions have begun to appear. (And I find it somewhat amusing that an optional tool to help content creators avoid permission mistakes, is being attacked on the grounds that it could encourage content creators to make permission mistakes.)
Indeed, SL’s permission system has been the subject of widespread criticism for years — by creators, consumers, and even Lindens! — precisely because it’s not all that great at the things Dusan thinks make it ideal.
C/M/T is what it’s all about kids: it’s Little Big Planet but with the right to sell your levels to others; it’s The Sims Online but with a wider range of avatars; it’s Facebook, or Twitter, but instead of little game widgets or bloggy haiku the whole PAGE is your own, and you can sell every bit of it, every photo, every poke, every status update, every font if you want and not turn around at the end of the day and find out that the platform owners, well, OWN it.
C/M/T built Second Life, C/M/T powered what must be the largest micro-transaction economy in the world today, C/M/T powered the ability to sell and buy stuff for fractions of a fraction of a cent if you want, C/M/T is what filled my inventory with 15,000 objects called, um, object, but they’re MY objects and I’ll organize them if I want to.
There are two big, leaky holes in the bottom of that argument:
- Linden Lab, the platform operators, do “own it”. Creators retain intellectual property rights on their SL creations, but the Lab owns and has control over the data. Can you really say you own your SL assets, when LL can delete them or restrict your access to them (i.e. ban you) at any time? Builders in particular lack a convenient way to create backups of their creations, and until that’s resolved, I’d argue that in practical reality, they don’t really own their creations.
- It’s a mistake to think that the only possible alternative to C/M/T is not having any content protection at all. C/M/T is not the only — or even the best — content protection scheme possible. And it’s silly to assume that Second Life would have been crippled if it had a different scheme. Indeed, I’d argue that the SL economy would be even stronger today if SL had been designed with an easier to use, more robust, more fine-grained permissions system than C/M/T.
Yes, counterfeiting CAN undermine the business. And that’s what this is all about – whether the Lab will actually protect content, or just give it a glance and move on. But there is enough protection in Second Life that it’s a damn good start: all content MAY be copiable. But the combination of good policy, strong enforcement, and reasonable uses of technology to counter it can all go a very long way to curbing theft to a minority.
Now, here’s a point where I agree, albeit with some reservations. The general consensus among those in the know about such things, is that perfect, unbreakable DRM technology is a theoretical impossibility, due to the so-called “analog hole“: if you can see (or hear) it, you can copy it. The only way to be sure no one can copy it, is to never show it to anyone. But, even so, it is possible to use technology to make it harder to copy. SL does this, and I think that can be a good thing, in moderation. (Past a certain point, it just tends to become annoying and disrupt legitimate use, though.)
SL’s permissions system is an example of DRM and content protection done in a mostly sane, if somewhat flawed, manner. Trying to apply more technology to prevent illegitimate copying in SL would be, in my opinion, treading into the realm of “annoying but not that much more effective”. Rather, I think the proper area to apply technology to, is the detection of illegitimate copying. For example, tools to objectively analyse textures and objects for similarity could be useful for detecting simple rips.
However, SL’s main problems in this area are weak policy and minimal enforcement. LL deals with takedown requests enough to satisfy the requirements of the DMCA, but the consequences to offenders are weak: the content is usually removed, but they can just re-upload it the next day. LL has not taken the initiative to define its own, more effective policy.
Open source isn’t much different than a quilting circle or a barn raising. A community comes together, everyone brings their own tools and time, and maybe they help build a new church or whatever: the whole community benefits, everyone who bore a hammer feels good about themselves, we can all take pride, and the world advances towards being a little more civil.
The problems come when Joe shows up to help out and hopes to get hired as a woodworker the next day, or the church is built on company-owned land, or Pete wants the cost of his nails reimbursed.
See – C/M/T, the permission system in Second Life, helps to solve a lot of that. You can still do stuff for free if you want – but you’d better know that you’re doing it for the right reasons, because more often than not free is nothing more than a cheap advertising ploy that makes you look more like WalMart than Tiffany’s.
So, Joe has unrealistic expectations, the church-builders don’t understand property rights, and Pete doesn’t know what “volunteer” means? SL’s permission scheme doesn’t help any of that one bit. Nor does it stop the SL content creator who deliberately gives out freebies in a dubious attempt to bring more paying customers into their store.
Those are all “wetware issues”, and SL’s permission system doesn’t address any of them in the slightest. And there’s no reason to think that new tools to help manage permissions would make people more (or less) likely to act foolishly or have poor understandings of the permissions system.
There’s this JIRA out now that argues that the mechanics of setting perms should be changed so that it’s EASIER to make choices about the stuff you make.
Let’s say you’re a builder working on a team – you need to transfer your stuff back and forth, it’s just easier if it’s all full permissions. So the JIRA proposes that you should be able to toggle your default permissions: turn it to “Full permissions” or “Transfer Only” and leave it there. Avoid the hassles of having to remember that every prim you rez needs to be changed from its default, avoid all the complications of resetting them every time.
The support for the JIRA is support for choice, and choice is hard to argue with.
This is actually a decent summary of the JIRA issue. It is about choice. But the choice isn’t a simple toggle between “full perms” and “transfer only”; it gives much more fine-grained control than that. If you want to keep your creation permissions as transfer only, you can do that. Indeed, that’s the default, so you don’t really have to do anything at all. If you want to choose modify+transfer, or modify+copy, or copy+transfer, or copy only, you can do those too. And yep, if you want to, you can even choose full perms.
Somehow, though, the fact that full perms is a possible choice has got some people gnashing their teeth about freebie culture, and predicting the downfall of the SL economy, or even capitalism at large, if this feature is implemented and people are allowed to make their own choices. (How curious that capitalism, a system based on the ability to make choices in a free market, apparently needs to be protected from the ability to make choices in a free market!)
Of course, all that freebie obsession and doomsaying is utter hogwash. It’s just unfortunate that someone as intelligent and thoughtful as Dusan could be taken in by it.
The current C/M/T system is, in fact, the ideal ‘nudge’, and is one of the hidden choice architectures within Second Life that makes it what it is: it nudges us towards the protection of content but still allows us the choice to change it.
The C/M/T perm system is a choice architecture based on the realization that we are not all rational actors (and especially not when we’re new to Second Life). It’s a nuisance at times, infuriating at others, but even for someone like myself who has rezzed his share of prims, I STILL need the ‘nudge’ of changing those perms so that I make the conscious decision that they should be changed.
That’s fine. I can understand the concern about setting your default permissions and forgetting about them, then creating some product and releasing it with the wrong perms. As I said, people tend to forget things, especially if there aren’t reminders. I’ve suggested some enhancements that would reduce the opportunity for forgetfulness (display an optional on-screen reminder of your current permissions), and limit the consequences of forgetting (allow permission settings to optionally be set only for the current session).
But those enhancements can only be made if Linden Lab implements the base functionality. And there will likely be a period of time when only the base functionality is available, before the enhanced versions make it in. So I’ll offer this advice for the meantime:
If you’re worried about forgetting that you’ve changed your default perms, then don’t change them.
No one is forcing you to use permissions settings that you don’t want to. The initial default permissions will still be transfer-only. If you don’t want to change that, then don’t. Just leave it alone, and it will be the same as it has been for years.
That’s your choice, and I’ll let you make it. So please, don’t tell me that I shouldn’t be allowed to make my own.
