At risk of introducing feature creep, I'd really like to have user-customizable "presets" as well, so that I could easily switch back and forth between different permission schemes. For example, when doing a collab build, I could change to my "Collab Mode" preset. Then when I was done and I wanted to work on a mod/copy product for my store, I could change to my "Mod/Copy Mode" preset.

Otherwise, the usefulness of this feature would be limited by the inconvenience of having to set all of the perms every time (not to mention having to stop and think about what they should be set to).

• The Open Source objects could become much more common. Currently it is a pain to "liberalize" the rights for every prim and script you create, and this is discouraging Open Source creation.
• The sellers could win time by applying their preferred Copy/No trans or No copy/Trans model from the very beginning.
• The professional builders could work in teams much more easily by having the "shared with group" flag activated as a default

I intend to work on a patch. As I only worked on easier patches so far and I lack experience, every good will to work on this project is welcome. One big question is also if it is possible to code that without having access to the server code.

Anyway, this comment is simply a 'yay Catherine!' Thank you thank you!

Okay, I had a first quick glance at the code. The "Create" pie menu is handled by code in linden/indra/newview/lltoolplacer.cpp. This code builds an ObjectAdd message which syntax is explained in http://wiki.secondlife.com/wiki/ObjectAdd , and then sends this message to the region. Unfortunately, this message details all geometrical characteristics of the new object, but not its permissions.

So the bad news is : as far as I understand, when the server receives that message, it creates an object with default "egoistic" permissions.

From that point on, I can see two solutions :
1) modify the permissions of the object just after it is created
OR
2) change the syntax of the ObjectAdd message to include desired permissions

The second solution seems to me a lot cleaner and robust. But it requests a change in message syntax and recoding on server side. I don't know to which extent the Lindens are open to such suggestions, nor whom we could contact at Linden Labs to suggest that change.

Any clue ? Any suggestion ?

I also received advice to open a SVC issue ( SVC-3046 ), and to link it to this VWR issue. After all, it becomes both a server and a viewer issue if the lindens accept to change the protocol.

Yes, Lex, you are right, I can work on the XUI part in a way that does not depend too much on the #1 or #2 way to implement the solution.

Criticism:

1) This is currently for objects only (not notecards, textures, scripts...). This is better than nothing, though.

2) The implementation uses new flags in the "ObjectFlags" field of "ObjectAdd" message. Perharps Lindens would prefer to add new fields, or to use different values than the ones chosen here.

3) I did it the simple way - no "presets" to choose from as Jacek suggested.

4) As already said, this implementation fully relies on the Lindens accepting to patch the server side as well...

Hope it helps though. – Cathy

http://www.ipetitions.com/petition/secondlife-4freedom/

Oh and for our group this really isn't a minor issue with low priority. We do our bes to keep everything free on our land and that really is not an easy task, to put it mildly.

Personally, I tend to love simple user interfaces. I don't think there is a problem to apply the same defaults to all types of items (scripts, textures, etc.). There could be an exception for notecards, which are by nature copy/mod/trans. Or the defaults could be ORed with type-dependant flags. Like a UNIX umask, with the difference that the UNIX umask is basically a AND, not a OR.

But a grid of checkboxes is okay too.

In any case, before we start thinking at applying the defaults to other item types, or any other enhancement, I'd like to get some feedback from LL about this proposal.

I'm a big Creative Commons fan, but I wonder about the potential for inadvertent over-permissiveness (and thus, theft) by changing the perms at such a high level (for everything you build).

Do you think an inventory-folder level bulk permissions tool might be close enough?

It's not just a matter of customization, either. There's also some really great features that can be built around it. For example, permission profiling. Imagine going to the tools floater and setting a profile to "group build" so every box you create is shared with group and full perm. It would save so many headaches.

We could already have patches on here for that, if LL commits to the necessary server-side changes to allow it.

They're not related.

If I have misinterpreted you, please let me know.

PS: VWR-5082 would work for people who are making in-world items, but things you make in Appearance mode or in your own inventory (eg clothing, body parts) will be unaffected by it.

VWR-5082 will be great for builders, don't get me wrong! Just don't think of it as a solution for this JIRA.

We would like to be able to set our preferred permissions model for all the time we create objects. With VWR-5082, we would have (again) to fix the permissions AFTER having created the objects, and that's a tedious task if you build a lot. And there's always the risk to forget some of them. That would be easier than it currently is, but we would still have to do it.

There is no risk of over-permissiveness as the default would not change : by default, people would build unmodifyiable, uncopyable, untransferrable and unshared objects, as it always has been the case. Only the people who explicitely set other default permissions would build objects with different permission schemes (freebie, creative commons, open source, copy/notrans, nocopy/trans, etc.).

On the contrary, when you have to change manually the permissions after the objects are created (either with the current dialogs or with VWR-5082), the risk of making a mistake is greater, thus leading to "theft", as you call it.

In short : by default, nothing would change, but people would have the opportunity to choose different creation models. And that includes vendors who sell copy/no trans and nocopy/trans - people who certainly do not give away their objects easily .

Will it be the default for bulk permissions change, or the default for newly created object?

The default for bulk permission change is NOT interesting. Changing permissions afterwards is a correction
for bad defaults, not new defaults.

I don't really care where this functionality is. It could be a settings dialog accessible from the Tools menu,
for example. This way, it would not clutter the precious Edit => Preferences dialog.

Where I agree is that the "defaults" for bulk permission changes and the default for newly created objects
could use the same set of settings stored in settings.xml.

Could you make more precise what this "make default" button would exactly be? If it is a default for bulk permisson changes it does not answer this JIRA.

Erica:

If I understand the 'bulk permissions floater' correctly, that will be a dialog that appears when you edit a particular object. I think you're suggesting that you add a checkbox to that dialog, that will make the permissions set in that floater, the default permissions for all new objects created during that session.

Honestly, I think that's bad user interface design.

In all other ways, that floater affects that one object and all its contents.
In this one way, that floater would end up affecting every object they create for the rest of the session.

That breaks the principle of predictability. It's not a predictable part of the user interface, and it's not in line with the user's mental model of what's going on. (The user is thinking of this floater as applying to the one object and all its contents.)

If you're going to add the functionality of allowing the user to set their own default permissions for all new objects that are created (and please do!), it'll need to be in its own dialog; for the sake of predictability and the user's mental model.

The menu or dialog entry that calls up that dialog doesn't have to be under Edit->Preferences. In fact, the more I think about it, the more it makes sense for it to be in Tools or Advanced.

Yes, very good idea!

Seshat:

The bulk permissions floater would change every object you've selected, like the current "reset scripts in selection", if I have understood it well.

About predictability : I think that Erica meant a button "Make defaults" limited to the bulk permissions dialog, not for newly created objects. The design mistake is mine.

What about this solution? in the bulk permissions dialog, add a "Use defaults" button (instead of a "Make defaults"). And what defaults would it use? Precisely the defaults for newly created or uploaded objects that we are speaking about.

Like the previous patch (the one for the "Edit" menu), it mainly does the User Interface part. The transmission of the correct permissions to the servers is still rudimentary.

Coco:

I have also started writing the code to support the default permissions for uploads. However, it looks like it won't work because NewFileAgentInventory capacity has no field for permissions. Is this a correct assumption? (reference: upload_new_resource() in indra/newview/llviewermenufile.cpp).

Like you, I also looked at hooking this into the bulk uploader where the pain can be huge, and I discovered the same thing that you did. Unfortunately there is currently no provision for specifying initial permissions on resource upload. We should definitely change that but to avoid complicating things, it'd be best to do that back-end work before the front-end which means that it will be a very long time before it becomes publicly visible.

If you can find some other content creation cases where your new preferences could be applied, then I could argue for including your preferences and associated UI. People might argue against it on the grounds of an incomplete pattern, but I think it could fly even if it initially only applied to one big pain point. There might not be any such content creation cases unfortunately.

The SL permissions system is a scary, hairy mess and because it is so critical, people are often afraid to touch it. I believe that we need to touch it because it's messy and important. I also think that work like yours can make clarifying improvements if done well, so don't despair. Note also that the LLPermissions class in indra\llinventory might be the more appropriate system to use over indra\llprimitive\object_flags.h stuff but I honestly don't know.

I think there is strong builders support for this patch. Coco, I am glad that for the first time, someone at Linden Lab too shows support for it, that's very encouraging. Thank you.

At the risk of repeating myself, I think we need BOTH bulk permissions correction AND settable defaults. Both patches do not oppose, they are complementary.

Erica's point that Edit => Preferences is not the right place for this feature is perfectly valid, since that dialog is end-user-oriented and not builder-oriented. After all, the grid settings (typical build stuff) are in a separate dialog too. On the other hand, a central place for all settings is something towards all modern systems go (think at Windows, KDE, GNOME, MacOS, etc). My personal taste goes for Edit => Preferences too, but my tastes do not count here. That's why I have provided TWO user interfaces (two patches and two screenshots), one for the Edit menu, the other one for the Tools menu. You Lindens choose.

Regarding the "no provision for permissions" in the NewFileAgentInventory capacity: I am not 100% sure that there is really no provision for it. After all, there WAS an NextOwnerPerms field in the old UDP NewAgentInventory message, and if I have understood well, the new capacity system is just a transposition of the old UDP messages. Yes it does NOT work if I add
body["next_owner_perm"] = ll_sd_from_U32(next_owner_perm);
but maybe I have done some other mistake elsewhere.

Regarding LLPermissions versus object_flags.h: I was using the latter because that's what the CreateObject message (sent when creating inworld objects) already uses. But honestly, I really don't care what flags we use and where they are defined.

Coco, you are encouraging me to continue with the end user part as much as I can while Linden Labs has its internal debate. Okay, here is my patch for the "upload inventory" part. It can be combined with either one of the two previous patches (edit menu or tools menu UI).

Thanks so much for that "upload" part of the puzzle!

I suggest a few small ameliorations. See issue VWR-10854 for details.

This patch does not set the "share with group" and "can be copied by everyone" flags correctly. To do that, some server-side work would be needed, to handle the "everyone" and "group" masks when received a "CreateInventoryItem" message. I have marked with TODO comments the corresponding locations in the client code, for the day that we want to fix this.

Enjoy.

Here is a summary of current patches:

• permissions-edit-menu.patch: user inteface for setting the defaults in Edit => Preferences
• permissions-tools-menu.patch: user inteface for setting the defaults in Tools => Default permissions
• inworld.patch: setting default permissions for objects created inworld
• upload.patch: setting default permissions for uploaded textures, sounds and animations
• inventory.patch: setting default permissions for items created whithin the inventory (skins, notecards, jackets, gestures...)

All three inworld, upload and inventory patches would need some server-side work, which I cannot do as an external contributor.

There might be some cases of content creation that I might have overlooked, like creating clothes and body parts from the appearance mode, or creating scripts from the objet edition contents tab. But I suppose that it's not really harder to do than what I did so far, and of course I can continue contributing the corresponding code if needed.

The new patch uses the capabilities system.

from an open/interop perspective, we should make sure the OpenSim folks are tracking this too.

and as a software architect, my initial instinct is to cast this feature as a concrete example of a larger design pattern... but more on this later.

thx for changing this to capabilities, catherine!

If you read "inworld.patch", you'll notice in my comments that I have doubts about my implementation: is it still needed to "pack" the ObjectAdd data like we used to do with the binary message? Can't the volume information be sent "as is"? In any case, that's just implementation details, I'm sure that the message specialists at LL will have strong opinions on this .

Completly unrelated: I have updated the two UI patches to resynchronize them with the latest source code. I have also added "OK", "Cancel" and "Help" buttons in the "tools menu" patch (see updated screenshot) by stealing^Hcopying Coco's code.

The old UDP ObjectAdd packet was divided into two sections : "AgentData" and "ObjectData". "AgentData" describes the avatar who creates a prim, while "ObjectData" says it's a cube or a cylinder, etc. On the opposite, "inworld.patch" used to put all the data in one big single map, without consideration for this separation into two sections.

I have attached a new "inworld.patch" that solves this problem and produces non-flat packets. I have also changed the field names to be written in CamelCase.

Thanks to the person who reported the problem.

The inworld object creation works with latest version of OpenSim.

I have been able to create a cube with "share with group" set in advance in the defaults, or with "let anyone copy", or any other flag. Technically, it has been hard to do, because I could not show my source code to them for legal reasons.

I'm currently working with Coco to get it to work on SL servers as well.

Particularly with CAPS, probably the most helpful thing that someone can do if they want to work with us in implementing a feature is send us an XML dump of the output of the cap along with the CAP name and a description of what it is intended to do.

Since we can't look at the code itself, we must use the output to figure out what the servers should be reading. Great work catherine!

I wonder if this shouldn't be a parcel property. Wouldn't this be much more helpful for group build?

Also, batch permission change could be enhanced by implementing SVC-3551

One of my pet peeves is forgetting to set the right group tag prior to building and having my stuff auto-returned to me. It would be nice if my objects would inherit the land group (if I'm a member) - and once you start doing that, it is fairly natural to also define the build policy on a per parcel level.

Anyway, we'll likely be doing user preferences first...

I've actually had that problem on my mind lately, CG. My current solution is to have the viewer inform you whenever you open the create tab and don't have the right group tag on, but that doesn't really solve the problem of rezing from your inventory. Curious if people would find a text notification when you enter a sim too spammy (if even one just for sims that have autoreturn/group build only enabled)?

Concerning your idea of land-specific permissions, I think this is an independant problem from this Jira. I think it deserves a Jira of its own.

I have added a safety question to the user interface, with texts in attached file "safety.txt". I have added real-life examples to the safety questions to make the choices more concrete, because I think that permissions can be felt as something very abstract by end users. As English is not my mother language, I suppose that those texts could be improved, of course. Any comment welcome.

Finally, I have added a "help" button to the edit => preferences proposal for user interface, and resynchronized all four patches with current upstream code (version 1.23.0, release svn 1776).

I'm not sure I understand "I've got UI waiting for this", McCabe. Are you building an alternate viewer with my UI patches? Are you proposing another UI implementation? In the second case it would be good to attach it as patches to this issue. Please give us some context .

And yes, it's good to see things are going into the right direction .

The default permissions systems help newbies in particular from obtaining acknowledgement, respect, and value out of their creations and keeps the connection between creativity, commerce, and intellectual property that is at the heart of Second Life.

The default of copyright law in the real world is that your property is yours, and you need not register it. You do not need to add on misleading and fake Creative Commons licenses to claim and defend copyright which is law.

Therefore it makes eminent good sense in the virtual world to have property rights default to visibly illustrate intellectual property, and codify the social injunction against theft that has been so eroded online by copyleftism and the "analogue hole".

There is ample opportunity to set all the flags to give-aways of your object completely without having to impose your ideology on the entire world.

This is a perfect example of how under the false guise of "choice," copyleftists impose coercion and non-choice.

I'm particularly annoyed that the author imagines the Lindens are liking this and working with her to implement it by going around the rest of the content creation class and the entire community of Second Life and portraying this as a done deal.

Erica Linden is absolutely right that this codifies and legalizes theft as the default, and utterly destroys private property as a concept and as a fact of the economy by making it instantly possible, and all under the guise of "freedom of choice" for a tiny handful.

Creative Commons licensing MUST NOT be welded into our world as it takes away the living connection between creations and commerce. Note how when you actually poll people about their attitudes and uses of Creative Commons, a very decided minority claim to make a living by giving everything away, and CC is unuseable for most people precisely because its makers refused to incorporate sale of copyrighted items and micropayments into the concept:

http://www.ask500people.com/questions/do-you-use-creative-common-licenses

I'm awfully glad this train wreck got avoided by the happenstance of Coco Linden leaving the Lab, but this raises several questions. On the one hand, why is one resident representing a tiny lobby able to railroad through changes into the viewer by writing ideologically-driven patches and pushing them through the fake "triage" of a handful of people showing up at a meeting, and getting it in just because a few Lindens are enthusiastic? (Certainly the bottom-line top management Lindens haven't obviously seen where this is going in terms of destruction of product value). Conversely, if something is decided "by Linden Lab," how can it be undone by just one person leaving? What's up with that? Why this very idiosyncratic and subjective approach about matters affecting the entire community?

I won't argue your ideological concerns. Let me just stress again that this option will benefit the commercial vendors too.They are able to choose between copy/no transfer or no copy/transfer. It will benefit team builders too, who will be able to set "shared by group" from scratch.

OK, you're voting against it. We took note. 95 people already voted for it. And I must tell you that first step (being able to set permissions on uploaded textures, sounds and permissions), which is available in 1.23 RC, has been acclaimed by many builders as a way to make their lives easier.

Prokofy, please, if you don't want this feature, don't use it. But let the other people have the choice of their preferred permissions model. Nothing forces you to use it.

Can we include the quasi-permission "free to copy" in this while we're at it?

Commercial vendors will be the judge of whether this "benefits" them and so far, I don't see them informed or voting on this, as per usual when a small group tries to hijack the JIRA with a minority view.

Most vendors are perfectly fine with the default to all permissions holding, and prefer to opt IN rather than opting OUT of copyleftism, as under your plan.

95 people who voted against it with an opensource agenda isn't meaningful whatsoever. I don't see any of the names of the top content creators of Second Life. And 95 of anything on any issue means nothing for a world in which 1.5 million people log on every month with 80,000 top concurrency now.

Um, your "must telling me" about something already rammed into the viewer on textures, which are the most widely stolen artifact of SL, doesn't mean we should continue the expropriation further. And I don't see any actual acclaims, except from you, with an understandable political agenda.

Catherine, you're the one who needs this lecture: if you don't like copyright, set all your stuff to no permissions. But don't impose this on the viewer for an entire community so that they are forced to opt out each time in order to protect their IP.

There isn't anything "easier" about this campaign except theft – which is already too easy in SL.

The current implementation of the "in-inventory" creation patch does not set this flag correctly. All other patches (upload, in-world creation) do it correctly. The in-inventory one would need some more work, I guess.

The "per parcel" mechanism was only a suggestion. So far, all patches work on a per-user basis, which does not present the same security concerns as the per-parcel version.

If you choose to do nothing, the permissions for uploading and creating are exactly as they are today. It is only if you choose to change the defaults, or opt-in, that they change.

So while that sounds at first like a great concept for a tiny minority of builders who want convenience, and an even tinier microscopic group of those who wikitarians who take part in collaborating building projects (who shouldn't be allowed to set the entire agenda for building and group tools anyway), in fact it has system-wide repercussions that in fact set people up to make bad choices forever and lose their work and the right to make money from their IP.

One of the repercussions we've seen in discussions on this is Catherine's demand that the Lindens change their "egotistical" server code. Sigh. By that she means the default to permissions. Andrew Linden responded by saying he could do this, but it would take changes in how the server reads objects.

I'll say. It would likely take changes that read all objects as having no permissions (unlike the current long-standing regime) and then added on to them only those flags set by this or that resident action.

If you think we have problems with a hacked viewer now and content theft, think of what it means to have the server code render every view of every object by default as having no permissions – until they are set.

I'd like to hear Andrew or another Linden tell us exactly what they'd have to monkey about with their system which is not broken for most purposes in the economy and how they plan on becoming better protectors of IP as a result – given their uneven track record on this already.

What this is about is a stealth-campaign to smuggle in the copyleftist agenda, which I see EFF is now flogging as well against SL, to try to "Liberate" the creations of SL.

It comes at a time when the economy of a digital-rights-management regime in VWs are FLOURISHING, especially in SL, so unlike the music industry, which copyleftists and thieves succeeded in destroying. So that's why the opensourceniks are now setting their sites on the SL copyright regime and chanting the same mantra as Creative Commons does, that you need "help" in "sharing" because otherwise you face "cumbersome restrictions".

The intent here is to shift the way copyright is thought of and acted upon, and to push people into "sharing" by promoting massive permanent changes under the guise of "choice".

When you are bound permanently by a one-time toggle, you are no longer in choice, you are in prison because then you have to constantly go back and re-do it.

Server code changes would be to the ObjectAdd messages, telling the server what permissions to create the object with, it is doubtful they would have no permissions until they are set.

For instance, I would likely set my defaults to "copy / no trans" as those are the permissions that I tend to apply to everything going to anyone else.

It should not be parcel-related certainly.

The average person will rez out an object for a friend, click it on all permissions to give it to the friend, but then...not think about how the next owner and next owner after that forever and ever have full permissions – and now he can't take them back. Ever.

We live in a world where masses of people keep making mistakes and setting land to sale for $0 even with four safeguards on the viewer to prevent this.

No one should be forcibly hog-tied to give up their permissions forever. This is the forcible codification of the Creative Commons shill with forces people to license their works forever, always, as copyable with credit, and then they can't get it back.

The chief purpose of this exercise is political, and designed to stop copyright from being connected to private property and commerce.

>Server code changes would be to the ObjectAdd messages, telling the server what permissions to create the object with, it is doubtful they would have no permissions until they are set.

Harleen, what was your plan, after you've set your dashboard to mass-produce "give away my stuff to the Freetard Republic 4-ever" and released it into the wild all perms, to go fetching each discrete rendering of that object and put back its perms?

Of course it extends to all your newly-created objects forever – and sure, you can change your mind mid-stream, but then you are stuck with all the stuff in the wild. It means you cannot take various objects and make them loss-leaders for short periods

I'd love to hear how that works. Kill files? Kill files that mass-produce, too? So far, we've done without that bit of creator-fascism in SL. Will this help bring it about as a corrective to the idiocy in this proposal "liberating" objects?

I don't trust hearing that "it is doubtful they would hav eno permissions untli they are set" from you – not after I've seen in fact interchanges suggesting that as a solution. I want to hear senior Lindens tell us how they will implement this, truly.

Oh! I can see another "lovely" side effect of this copyleftist scheme. The opensourcenik sandboxes will release all kinds of stuff that can now no longer be sold. You will be unable to take copyable transferable objects made copyable and put them on sale. There goes all those freebie weapons sellers!

Of course, some will love that enforced grab to crush the first sale doctrine and crush the free economy that they really should be encouraging because if they really want to help newbs so much, they should allow them to resell items. See, the love of freeness never extends to letting someone else make a buck ROFL.

Copyleftists and Stallmanites who constantly told us that we shouldn't be burdened by onerous copyright "obstacles" now burden us with forced-free obstacles, so that nothing can ever be sold or stopped form copying, say, after you modified it.

If the opensourceniks really in fact loved freedom, they'd welcome anybody modifying and reselling their works – and if they don't like that, they could put a price tag on them themselves.

I'll take this opportunity once again to say that the Lindens need to stop smuggling stuff into the viewers. Changes to the viewer need to be explained in advance in layman's terms with some senior Linden reviewing them as to how they impact the world and economy, without having junior coders put up indecipherable jargonistic blogs about their intentions or only talk about them in essentially closed workshops of technicians in their office hours.

Here Lindens are assigned to this, people are lobbying it actively and vociferously, and no senior Linden is grappling with how this harms the economy and whether people are adequately informed.

Actually I think that it is better to give people the option of building at a default copy/no-trans, rather than the current default no-copy/trans, as it means that people to whom one gives stuff, one can be sure that one can give replacements without issue.

If the creator changed the permissions to copy/mod/trans before giving it to the friend, that would be forever for that object, again just like it is today, but it wouldn't be itself change the permission for other newly-created objects; no change there either.

The only change to behavior would be for people who consciously went and changed their new-object default; your average user wouldn't do that unless he wanted to, y'know, change their new-object default.

You do bring up a good point, though; I've seen a few cases where it would have been nice to have a permission like "this should be copy/nomod/trans to the person that I give it to, but should be nocopy/nomod/trans to people that he gives it to". (The fact that you can't do this now makes certain kinds of affiliate vendors, although not others, impossible.) I wonder if there is a JIRA on that? Would you be interested in starting one? Although it would sort of complicate the permission system...

Again, this is exactly how it works now: if you give something away full-perm, then it's out there full-perm, and you can't take it back. The proposal in this JIRA doesn't change that in the slightest.

"The opensourcenik sandboxes will release all kinds of stuff that can now no longer be sold. You will be unable to take copyable transferable objects made copyable and put them on sale. There goes all those freebie weapons sellers!"

I'm not sure what you're talking about here; there is absolutely nothing whatever in the proposal in this JIRA that has anything to do with that.

Harleen, what was your plan, after you've set your dashboard to mass-produce "give away my stuff to the Freetard Republic 4-ever" and released it into the wild all perms, to go fetching each discrete rendering of that object and put back its perms?

If I have done this then my intent would be to give it away full perms and hence would have no need to go fetching them later. I like all the others commenting do not see how is this any different that what can currently be done, I create objects make them full perm and give them away?

Oh! I can see another "lovely" side effect of this copyleftist scheme. The opensourcenik sandboxes will release all kinds of stuff that can now no longer be sold. You will be unable to take copyable transferable objects made copyable and put them on sale. There goes all those freebie weapons sellers!

How would having the ability to set your default permissions create this "side effect", this change does not allow you to do anything more than you can do now?

The default permissions would be set in a UI widget where it was clear you were setting their default. The "default default" would match the current version. If a Resident finds that widget and changes the values then they would be responsible for changing the the final permissions per-object should they want them otherwise, or else going back and changing their defaults accordingly.

A few people might be momentarily confused and release some content with the wrong permissions, however the frequency will be low and the quantity and quality of such content will tend to be low (remember, under this scenario the affected Residents will tend to be newbies and not experienced content creators). Such minor theoretical risk does not outweigh the benefits of a powerful user interface that gives the SL residents more control and convenience. There is already ample room for people to get confused about their object's final permissions wrong when building in SL.

The only obstacles from LL for gettingt this done are:

(1) Everybody is really busy and no one else has been able to help with this effort yet since Coco left.
(2) The UI designers (such as Erica) are going to want the UI changes to fit well into the system and may request changes.

o while not now a regime of rezzing objects nakedly with no permissions, it certainly moves a half step closer to default rezzing of objects with no permissions, which is the goal of copyleftists, and already an opensim aspiration or even default (permissions are put as add-ons, and are buggy in OpenSim).

o it undermines the current philsophical notion of copyright as an inherent, metaphysical property that automatically defaults on every manifestation of every object by setting up a blanket override to be mass produced

o it opens up changes to the server code which I'm not hearing in fact are not serious: "The server currently assumes the default permissions, so they are not included in the creation messages from the client - that info would have to be added to the message, and the server would have to be changed to be able to extract it.:

Translate that out of code-speak, and it means this: while the server code currently recognizes that all objects inherently have all copyright protections just as copyright law in real life does, now, the server code will have to be changed/overridden/rewritten to create objects with a new state, which is "always and forever no permissions from this resident or group".

As I noted a number of times, the intent is to decouple copyright from objects and erode the DRM that already obtains in SL, and to due it under the false flag of "convenience" – that's the social hack, and that's what Andrew Linden and Infinity Linden and others can keep invoking endlessly.

>If I have done this then my intent would be to give it away full perms and hence would have no need to go fetching them later. I like all the others commenting do not see how is this any different that what can currently be done, I create objects make them full perm and give them away?

No. It's about mass production, and it's about changing the per-item default.

The way the system is now, the default is always and everywhere to all permissions on, always. That means that each time I make something, I have a choice. I can "liberate" the permissions – or not.

But with this mass permissions-in-advance maker, a one-time decision I make can then inadvertently be applied whether in fact I wanted it for the next creation or any future creation, or not. I'm stuck with a choice I made once. This is not only bad for newbies, who are endlessly invoked when tekkies need to invoke them (but aren't now), it's bad for anyone who makes a mistake.

The analogy is the use of the land menu, which you would have thought was failsafe, and in fact isn't, and if anything, paradoxically more safeguards have led to more percentages of mistake.

I don't see on what basis Andrew Linden can predict low incidence of failure when in fact nothing like this has ever been tried in SL or any other world.

Masses of people do not change the default file format of a word processing application. Why would they do that? The exotic uses that some creators would have to always make "PNG" default instead of "JPEG" are a minority use case.

I hope that Erica will keep plugging away with her correct response, which is this type of high-level permanent call is too prone to error and too blanket in its effects – I hope she will not be bullied by other Lindens in making the consequences of this clear. Among other issues, there is the problem of people understanding whether a box filled or empty means a property obtains or doesn't obtain.

When you give away a single discrete object now with all of its perms on, sure, you are stuck with a situation that now, someone can copy your object. But that's only for that one object where you did that. It's not for 100 different objects you made that day or in that group.

with this feature, new prims, scripts, textures etc, will have only the permissions the creator intends, one can choose to have the current default perms, or different ones, or even no perm at all (which would mean the thign can't be modified, copyed nor transfered, ok, there is that limit that prevents things being both no-copy and no-trans at the same time so just one of the two), this setting only applies to newlly created items and not pre-existing ones nor copies of pre-existing ones, if the permissions of an object is changed, those permissions stay with the object, this won't change the permissions of things already rezzed, won't change permission for things already in the inventory, and it won't change permissions for things that are owned by people not the creator. Each creator can decide their own default perms, and can change their mind after the item is created and change the permissions of the item, and they can change their default permissions again at any time they want.

The only difference from how things are today is that creators will have the option of specifying different perms before creating new items instead of needing to tweak the permissions manually after the items were created. People who like how things are right now, will not need to do anything, and people who rather it differently will have the option of changing it for themselves. There are lots of other things that are real issues to be bitched about, this isn't one of them, I believe you're complaining either because you're not understanding it correctly, or because somehow your mind is twisting your interpretation of reality, or because you enjoy antagonizing people needlessly.

My intuition, after all these years of using various computer user interfaces, tells me the above assertion about error reduction is very likely true. Similarly my intuition, after working with Second Life after all these years, is that the number of cases where people get confused by a default settings will be low – I'm optimistic about the general intelligence of the people using Second Life – I think they will be able to understand what the default permissions are all about, and if they have any confusion it will clear it up very quickly.

In particular, I think the argument that they will accidentally allow many days worth of content creation to go out with too permissive settings to be unlikely. My experience has been that people discover permissions problems in their content pretty quickly. The permissions as set will be visible while they edit the object, and they will be able to browse these permissions and change them prior to putting their stuff on the market – I'm confident that many content creators will browse these permissions settings to make sure they are correct, as they currently do already.

I should note that I haven't seen any of the proponents of this project promoting creative commons permissions. Catherine is the only person to mention them, but the context was in response to Erica's post about them, and were only listed an an example with many other permissions settings, including "no-copy/trans". All of the pro arguments have been about the technical improvements this feature would bestow: less error, more control, and convenience.

Therefore the "copyleftist agenda" issue is a non-sequitur in this thread, and appears to be a misunderstanding. I suspect this is why Catherine brought up the notion of "tilting at windmills". The meaning of the phrase, as I understand it is: "attacking imaginary enemies". Apropos in this case, as per the aforementioned thread analysis.

Erica is not at all mistaken about the Creative Commons tilt to this proposal, and the inherent pro-CC bias in this proposal, welding CC into the tools, instead of welding what pertains in real life into the tools, which is a default recognition of the inherent, intrinsic nature of copyright. You do not need to register copyright; it just is. CC erodes that by implying you "protect" your copyright with a "license" (something that is illegitimate); law protects your copyright, not "licenses".

The copyleftism inherent in this proposal is a forced-march blanket granting of permissions. This will be particularly nasty in groups, using group dynamics to browbeat people, if all group objects in a group I'm in are always and everywhere flushed out of their perms and to be rendered as permless. This is where the most collectivism and adverse effects will take place.

By making it possible to blanket-pre-set massive permissionless objects, LL will indeed be handing over the implementation of code of the Creative Commons shill – that you should forcibly always and everywhere distribute everything without permissions, and that this is mitigated by you having "credit" for your work, and that you should just "share" for the good of the "commons" – and no, we won't worry about how you'll get paid.

The beauty and magic of Second Life is that apparently even inspite of themselves, the Lindens arranged it for people always and everywhere to get not only credit for their creations, but payment for their creations by being able to lock the copy/mod/transfer permissions.

Oh, I trust in the inherence of the SL resident, too. But even I have been surprised by how numerous the mistakse are with the menus on the land now, which, as I keep saying, has 4 failsafes to prevent $0 sales. And that suggests that the more widgets you force the resident to "find" or that you provide for the resident to "find", the more mistakes. The less widgets/menus/choices, the less mistakes, in fact.

Also, Andrew, you need to realize the context of this discussion:

1. Techdirect flogs the idea that SL should never have instituted copyright protections in the light DRM that it has, with copy/mod/transfer (http://www.techdirt.com/articles/20090501/0154374713.shtml) This author is making a forthright frontal assault on copyright protections in SL and wants them completely removed as he believes they only create "troubles" – this is the usual CC/opensource shill, that copyright "restricts creativity" or "places needless burden on the user". But we know in our context it does no such thing, as "no transfer" works marvelously in a digital world in ways it can't seem to work on email, websites, or in the physical world.

2. EFF is also campaigning now against copyright in SL, invoking a fake chimera of too-burdensome copyright bids from people allegedly prepared to make claims about screenshots and machinima automatically violating copyright unless you get permissions. This is utterly fake, as there is no such call in SL, it's a lawyerly fiction, and in this case, not mounted by conservative lawyers but "progressive" lawyers to help undermine what is a growing successfuly microtransactions commerce based on DRM that in fact annoys the CC gang no end as it goes against their commerce-free, no-sale policies.

3. Into this context with several parties very obviously lobbying for removal of copyright protections in SL comes Catherine, who flogs the idea of her perms because she is already on the CC and opensource bandwagon, and says, "We must have this patch to remove the burden of overly protective copyright".

4. While the setting of individual objects is error prone, it is immediately rectified on the next object, because you start afresh with a protective default. Not so blanket settings, especially in groups. You can't change your mind. Group objects of course are already a murky area of property rights.

5. Copyrightism and CC are not at all non-sequiturs to this thread, but form the robust substrate driving the ideology of the patch; it's merely flying under the flag of convenience of "builders' convenience".

I totally get how it works, as indeed anyone with a high-school education would probably be qualified to do in this day and age. You're simply not getting the larger conceptual issues and the contextual issues, that's all. Not surprising, as literalism and head-down-on-the-code is usually the mode here.

When one talks about "only the permissions the creator intends," that implies that there is this huge mass of creators just dying to free all the content up, to "liberate" it, like digital latter-day Che Gueveras.

But there aren't.

There's a small sect of coders/builders who a) have very ideological ideas about how "information wants to be free" and b) can rope in a few more people around that idea by peer pressure, and the false flag of "builder convenience".

The "convenience" of Second Life in fact isn't what you say, blanket permissions mass-produced, the "convenience" is that always and everyway, "always on," there is intrinsic copyright protection, that only if you consciously undo it, can you defeat it, checking off boxes.

That has insured that unlike the rest of the rampant criminality of the Internet, Second Life respects private property – inherently. It promised a way out to Web 3.0 that would leave behind all the destructiveness and loss of value that occurred with 1.0 and 2.0 because engineers simply wouldn't code for commerce and value, but kept coding for collectivist ideologies.

Duh, I get it that things already created before this patch remain unchanged; and that duh, the creator doesn't have to "find the widget" as Andrew so illuminatingly put it.

But it is destructive nonetheless, in implicity encouraging the Creative Commons mania which is based on a basic false preaching: that you can make money by giving things away for free, and that creativity is encouraged by constantly sharing things for free.

It isn't. And Web 1.0 and 2.0 and the fate of everything from music to newspapers ought to tell you that, if you won't listen to it on my little poll, where the Big Lie of Creative Commons is exposed daily.

A creator cannot change their mind about items already mass produced with blanket permissions, just like they can't change their mind on an individual item. What it does is fill the world up more with devaluating freebies cluttering inventory and the Lindens will have only themselves to blame as they put in this feature and watch two immediate direct effects: a) groaning asset servers from more freebie content mindlessly distributing b) devaluation of the Linden as more and more freebies fill up the economy.

Creative Commons has not led to the creation of a class of people making money from their content; it has only led to the impoverishment of the creative intelligentsia and the sense of entitlement from the masses.

The act of mass production moves from the era of craftsmenship to convey-belt production without much thought for the consequences, especially for groups. The spread of group-created objects might at first seem a boon, but I guess they've never been in a group build project where somebody got mad and then used their group powers to delete the build that everyone thought was the group build. Groups never really function as perfect collectives as that's propaganda; what really happens is that one or two seize power, unaccountably, and become the group caretakers.

If you can't see these higher issues, I fully understand, many things I say are pitched too high over other people's heads, and they are forced, in their cramped notions, to then charge me with "mental illness" or "griefing" or "stupidity." That's fine, I'll use any opportunity to keep whacking at the evils of Creative Commons and I don't want to see it welded into the tools in Second Life as it destroys value.

I know about the issues with "share with group", someone that for some reason I don't know was in the group that owned the land I was using stole 1000L$ (might seem little for people with commercial stuff in SL or that can afford buying L$ with frequency, but that money was from and for newbies) by taking advantages of a donation thing that was set to the land group to not be auto-returned, and after couple of support tickets and a long wait the Ls didn't do anything about it

in most situations people would leave "share with the group" disabled on the defaults and only turn it on on individual objects that they intend to share with the group. I myself intend to make my defaults be +mod+copy+trans but not "free to copy" nor "share with the group", this way only people I give the items to would have it, and I would check perms as I usually do before transferring things I create or putting them for sale, and specially if it is somthing for sale I'll probably send it first to an alt or someone i can trust to confirm the permissions are working

people can already be pressured into releasing their stuff full perm, or setting it to the group or whatever, there wouldn't be any change.

Each person will have their own default, which by default will be the same perms things are created nowadays, those that want change their defaults can change them, those that don't want, don't change them, and if they're pressured into going against their will, they should file an abuse report and move away from the griefers (and perhaps also get mental treatment since one shouldn't cave in so easily under peer pressure to loose profit or go against one's ideals)

Prokofy argues:

[1] A leftist agenda exists to coerce people to release their copyrights.
[2] People will profit (fame and value) the most if they retain their copyrights.
[3] This feature does not change the permissions possibilities.
[4] This feature makes it very easy for people to relinquish their copyrights.

Prokofy's conclusion looks something like:

This feature is bad because it will cause more people to accidentally lose their copyrights such that they lose value and this will help devalue copyrights in general.

Most everybody else argues some subset of:

[3] This feature does not change the possible permissions.
[5] This feature makes it very easy for people to set the permissions to whatever they want.
[6] For convenience it should be as easy as possible for people to set their permissions to whatever they want.
[7] There will be fewer mistakes if it is easy to control their permissions settings.

Nearly everybody else would conclude something like:

This feature is good because it will make permissions easier to control.

Note how self-selected respondents to a survey essentially never give one a representative sample, and how strawman arguments are worthless.

@Dale : you are perfectly right. That could have been a valid client-side implementation technique. We even mentioned it as an alternative at the very beginning.

But I decided not to follow that way because it was ugly from a technical point of view. Instead of fixing the permissions AFTER an object had been created, it was much cleaner to declare the correct permissions RIGHT AWAY, in the ObjectAdd message. It also made one datagram less sent to the server.

Of course, I did not realize at that time it would take several months to have the server-side patch written. As a comparaison, it has been implemented in less than one hour in OpenSimulator...

Andrew wrote:
> A few people might be momentarily confused and release some content with the wrong permissions,
> however the frequency will be low and the quantity and quality of such content will tend to be low

Please also see the confirmation question that I have added to the UI patches. You can see it in the screenshots. The user is warned about the consequences of changing his/her defaults. This should reduce even more the newbies errors.

> The only obstacles from LL for gettingt this done are:
> (1) Everybody is really busy and no one else has been able to help with this effort yet since Coco left.
> (2) The UI designers (such as Erica) are going to want the UI changes to fit well into the system and may request changes.

(2) Erica was right worrying about that. We did our best to make it fit into the current UI scheme. Coco's current version in 1.23 is limited to file uploads, and very logically the new menu appears in file => upload submenu. I proposed two other versions, built on top of 1.23, one of them is the one that did not make Erica happy and appears as a new tab in Edit => preferences. The other one appears in the Tools menu, which is perharps more adapted to a feature intended at builders.

(1) is more of a problem . Hopefully, it will go better once 1.23 is out and now that Andrew jumped in.

> Therefore the "copyleftist agenda" issue is a non-sequitur in this thread, and appears to be a misunderstanding.
> I suspect this is why Catherine brought up the notion of "tilting at windmills". The meaning of the phrase, as I
> understand it is: "attacking imaginary enemies". Apropos in this case, as per the aforementioned thread analysis.

Yes, that was my idea, we should not fight against imaginary ennemies. It was a reference to Miguel Cervantez' Don Quichotte who is so anxious at making the world better that he starts fighting windmills, thinking they are evil giants.

About conspiracy theory: I won't hide the fact that I am a big Open Source fan. But I also recognize that the proprietary model is important in Second Life and should be kept intact. I just want to give everyone the choice of their preferred model, just like in real life where everyone is free to choose the licensing model for the software they write. When this jira will be implemented, Prokofy will be able to create proprietary items and I will be able to create Open Source items from scratch. Prokofy will even be able to choose between no copy/trans or copy/no trans as his preferred default. Last but not least, team builders won't have to set "share with group" over and over again.

It's not about "making Prokofy happy". It's about respecting private property and the intrinsic connection between creative, property and commerce that opensource and Creative Commons – and EFF – are constantly trying to break.

You gave away your hand when you began calling the SL server "selfish". We'll leave aside the problem of how suddenly, machines became anthropomorphic because they appeared to "thwart your will" and realize that your characterization there illustrates that you view copyright as an enemy.

The idea that servers can be "selfish" in inherently protecting copyright, and keeping the real-life concept of intrinsic copyright intact is one that doesn't bother most people, and is a demonstrable good. That Andrew would have to monkey with the server code and change its nature to accommodate this entitlement-request from a minority is profoundly disturbing – because it's ideologically driven, and not science-driven, despite it being cloaked in all kinds of pseudo-science.

Key to understanding this flawed "science" is understanding that the argumentation "There will be fewer mistakes if it is easy to control their permissions settings" is a religious belief. In fact, the more widgets you add, the more mistakes you add as we saw with the land menu. The "safety message" is wordy and jargonistic.

Where this feature will be particularly buggy, contentious, and destructive is in group tools.

Andrew, if you want to play literalist here and ignore the context, that's fine, you'll live with the consequences then. And my argumentation illustrates that there are very pernicious and far-reaching consequences to this fake "boon for builders". Perhaps you find nothing alarming about "copyright in general loses value" and "some people will lose their copyright forever on some items accidently" as more blanket and mass decisions are made at a high level, but obviously these are far, far more destructive and wide-ranging than a builder being temporarily delayed by having to check off a box again.'

I'm not the one fighting imaginary enemies, because I don't view copyright as an enemy, nor do I view the SL server, protecting copyright, as "an enemy" – it is the sect of opensource opposed to copyright on specious grounds that this creates an obstacle to creativity that is the one tilting at windmills.

The idea that "choice" is given when copyright is undermined is one of the central pieces of the OS and CC propaganda. But undermining copyright is in fact undermining choice. Once you have made blanket, top-level decisions and mass produced, especially in groups, you have taken away choice, not added to it, forcing the obstacle to come back in to undo that forced march.

"Builder convenience" is a trojan horse that is being used to invade SL copyright at a time that it is more successful than ever as an institution. The consequences will be profound.

It's not "for everybody".

Most people want to keep copyright and not undermine copyright, especially creators who make a living in SL. In fact, the overwhelming majority of SL users don't create things, so this is an exoticism.

You do not see any of the major builders or creators of Second Life making their living in SL voting for this proposal. Instead, you see every opensource, AWGroupies, etc. type voting because they see it is about pushing through their agenda – an agenda which sees propriety rights as evil giants.

Only a tiny percentage of SL residents want blanket freebie perms so they can flood the world with their "generosity" – usually "generosity" that is put on "no mod" so you can't do anything with their primmy wonders (GNU store goods being a classic example).

Andrew has introduced "fame" into an argumentation I didn't make, and I would argue that "fame" is what people massively producing freebies want for themselves by flooding the world with goods that show their name and ostensibly force people to thank them for their magnanimity. Andrew has also ducked the two consequences that I discussed here: a) more server burden from massives of freebies b) more theft due to mistakes.

Any creator who doesn't check the permissions before distribution is not just asking for trouble, they are begging for it. Considering the problems SL has had in the past, I don't know why anyone would trust it to get them right. Over the years I've seen SL get permissions wrong... not just stripping permissions but on a few occasions adding new ones. If you can't be bothered to verify them, you are getting what you deserve.

Now by commenting I'm sure to be "confirming" the conspiracy theory.

BTW, are we going to have this mass produced freebie factory put on scripts, too?

As has been stated: anyone who doesn't like this feature simply need not use it. The system defaults will be unchanged, and I hope there will be a simple 'revert to system defaults' option in the UI - probably a single button to press.

Therefore, this cannot impact on the whole 'creative commons vs proprietary' issue. (My own opinion on this matter will not be stated in this JIRA request, cause it would just complicate the discussion further.)

As it happens, I believe that this feature will make it easier for both sides (and for the moderates) to put their objects out with their personal choice of permissions.

I am very pleased to see that this has now been activated, and look forward to seeing it as a new feature in an upcoming RC.

As far as I can tell, when looking back at the transcript, this debate has been between Prokofy and Everybody Else. Ironically Prokofy claims to be crusading for the cause of "most people" but popular support (any support, really) on that side of the argument is not in evidence. Meanwhile, Prokofy has conceded no points and no one has been swayed by Prokofy's arguments as far as I can tell.

If there were a vote I fear Prokofy would lose. Therefore I'll go ahead and implement the feature.

You can opt to keep the default and modify it in various ways – or you can "liberate" your creation for the "masses".

And most people do not chose to "liberate" their creations.

Therefore this change is ideological in nature, forcibly input at the behest of a small lobby with Linden like-minded who are trying to get it past management.

There already IS choice in the viewer. What this does is enable a small and extreme lobby to impose their choices on the viewer.

Like I said, Harleen: prefabs put their objects on NO TRANSFER. They do not "liberate" their objects.

Using any argumentation on the JIRA like "well, looks like everyone is voting for this (when there are 105 votes largely from the scripters opensource group)" and "looks it's only Prokofy in opposition" just highlights the lack of democracy, accountability, and transparency in Second Life, and it's a lame argument, and you know that.

It's funny that Melissa Yedoux can crab about me citing a poll as "not a representative base" – although of course what's operative about my straw poll is that even though it is publicized mainly on websites frequented by the CC and OS gangs, it still betrays that a majority don't find a need for CC and find CC actually an obstacle to making money.

So my straw poll is suddenly illegitimate but for Andrew, this JIRA flash-mobbed straw poll, which in fact only increased – because I drew attention to it (ROLF) and some are trying to spite me. That more than anything shows you what it's all about.

In fact, it was only through a fluke that I, who try to keep up with the JIRA although not a coder, accidently found out about this attempt of this lobby to put one over on the viewer by seeing the article in techdirect.com praising EFF's attack on SL copyright, and seeing catherine Pferrer fanning this in the remarks below the article.

I can take pride in making reasonable argumentation and seeing that at least one person who hadn't thought it through has removed his vote. And that's what it's about here, putting up at least some dissent to the extremist sectarian stuff that goes on in SL constantly under the flag of "the community" and "it was voted on".

By the way, the overwhelming majority of residents are not the only ones who don't read or follow the JIRA. M Linden doesn't follow it either. I IM'd him and asked him to stop this undermining of copyright. He responded "I will look into it". That means he didn't follow it. Meanwhile, the copyleftist Lindens admit that they have to "evangelize" this internally.

We can also see how ideological all this by Andrew's haste in implementing it, alone among patches/bugs/options in a very long queue.

Creators might like the choice of thinking of each creation and its uses and context uniquely, rather than be driven by a template in which mass choice is made in advance.

Just because I want to italicize one word in a sentence now and then doesn't mean I remove the default against "italics" and then keep it in "italics" mode all the time, undoing it for each sentence.

Creators might like the choice of thinking of each creation and its uses and context uniquely, rather than be driven by a template in which mass choice is made in advance.

Then they will not use this feature

Those that want to change their prefabs from the default "transfer" and "no copy" aren't here voting and haven't demanded this.

You're wrong about creators "not using this feature" once it is put in and "evangelized" – there will be rampant confusion and misuse, just as there has been from the land menu with their every growing "safety" features.

Er, are we going to get this liberation treatment on scripts, then?

In fact, I won't be terribly surprised to see a JIRA after this rolls out, with builders wanting it rolled back over something that was unforeseen. Will messing with it change permissions on items I have already set...? I have no way to know that right now. People say it won't, but we all know the track record on that.

I'm always kinda touchy about permissions, it's easy to mess them up no matter what you do. SL has from time to time, messed them up in so many ways before.

@Hypatia: It would be really hard to misimplement this so that it had any impact on existing permissions. It's a nice localized change that touches only the permissions assigned to brand-new just-created things. If you don't change the default, SL will behave exactly the same as it always did. (And I agree, bulk permission changing at the folder level would be a great thing also. Point at a JIRA and I'll vote it up!)

@Prokofy: On the question of just what it applies to, I don't know what Andrew's planning to do first, but the initial JIRA entry up there talks about being able to change the default perms for newly-created things in categories of Animations, Body Parts, Clothing, Gestures, Notecards, Photos, Prims/Objects, Scripts, and Textures. Up to Andrew whether or not to allow different defaults for all of these afaic. I don't think there's any reason to go as far as letting someone have a default for new shirts that's different from their default for new pants. I'd definitely want to be able to change the default perms for a new script, myself; I'm forever forgetting to change them and then ending up with the object they are in wrongly permed. A combination of adjustable defaults and bulk-perm operations will make life MUCH easier in that regard.

Prokofy initially thought that the proposal would mean that every newly-created thing was full-perm and free-to-copy upon creation, so that people could "swipe" it before you had a chance to change the permissions. And that would indeed have been a bad thing! But given what the proposal actually says (and given that it's a small change and unlikely to introduce any significant bugs), it's hard to imagine why anyone would object to it. Imagine the poll question!

Would you like to be able to change the permissions that SL assigns to new things that you create, as long as you can still change them on a per-thing basis?

(A) Yes, that would or might be useful sometime.

(B) No, please don't give me that ability, because I might be unable to resist using it, and I would use it wrong and shoot myself in the foot. I must be protected against myself!

catherine Pfeffer came bounding into this thread to flog her patch. She didn't say, "Oh, actually, we do respect copyright but we'd like something that would make it easier to build for those of us who want to give away our builds". Instead, she put her patch in, "as is".

Here's what catherine wrote, for your edification, Dale:

"You might be interested to know that our Second Life group "4freedom" is activating against the way copyrights work in Second Life. We filed a petition against that and now Linden Lab is cooperating on implementing a different system into the viewer. The idea is to let creators make an active choice on copyrights. For more information see:
http://www.ipetitions.com/petition/secondlife-4freedom/index.html"

So here's a group 'activating" AGAINST THE WAY COPYRIGHTS WORK. She doesn't specify how. She says this patch lets creators make "an active choice on copyrights" in a context where we all know THEY ALREADY HAVE CHOICE and where she has said SHE IS AGAINST THE WAY THEY WORK in an article that is AGAINST COPYRIGHT< PERIOD.

So in this context, it sure as hell looked as if she was putting in a patch to make the default no-copyright, no-permissions, no-nothing, and force people to add on a layer of protections. She didn't correct that misimpression whatsoever.

It isn't "being mistaken" to read this context just as it was intended – as a lobby against copyright, seizing a context that was against copyright.

After following all the JIRA discussions, and asking a number of pointed questions here and on my blog, it seems that technically, the default default will remain, and only "if the resident finds the widget" will it be overridden.

But none of my concerns are withdrawn, none of the obvious context of anti-copyright pro-CC invective has been changed, so I fail to see why it is "wrong" to keep pressing these concerns, as they are valid and legitimate.

I don't see Andrew or other scripters here jumping to change this on scripts. They often exempt scripts, and say "Oh, they execute server-side" and say "nothing can be done about texture theft because it's client side, but by God, we'll make sure nothing happens to what we care about, which is scripts, server-side." So I'm very interested to see if yet again, we will see this uneven treatment for scripts.

And again, Dale, so that you can cease your usual snarky smirky and "gotcha," note what the original reporter on this issue wrote:

"It would be wonderful for content creators, builders, etc; if we could set our own default permissions. At present, objects of different types are set with Linden-determined default permissions. Notecards are set Mod/Copy/Trans, most other things are set No Mod/No Copy/Trans.

Many creators always sell things Copy/No Trans or No Copy/Trans; with Mod or No Mod depending on personal choice."

This does not make clear, in objecting to the "Linden determined default permissions" (which are the default permissions not just of "the Lindens" but of common sense and copyright and property norms), that this author is contemplating leaving the default default alone and having a separate widget for customized making of defaults.

A tiny group of scripters, with their Lindens, are instigating a revolution in property rights, as they've done before, such as on the interoperability fandago. The obvious fates of the open sims should have been a cautionary tale to management Lindens on this.

Of course it's being mistaken, Prokofy. You may have a good explanation for why you were mistaken, given what you read into the context, but when you said that this proposal would make all new objects full-perm ("naked" I think was the term you used) by default, and that I was a lying sack of **** for saying otherwise, you were mistaken. You believed, and stated, something that was not in fact true.

It's okay! We're all mistaken about things sometimes.

It's simple, quick and sure. With this feature we have now the choice to use our personal default permission.

When we need (for exemple for selling ) we can change in few seconds.

Good and simple.

If scripts are created from the inventory, they are covered by the in-inventory creation patch. If they are created from the object ("New script" button), there's no patch for them yet, but I'm planning to work on it someday.

To give an idea, the roadmap is as follows :

• user interface : done (we'll move it away from file => upload menu)
• uploaded items : already implemented by Coco, available in 1.23 RC
• objects created in-world : client side patch available, Andrew is working on the server side
• items created from the inventory : client side patch available, does not honour "share with group" and "allow anyone to copy" yet
• items created from the objects (scripts only) : no code written yet
• I'm not 100 % sure how the creation of body parts and clothing from the "appearance mode" fits in the picture, but I'm not forgetting it.

These kinds of games of "gotcha" generally serve best to point up the infantile nature of those playing the game of gotcha. And indeed you ARE lying because you did not accept that my concerns about this were indeed true.

Regarding the technical matter of rezzing "naked without perms," as you can see back on my blog, Dale, I wrote the following on May 4 at 12:39 pm

"No, Dale, read the JIRA, look at the screenshots, and see what the author's INTENT is, and how they have modified it, but how their INTENT still shines through: mass production of permissionless objects under the guise of "builder convenience" – with an aim to shifting the center of gravity of copyright.
Look at the screenshot, which says, with default boxes:
"can modify, can copy". You then check this off - but it's DRIVING you toward the permissionless regime.
If objects won't be rezzed in world permissionless, that's great (I'm not seeing definitive proof of that), but there is still a campaign to undermine permissions by trying to shift the perspective of the default.
It's something that people will do as a convenience in building, and it leads to the erosion of copyright protection.
It overturns the basic premise of SL."

So let me repeat again what I said: "If objects won't be rezzed in world permissionless, that's great (I'm not seeing definitive proof of that), but there is still a campaign to undermine permissions by trying to shift the perspective of the default."

I think in literalist tekkie land, you are simply not familiar with how democratic debate goes and for you, every single supposition or proposition is true/false, 0/1, and you fail to see the larger points of the larger truths. People express concerns, explain how something seems to them given its context, and articular their understanding. Someone else says, "Oh, but it's not really that way, it's this way." Then the first person says, "Oh, ok, glad to hear that, but I'm still not convinced, and have the same concerns." etc.

What doesn't normally happen in normal democratic debate is that the second person says over and over again "You're wrong. You're wrong. You can't admit you are mistaken. You got it wrong. You are mistaken" – as you do. And when told, "No, you're lying, I am not wrong," you keep trying to insist you are not prevaricating and insist that you are right.

That's because you, like many programmers trying to constantly force decisions and technical culture on the way, cannot accept and grasp that the way a debate evolves on matters affecting a community, especially when some tiny minority hijacks the process to push through a piece of legislation, is that people DEBATE. They mount hypotheses, not fearing if they are wrong or mistaken, others shoot them down, then the first set say they aren't persuaded, and so on. That's how normal life outside the code cave does work. A minority opinion as this one DEFINITELY is is being called upon to justify itself, especially given the profound changes to server code that will have to go in for this whim. And that's normal, and just.

So again: I stated something that was true in the context I saw it in.
Nothing to the contrary to address that concern was in that context (nor this one on the JIRA).
When it was explained how it "really worked," I immediately said "Oh, ok, but that's not enough".
You are indeed lying when you fail to see what a) the real agenda is here b) the consequences of in fact mass production of items by newbies or people with second thoughts.

I'll not be replying again, and you're welcome to keep up your game of gotcha on my blog, where I've provided a longer exegisis, because I know from long experience that attempting to reason with you is pointless.

Re: "If they are created from the object ("New script" button), there's no patch for them yet, but I'm planning to work on it someday"

Well, gosh, don't tarry at this too long. Information wants to be free, you know. No reason to be slow on liberating scripts now, is there.

If you hadn't misinterpreted the function of this proposal in the first place, I don't think even you would have thought it was a revolution in property rights or an attack on copyright, since it's so clearly neither of those things. Absolutely all it does is save creators who elect to use it some repetitive button pushing (and thereby avoid some annoying mistakes when they forget to do the button-pushing). It's a very simple and very useful little mod, with no ideological implications. It may well be that you have important philosophical differences with one of more of the people involved in the mod, but the mod itself is apolitical.

I will also try to stop talking now, since it looks like the issue is resolved. I am such a blabbermouth on some things.

1. Go back on my blog, read my comments in sequence, and you'll see that you're wrong once again.
2. Um, I don't need to "pretend" that I knew something all along. But thanks for the "projection much" tip there, as insecurity often drives many people's actions . It doesn't drive mine. As soon as I saw that in fact the perms wouldn't rez "naked," I immediately said, 'Oh, that's how it works, BUT." That's on the record, no need to belabour it.
3. In fact, I was saying something deeper all along, and I'm NOT mollified by being told that literally and technically the opensourceniks for now – despite the incitement of EFF – aren't going to tamper with the default default. For now.
4. My misunderstanding of this literal technical function in a context where it was not clear, and where the author was lobbying the opensource agenda and celebrating NO COPYRIGHT was not at all driving my concern about this caper. My concern about this caper goes much, much deeper as I see the agenda is a broader and more radical one, and it is only making this as a tactical move.
5. Of course it's a revolution in property rights. Anything that makes Employee No. 2 have to tamper with the inherent properties of the server code related to permissions is a revolution in property rights. He knews that; we know that.
6. The mod is not "apolitical" when the mod's booster and patcher, catherine, is ragging on the server as being "egotistical". So much apolitical technology.
7. Your need to play gotcha is pathological. I'm going to switch my tactic from not responding to you, which I've done for about a year or more, responding early, often, and harshly : )

1. If you don't want people to mix up "Catharina" and "Catherine" then...write your last name on websites when you come to celebrate articles advocating no copyright, and flog the patch of someone with nearly the same first name. Also, illustrate how you think differently than the other person with the same name if you don't want to be mixed up.
2. It's typical that when people question the collectivist copyleftist agenda, they are accused of spreading "FUD" and, er, "dezinformatsia." That's ok, it's a job that needs doing.

I'm still not seeing any major builders or content creators showing up here.

I have to wonder why in four years that I've been in SL, no builder has ever demanded this "convenience," although you would think they would, if it were really all that, and that the patch only comes at a time when EFF is crusading on all fronts to undermine SL copyright.

1. this feature will remove a lot of tedium for a lot of builders,
2. be implemented in a clean way, and
3. clearly not alter the permissions system contract,

are the reasons that Andrew has agreed to help with this.

Thank you Andrew and Catherine.

"Newbies often have no intention at all to put restrictions on the simple objects they build, "

is probably one of the biggest FUD statements I ever did read.

As I like to quote from one of my personal heros - Daniel C. Dennett - when he was rebutting Rick Warren's book –

http://www.youtube.com/watch?v=DTepA-WV_oE

The truth will set you free - that is what it says in the Bible.... and to paraphrase him, when reading your religious tenets, I just don't think that's true...

That being said, I don't see this being anything totally nefarious, but I can see other things I've wanted long before this, and that annoys me greatly. If default permissions are changed from how they are now, it will cause a lot of problems, because the truth is, most people expect items they make to not be sharable. Or else we wouldn't have such a huge content theft JIRA ...

But that's just me complaining about the SL interface. I have come across many people who just don't realise what is lurking in there. Most of my 3d programs let me access such settings from the equivalent of the build menu, and I'd submit that might be a better place for it. Unsure if its workable though.

Some of the links you are giving are to another concept, of having objects decay or retain to lost and found automatically after some set point. That's a different idea, and not a good one.

Try to have a little more curiousity as to why the esteemed oldbies Nephalaine Protagonist and Khamon Fate did not jump up and down and demand this feature back in 2004. Might it be because as Khamon pointed out, first, permissions should work right in the first place. And, they no doubt feared more buggyness when things developed more trees and checkoffs and complexity.

I

Bingo.

Newbies do not expect to take part in the Freetard Republika as soon as they land – that's a concoction and a fiction.

No, people expect the properties of objects to contain inherent within them the copyright that pertains to us all.

Yes, the unseemly haste with which the Lindens and OS camp followers are RUSHING to perform this "fix" is unreasonable, and a red fly at a time when EFF is banging on SL and demanding it remove copyright.

The EFF is doing no such thing. The article that's got Prokofy going is this NWN piece:

http://nwn.blogs.com/nwn/2009/04/eff-and-sl.html

which quotes an EFF lawyer as saying that "Second Life in some ways is worse than real life" regarding copyright infringement potential, because there isn't much case law yet. Which is quite right. The NWN article also semi-quotes the EFF lawyer as pointing out that while someone who sued because their copyrighted texture appeared in the background of someone else's SL snapshot would probably lose, that hasn't actually happened yet so (lawyers being conservative types) you can't be sure. And as saying that "In Second Life these are gray interesting mysteries" around the law.

None of which comes anywhere close to the EFF "banging on SL and demanding it remove copyright."

And none of which has anything at all to do with this JIRA, but I don't like seeing these bizarre rumors spread...

This wikitarian use of SL is a very tiny sect. In fact, I realize that another stalking hobby horse here is the wikitecture project that actively lobbies to have group builds with everybody modding everybody else's stuff. But...that's not the norm. It's not what most people want. Most people want to create things and sell them and not have others change them. It's an exoticism to have it otherwise. It's also a set-up for disputes, griefing, theft.

The chief function of group deeding right now is to encourage theft. No one puts their items in SL in "share with group" anymore because if they do, they risk griefing or theft. We're forced, on group land, to make tenants deed their TVs to the group. All that does is set up a certain percentage of them for theft. The problem is that even if you aportion the role of "deed to group" as a role only for some residents, and not the open group members, the buggyness of the tools (which elsewhere on the JIRA is argued by an opensource Linden as being "the way it's supposed to work) forces you to make an object vulnerable to theft. The overwhelming majority of "use cases" of group owned objects in SL today is THEFT. The exotic sophistry of the wikitectured group build cannot whitewash that harsh reality.

As for Dale, trolling once again, the fact is EFF is banging on SL. As I've explained in copious detail on my blog, the EFF lawyer set up a fake problem – putative DMCA takedowns over screenshots and machinimas which don't exist – in order to provide a contrived remedy – not having copyright hold in a virtual world.

In fact, there is no such case, anywhere, nothing like it.

And because Dale and others keep refusing to LOOK at the link that is provided showing the original context for my concern about the various Catherines and their various opensource gambits, I'll quote it in full here:

http://www.techdirt.com/articles/20090501/0154374713.shtml

"Way back in 2003, when Second Life first announced that its users owned the copyright on anything they produced in the world, we pointed out what a bad idea it was. In the early days it was cheered on, because people thought it was better than what they considered the alternative to be (i.e., Second Life creators Linden Lab owns the copyright on everything). But as I noted at the time, the problem was that putting real world copyright into a virtual world, where the fundamentals of physics are entirely different, is bound to cause problems. You have property rights in the real world to deal with the efficient allocation of scarce goods. Putting them into a world where there is no scarcity at all on those goods is backwards, and only leads to massive problems.

It's nice to find out that some folks at the EFF have come around to this viewpoint also. Michael Scott points out that Fred von Lohman recently noted at a conference that copyright in Second Life was "in some ways worse" than in the real world, noting that just posting a screenshot from within Second Life may violate many different copyrights – unlike taking a photo on the street. And, by setting up virtual world issues to be governed by external world laws, problems are going to follow. This was a situation that from the beginning should have been dealt with in Second Life, rather than trying to apply real world laws to a world with a fundamentally different makeup."

EFF is indeed banging on SL copyright – this story has gotten enormous replay. Dale might no doubt point out that this author is the one making the claim about EFF, giong further than the EFF lawyer's quote, but I can only reply: no accident, comrade. This author – and EFF – and the EFF lawyer – are on the record all over the Internet with constant attacks on companies issuing DMCA notices, and constantly complaining every time copyright is asserted. Makes you wonder if in fact LL doesn't respond quickly to DMCA notices precisely because of this amen corner.

In fact, an entire legal conference was held at Stanford (which also bangs on copyright in general – home of Lawrence Lessig). Hamlet's story quoting the EFF lawyer was from that conference.

BTW, I'm having a good laugh finding that I'm banned from entering the Open Source haven of Ms. Pfeffer in order to pick up a notecard about the "economy of opensource" that she is advocating ROFL.

And figures you would not see the humor in Khamon Fate's comment.

<and that annoys me greatly. If default permissions are changed from how they are now, it will cause a lot of problems, because the truth is, most people expect items they make to not be sharable. Or else we wouldn't have such a huge content th
Bingo.

Again default permissions are not being changed by this.

Your first link to a post in 2003 leads to a lament by a fellow who lost control of a 2 x 2 x 2 prim on his land. He laments its loss because he fears the TAX on it. That's his primary motivating goal here – fear of a prim tax, a tax that doesn't even exist anymore.

He ends up saying this: "My thought would be to have my objects, by default, die after an hour or so. If I had that, I woldn't worry about lost objects like this one."

Gosh, that sounds like the perfect opensource objectless dream. Let's have not only objects with no perms, but objects that completely disappear after a set amount of time. Hey, let's not just destroy property rights, let's not have property at all.

Yes, along the way, this guy talks about how he'd like to set default permissions on scripts so he doesn't have to keep setting up the same script in each prim.

Guess he's been waiting since 2003 eagerly for this to be put in, checking the JIRA constantly.

Guess he'll be waiting another 6 years, as what he wants won't be put in now, because catherine doesn't want to make time for it now.

Hypatia is right that most people expect items not to be shareable. And making a blanket decision TO make them sharable does in fact make way for errors and fights.

I'd love to see how the typical group is going to deal with the fact that one person, the founder, the officer, decides that henceforth all group objects will be copyable and shareable.

The arguments and dramas that are likely to ensue. People will leave groups because they won't be able to get copyright protection.

Of course griefing incidents will go way up because a very common griefing gambit is to take a group-shared object and move it all around to block people, enlarge it to block entrances, take it to pieces, make some grief object out of it, etc. etc.

And this JIRA is not part of a conspiracy between the EFF, some Techdirt writer, "the opensourcers", and multiple people with similar names starting with "C", to destroy copyright and bring about the victory of communism.

I find my mind boggling at the fact that I just actually wrote that sentence.

I'd love to see how the typical group is going to deal with the fact that one person, the founder, the officer, decides that henceforth all group objects will be copyable and shareable.

I'll probably hate myself for asking but how does being able to set your own individual create permissions allow this?

The techdirt author is someone who constantly flogs the opensource line. The EFF lawyer represents the perspective of EFF on these issues. Mitch Kapor is active in EFF, and was a founder. In fact, this opensource/copyleftist/Creative Commons/graphics libre stuff pervades some key groupings in Linden Lab and Second Life. It's not a conspiracy theory to report on this.

Making group objects shareable and moddable by everyone is communism. It leads to the same crime that communism does. There really is a difference between collaboration based on private property and individual rights, and collectivism, based on denuding those rights.

The various Catherines have made absolutely no secret of their opensource agenda and the belief that the Linden server is "egotistical" for insisting on property rights lol.

Second Life, in spite of all the copyleftists, collectivists, opensourceniks, graphic librists, etc. within it and lobbying against property rights succeeds inspite of the Linden caretakers. The connection between commerce and creation has held and flourished. It gives the lie to the constant tekkie and copyleftist refrain that you "can't" have copyright and DRM on digital items because "it won't work". It keeps working in SL, despite the views of even some founders. Look at Mitch Kapor in 2005 for example:

"Criticizing Creative Commons for undermining an artist's ability to be paid for work puts the ignorance of the critic on display. Creative Commons, with whom we share office space, helps solve a different problem than artist compensation, namely how to enable a voluntary, more flexible regime of sharing creative work. Free culture underpins commercial culture, and if the former is eroded by all-or-nothing IP schemes, we are all the poorer. If this isn't clear, read Larry Lessig's book Free Culture.

How artists are compensated is itself a significant issue, but let's not confuse that with whether the current business models of the organizations which control the creation and distribution of music, film, and software are sacrosanct. They're not, and outrage is the proper response when business tries to wrap itself in the flag and shout "Commie" in the face of disruptive technology and cultural shifts. That's the thing about the capitalist dynamic of creative destruction. You can find yourself on the winning or losing side of a paradigm shift. Business will go on, but the new winning models are going to be very different from we're used to. "

I'm going to keep shouting "Commie" at this stuff because I know I'm right. Mitch and co. didn't come up with any other "business model" in the four years since this over-enthusiastic fanning of CC was mooted.

In fact, it's SL with its DRM model that has worked, and it works because unlike CC, it most emphatically encourages people to sell their creations, and enabling them to do that by protecting copyright literally and physically.

"Lex Neva added a comment - 06/Jul/08 09:33 AM
When working with a group build, it's necessary to always set full mod/copy/transfer plus "share with group" so that others in the group can work with the object. It'd be cool if I could specify that all of my creations are full perms and shared with group. It'd save me a lot of time and annoyance!
[ Show » ]
Lex Neva added a comment - 06/Jul/08 09:33 AM When working with a group build, it's necessary to always set full mod/copy/transfer plus "share with group" so that others in the group can work with the object. It'd be cool if I could specify that all of my creations are full perms and shared with group. It'd save me a lot of time and annoyance!

Lex imagines that life will always be all about some tiny likeminded trustworthy group where he never has to worry about any of the group members selling his created object out from under him and the group.

It'd be cool if I could specify that all of MY creations are full perms and shared with group.

Still does not answer the question Lex's comment was about his individual permissions when he creates objects he will share with group, this does not mean every object created by any group member will have his default permissions.

And I am sure Lex is fully aware of the consequences setting an object to full perms and share with group.

I thought we had already made that clear...

The purpose of this proposal is to undermine copyright.

This proposal would not enable the founder of a group (or anyone else ) to cause it to be the case that henceforth all group objects will be copyable and shareable.

This proposal is just to have a panel in the viewer where you can say "Look, SL, from now on until I tell you differently, when I create a new thing it should be c/m/nt rather than the current nc/nm/t", for instance. That's all. That's it. That's the whole thing.

The owner of the group decides who can enter or leave the group. He also decides, in theory, who has access to deeded objects through a permissions function in the group tools that enables access to group-deeded objects. However, that function is buggy. Actually, Soft Linden thinks it isn't "buggy" but "functioning as it is supposed to". This is a discussion that has raged in other JIRAs, where Soft has insisted that this be reported not as a bug but as a feature request, although of course I've been around long enough to remember a) when the function for group deeded access was created b) when it used to work normally so that not all members except those members enabled with that check-off could access group deeded items and c) when it stopped working so that items become stealable.

So the combination of the buggy and imperfect group tools that enable owners to decide things (unless, of course, the owner has thoughtfully provided owner status to the entire hippie collective so they can all be owners) means that group deeded items are always in peril.

At any time, anyone can come and buy them for $0 – that's the hack, you go around group deeding by selling the item to yourself for $0-- if the group is open, they are especially in jeopardy. (No, the tools are not supposed to work that way and the fact that these two check-off boxes exist to be checked off lets you know the intent of the original designers, but that never convinced Soft).

So once any member mass produces all his objects to be copyable and shareable going forward, instead of deciding each time, then the group will obviously have access.

It increases the surface over which more people can access objects and more errors or theft can be made when you mass produce and replicate permissions.

You would think tekkies of all people would understand that basic mathematical truth.

I've answered your question repeatedly, Harleen.

Yes, Lenin said the same thing. "Power was lying on the ground"...

I'd love to see how the typical group is going to deal with the fact that one person, the founder, the officer, decides that henceforth all group objects will be copyable and shareable

That as Dale points out is simply not true,

As I've just explained: the owner of a group who controls access to the group, and permissions in the group, can indeed lock someone who created an object out of the group, and can indeed in fact take all the group shared objects and do what he likes with them. That is the obvious, known, demonstrable vulnerability of groups.

I'm amazed that you aren't grasping this, or claiming it's not true, along with Dale, who is defying reality.

There isn't any skirting of any question.

By mass producing open perms, and encouraging people to mass produce objects with "share with group," the number of incidents of theft by unscrupulous or quarrelling gruop owners and group officers and even plain group members will increase.

That you'd have any doubt about that, or claim I'm "lying" about this or "skirting" some putative hard question simply boggles the mind.

Making your object shareable with the group opens it up to grave vulnerabilities.

The more you mass produce and replicate those settings, the more margin for error.

The more you are in a context where the template staring at you each time you rez a cube is CAN SHARE WITH MY GROUP, so that you are browbeaten and propagandized at each moment of creation, the more you will feel you must share and must make copyable.

and if the condition for staying in a group is giving them the ability to modify, make copies and redistribute your object, it's basicly the same thing.

If to join some club you gotta give them a copy of the keys of your car and legal rights of ownership over the car, would you do it? I believe most people wouldn't fall for things like this, the ones that do should be nominees for Darwin Awards

Here's what I said:

"I'd love to see how the typical group is going to deal with the fact that one person, the founder, the officer, decides that henceforth all group objects will be copyable and shareable."

Read it over again carefully.

And here's what you said just now:

"you stated that the founder and officers can set the default permissions on newly created objects by other group members when they set it to share with group".

But that isn't what I stated.

I stated that the office DECIDES. I didn't say that the officer SETS.

That's where you're not getting it and your deliberate and malevolent reading of this, fueled by your desire to play "gotcha," is hobbling your understanding.

I most certainly did not say that the group owner or officers have now magically acquired with this patch the ability to change the permissions on a group object.

Fortunately, God save us, the author of this patch hasn't gone so far, as they indicated in their desire to have parcels determine permissions (!!! talk about collective farms!!!), that groups would now also have permissions operated at a high level by the owner, somehow granting the owner the ability to override, say, a mod, and put it into mod against the original creator's permissions. The copyleftists would no doubt love such a function, but they haven't quite said that.

No, what I said is that the group owner WOULD DECIDE about all group objects being copyable and shareable.

What that means – obviously, if you have ever been in a group and had this happen – is that the group owner, using his powers, takes objects that are deedable (and therefore automatically shareable) and copyable (because they were put in copy! Duh! Not because HE put them in copy! Because they were in copy!), and continues to make use of them. He can boot everyone from the group and go on selling stuff to his heart's content.

See, that's how literalists and Fiskers constantly create havoc and hate. I did not say "SET". I said "DECIDE".

And indeed that group owner WILL DECIDE because he has the powers.

Is this somehow a new set of powers than under the old patch? No, not at first blush, because it isn't any physical new powers (unless there's something I don't see).

But because of the pressure of mass preduction, the browbeating to share all the time, and the forcible driving of the template saying CAN SHARE CAN COPY crying to be checked off, there will be LOTS MORE STUFF that is in this state. And that means LOTS MORE OWNERS AND OFFICERS TEMPTED to theft.

All communism, inevitably, by its nature, and not by misapplication, leads to crime. It led to crime when the Lindens made hippie communes out of the group tools originally, making it possible for any officer of the group not only to swipe land that you paid tier on but deeded to the group, but also made it possible for him to vote you out of a group and ban you from land you bought yourself.

It was that fateful communistic flaw that finally prompted the Lindens to change the group tools.

Now we are moving backwards by insisting what we had before with group tools and groups land pre-2005, by promoting and producing masses of permitless objects.

But you won't need me to convince you of this when the patch is put in. The number of forums complaints, blogs, and abuse reports about this will tell the tale better than I.

But this proposal is about setting default permissions, so I (and it looks like others also) guessed that when you say an owner will decide for the group by using this feature that naturally means they are setting default permissions for the group.

What are these "forums complaints, blogs, and abuse reports about this" that you anticipate going to SAY?

"I set my new-clothing creation permissions to copy/mod/transfer, and now whenever I create a new piece of clothing it's copy/mod/transfer unless I change it to something else! When will you fix this horrible bug????"

"Ever since the ability to change new-thing-creation permissions was added to SL, I keep having these dreams in which people threaten me with hammers and sickles, chanting 'set them to full perm, set them to full perm, join ussssss'. Please make it stop!"

"Fummy McGooch keeps threatening that unless I change my new-prim creation perms to copy/nomod/notrans, he's going to call me names! Please remove this feature so he can't do this anymore!!!"

"The founder of the Fun In The Sun With Cows Group requires that all group objects be copyable and shareable! It's been a disaster! Please turn off the ability to change personal new-prim permission defaults so that he can no longer... oh, wait. Hm. Never mind."

You live in such a strange world, Prok...

For what it's worth, I agree with the general claim that sharing with / deeding to groups is complex and odd and quite likely broken in at least some ways. I've been in a few groups that used it, and it was always confusing, or didn't do exactly what we wanted, or both. But that's completely irrelevant to the current JIRA here, which has nothing whatever to do with group-deeded objects.

The purpose of this proposal is to undermine copyright.

This is only your opinion and should be stated as such, the OP has elected not to state their opinion on the matter, which is their right.

It is part of that creation of "Free Culture" that Lawrence Lessig so desperately wishes to create but for which he has no authority.

The OP stated their oipnion about copyright by creating a system to remove it in a blanket way.

The patch indeed encourges a culture of undermining copyright. Look at the jpeg screenshot that says CAN COPY as the check-off box. In the default as it is now, it simply says "Copy" with the option of "yes" or "no".

The change here will absolutely effect group-deeded objects because it will produce MASSES of them already pre-group-shared.

It's just like the copyleftist Lindens who filled up the Library with masses of "share with group" and "anyone can copy" dreck like the beach ball and the flamingos, If you ever wondered why grief attacks always contain billions of objects that are Philip Linden's party hats or Cory Linden's beach balls, it's because those objects are rezzed by masses of people in world, with the "share with group" on them, so that any open group automatically becomes vulnerable.

That reminds me, I need to do a JIRA about convincing the Lindens to get rid of that griefer vulnerability and incitement, which is just ridiculous. I've had to clean this up numerous times because I maintain open groups, unlike the soi-disant Open Source Center which bans people.

Of course this proposal has to do with group shared and group deeded objects because that's what the award-winning wikitecture group wants.

When the pressure of masses of freebies, especially "share with group" freebies are created, we will see the effect on the world, and I won't have to come on here to explain.

In fact, about once or twice a month, I already see the lovely results of the hippie free culture when some poor tenant, not cognizant of the share-with-group problem, which I notify them of in special cards upon renting, puts out a flamingo from the Library, or mistakenly puts his house in "share with group," only to see it griefed or swiped.

I think LL most of the time is pretty wise, in the fact that they act on their own interests and not on the sheer votes on something on the JIRA. Of course this makes them seem arbitrary, because their level of knowledge of their customers is different from each of our views. Which is why we have to keep the dialogs open on the JIRA.

Good for them, really, on that. It worries me when they get bullheaded and think about their shortterm goals though, forgetting that the rest of the world sometimes has done things already and know if they work or not.

So, the approach to the JIRA really should be to present your ideas to the Lab, and make sure you get their attention. And LL employees are not stupid, they do see when something is gamed by alt votes.

Anyway, I think that most opensource projects are pretty benign, and there's nothing wrong with them. But there's a small set of people, and they are a small set, who use the concept of opensource to bring about social change in a very lefthanded manner. Prok is right on that one, though I wouldn't go as far as to label it Stalinist. The shock value is in the right direction though - but I think Prok kinda left out the Social Darwinists here.

Actually, I'm a bit inbetween on the opensourcers. Because I can see good points in some of their arguments (nobody is wrong all of the time, and everybody is right some of the time), but I do disagree that this is some sort of "communist plot" ... rather I would characterise it as unintentional Social Darwinism. And I really do stress that for many people this is unintentional, but it is the general way they are working - they are favouring the achievement of short-term goals, thinking they are taking the long view, on the belief that they have all the knowledge.

When we should be taking into account that we don't have all the answers, and try to achieve a more distributed system that allows for people to be flexible on copyright when they need to be, to take in account of their knowledge of their personal situation at hand. The fact is, most people do not selfishly assert themselves over their creative works ALL the time, they do most of the time wish to keep their control, but wish to have the choice occasionally. Which is where I disagree with the spin on that site that Prokofy linked - people DO assume that they have proprietary control over their works at first, and THEN they decide to share or not.

Now to get to my criticism of this feature, it seems hidden to most of the builders. I submit that the interface to make these changes be very visible to builders so they don't make a mistake and forget that they haven't changed the settings. This feature should be duplicated into the build and tools menus so that people find it in their workflows very easily to prevent making mistakes.

I hadn't thought of that one, but you're right. I'm not sure if that's a good "choice" to hand to a newb on mass permissions.

But the usual ones I can see having a default set underneath the choices on the build menu... I should do some mockups and show how I mean.

I don't want to vote for this feature while it is hidden in the preferences, that so many people don't realise how to change. I have dealt with residents who didn't even see the features on the graphics and network settings, and those are more frequently played with.

No, Harleen. This isn't a proposal about setting default permissions. That's just the cover story. This is a proposal about decoupling copyright permissions from objects as their intrinsic property, and creating custom defaults to override them in a blanket and mass way. It is undermining copyright as a matter of fact, not opinion, because it takes the decision about securing copyright away from each individual creation, and puts it into the realm of a mass pre-decision on ideological grounds for the copyleftists to always and everywhere liberate perms.

No, Prokofy, this is still your opinion, my opinion is the opposite. This is a simple proposal for setting default permissions, that has been requested time and time again over the years, and that is just my opinion. It may be wrong but it is still my opinion. And I respect the OP's decision not to state their opinion and you should also.

I'd like to remind everyone that this proposal is only to enable everyone to chose their own preferred defaults for permissions. The "default for the defaults" will still be proprietary. People will still be able to go back to another model if they judge their current model is not satisfying. And they will still be able to modify the permissions of the objects after they have been created, just like they are able to do it now. So we are doing no radical change, no revolution. This issue is merely aimed at avoiding to have to change the permissions of the objects after they are created. It's only an improvement in the user experience for the builders of Second Life, not an attempt to let a conspiracy lead by the communist party rule the World. Let's stop making this Jira more important than it really is.

So I would like everyone to refrain from continuing the debate here. I have not counted, but I evaluate that Prokofy has already used half of this window's space to express her position. If I count in the reactions to her statements, we are probably already at two thirds of the size of this Jira window. Everyone had the opportunity to express in detail their opinions, now I think it's time to stop.

I am not trying to remove the freedom of speech of anyone. But Prokofy could continue to express her opinions elsewhere, for example on her blog http://secondthoughts.typepad.com/second_thoughts/ . People with opposite opinions could continue on their own blogs, for example on 4freedom web site http://4freedom.a.wiki-site.com .

If anyone wants the last word and posts something after this comment, just ignore him or her. Don't answer. Don't feed the troll!

Now back to the technical issues. Please.

oh, I'll go you one better on that, catherine.

Could we please not use ALL OF SECOND LIFE as an experimental polygon to inflict worldviews on the rest of the public?

Because that's what this patch in fact does – and the unseemly haste with which the Lindens are escalating it ahead of the queue does.

I'll absolutely feel free to go on expounding on worldviews on the JIRA as long as you keep putting worldviews right into the viewer and the world.

This is not merely to "enable everyone to chose their own preferred defaults for permissions" – you know that, and I know that. Harleen has to dredge back through a million forums posts on everything under the sun to try to scare up two notices from oldbies even hinting they ever wanted/needed this.

No builders came and asked for this. It is not something an actual legitimate interest group of builders asked for. Instead, it's a contrivance of scripters, and scripters who like to inflict the opensource view on everyone else. That's clear from the signatories. (If you have a pre-fab store and custom builds I don't know about, and not just an opensource center dispensing opensource propaganda inworld from which I'm banned, by all means, send me a SLURL).

You don't get to shut up debate about thrusting your worldview into the viewer – which you are doing, in spades, obviously, and evidently. It's not about "trolling" to express persistent criticism – and in this case, it's urgent criticism because what's happening is so egregious, so blatant, and so deliberate.

Once again: a tiny lobby of opensourceniks and the handful of AWGroupies and other penguin t-shirters they can drum up doesn't signify anything that "the community" wants and is a contrivance.

The group abuse dynamic is a valid one. I have been the victim of objects set to share with group only to have some idiot come along and replicate it en masse across the sim. Why would I want to be stuck in a constant state of going back and forth between global and next user? Forever and ever and ever. Not to mention the increased anxiety of wondering if I forgot to change the global default before I begin to build? You can say that many won't use this feature..but many would as well.

Even after almost six years I STILL get items returned to me because I forget to build with a group tag. This is just one more thing to worry about in terms of commercial intent. Creating a small building group of trusted friends and sharing mod rights with each of them has worked just fine for us to date. Don't throw the baby out with the bathwater. A small minority would benefit with grid-wide repercussions. You think freebie resells are a tax on the SL economy and stifles creativity? This would increase that scenario exponentially. BAD IDEA!!

Building, creating, marketing, distribution and sales all hinge on default perms and the convenience thereof. I already have to build in skyboxes because I have had (on more than one occassion) strangers swoop in and extend their edit arms. Adding another layer of obfuscation only makes me want to build less. Not more.

Think about this..you're building with a group and one of the members decides that they dont want to play fun anymore, or are not getting their share of notariety, whatever. They carve out their piece of the collaboration and decide they want to compete with yours. (Don't laugh, it has happened to me personally) Or, suppose they decide they want to give it away for free when the other group members want to sell it? What's stopping them? A license? a MoU?

Step back and look at the BIG PICTURE here. Please! Too many far-reaching ramifications and potential for exploitation and mistakes. God knows I've made my share, and I'm an experienced? builder?

The way we work demands that we create all objects/animations/scripts etc. full permission. This is because we often pass along unfinished products among us 3. My partner would create a piece of furniture, the objects, textures, etc. She passes it to me or our third partner for adding functionality. Scripts, poses, animations.

In the beginning we had a lot of trouble where we would by mistake not set the object full permission, pass it along, just to find out that in the next stage of production, we could not modify the object since the next owner permissions were applied. Even worse, if you allow that your partner edit your objects (and we 3 use that regularly) and you "take" object made by your partner to the inventory, the next owner permissions kick in and the object becomes permanently non copyable and non modifiable.

Our coping with this issue was to methodically keep setting every newly created item full permission. Having an option to set the default would really reduce the rate of permission errors we face.

It's only at the point when I put the items for sale that I set the finally permissions (usually mod-no copy-transfer).

I am not going to debate this issue as I have made my comments. But, I would like to add that I always prefer to err on the side security.

In terms of commercial intent and the "convenience factor" I will say this.

1. Lock down your sim
2. Absolutely 100% trust your partners/collaborators
3. Build in a skybox at 4,000M in the middle of your sim
4. Pray that your partners/collaborators didn't leave anything out full perm
5. Pray that no one can override your area/sim security
6. Don't crash in the middle of a build
7. Create airtight RL contracts that everyone signs
8. Make sure that everytime you pass an object from inventory it wasn't the full perm "builders model"
9. Never share with group

As much as a PITA as enduser perms are, I have NEVER set anything FULL PERM accidentally because the default is always secure and I build linksets. I have on occasion accidentally set items as COPY. Copy is ONE checkbox. What's worse, going through and changing everything from FULL PERMS to Mod-No Copy-Transfer or having to change everything from No Mod-No Copy-No Transfer? Err on the side of security. The means does not justify the end.

I can envision a whole new industry here. Flying around to skybox workshops to see what was left out full perm for resale.

we can't ban knifes just because the risk some people will see the sharp blade and squeeze it instead of the handle

if you think you will mess up and forget to set permissions, just don't ever touch any permission related settings, and the next person that gets your thing will be unable to do anything with it but pass it to another person

Somehow I doubt that Bill Gates implemented it in windows (default permissions inherited from parent folder) because he's a pinko-socialist.

Just because a given software has the ability to make custom defaults permanent doesn't mean that you would want or need them.

For example, in Word, I can change the default typeface to italic and henceforth, everything will always be in italics. But I don't thinks always and everywhere to be in italics. So I would have to keep them undoing my new global custom default as an annoyance, that will add to error.

That's why instead, I highlight one word, and then press italics for the occasional usage of italics.

I believe it was Ace Albion who noted that this feature can be accomplished by use of shift in SL in the same way as "highlight".

1. Prok is totally unqualified to determine my motivation. This is the first time we have ever encountered each other in virtual space, and (to the best of my knowledge), we have never met in fleshspace. Having never met me, and never having read my mind, Prok has no idea who I am or what my motivation might be.

2. My motivation in requesting this proposal was so that it would be more convenient for me to set the permissions on things I am creating. Basically, if I intend to mass create a range of copy/mod/no trans clothing, I want that clothing all made c/m/nt at the time of creation. It would be easier. Likewise, if I wanted to mass create a set of full perms items, I want to make them full perms at time of creation. Again, easier. I tossed the JIRA out here so that IF that convenience would help other people, it might be voted for and implemented. If I'm the only one who'd ever find it useful, the JIRA can languish in the depths of the database and eventually get aged out and deleted.

3. I make some proprietary stuff AND some free stuff, as anyone who actually cares enough to casually glance at my in-world profile would be able to tell. In the 'open everything' and 'close everything' argument, I'm a moderate. As in, 'let the creator choose'. Adding the ability for the creator, IF he or she wishes, to choose their own default permissions is open-content/proprietary-content neutral. Because hey, the creator can CHOOSE.

4. Scripts (and every other category of creation stuff) are included.

5. I didn't even think of group permissions, as the initial post shows. Including the possibly to set one's own choice of default group permission among already-existing group permissions would be within scope for this JIRA. Adding entirely new types of permissions is out of scope for this JIRA and discussion about new types of permissions - group or otherwise - belongs in a different JIRA.

6. As I envision it, the 'set default permissions' interface elements would be essentially an advanced feature, and NOT something which certain people in this thread seem to presume would be staring people in the face all the time. Most non-creators or casual SL creators would never even notice it. So the argument that it would be in peoples' faces all the time is invalid.

7. The 'italics' analogy is flawed. This is more of an 'I want to type in 14 point Ariel for most of my work today' issue. And frankly, the existing system seems determined to make me type in 12 point Courier and change each word to 14 point Ariel individually.

Edited to put direct responses to Prok into a separate comment.

"I'm not quite sold if this won't be a security issue somewhere down the road, the permissions we have now are pretty simple. I'm a big believer in "KISS" (keep it simple, stupid) whenever you can.

In fact, I won't be terribly surprised to see a JIRA after this rolls out, with builders wanting it rolled back over something that was unforeseen. Will messing with it change permissions on items I have already set...? I have no way to know that right now. People say it won't, but we all know the track record on that.

I'm always kinda touchy about permissions, it's easy to mess them up no matter what you do. SL has from time to time, messed them up in so many ways before."

If this is implemented as specified, it will affect only items that are newly created, and only if the creator chooses to use this feature.

As for whether it is going to be implemented correctly: I'm sure Andrew Linden is currently wearing a sports headband to keep the sweat out of his eyes as he studies the permissions code and tries to be certain he'll get it right. I'm sure he's trying to foresee everything - and would welcome suggestions about avenues of permission-clash to investigate.

"To reply to what Erica said, bulk permissions changing at the folder level seems like it would be far more useful to me, than this. I often change the kinds of permissions I use."

I believe there's a JIRA for that, as well.

"there is certainly a use for it, as long as there isn't any change in default settings. I somehow wish that it was more obvious when building to change these sorts of settings. It just feels wrong to have it only in preferences.

But that's just me complaining about the SL interface. I have come across many people who just don't realise what is lurking in there. Most of my 3d programs let me access such settings from the equivalent of the build menu, and I'd submit that might be a better place for it. Unsure if its workable though."

Excuse me while I run off and create a JIRA asking for permissions to be visible in upload windows, Appearance mode and the scripting window, just as they are in the General tab of prims. It's an excellent idea! I love it!

EDIT TO ADD:

http://jira.secondlife.com/browse/VWR-13181 is about setting perms in upload windows. It's linked to as 'related' to this JIRA.
http://jira.secondlife.com/browse/VWR-5082 is about setting bulk perms, also linked to as 'related' to this JIRA.
http://jira.secondlife.com/browse/VWR-13264 is one I created for setting perms in Appearance mode and in scripts.

Me: Yes, there is choice in the viewer. Tediously changing a hundred things one at a time is not my idea of fun, and that is why I asked for the option of automation.

Prok: "When you change the defaults you are forced to have them changed forever until you change them back"

Me: I'd prefer that to being surprised by having them change back!

Prok: "No builders came and asked for this. It is not something an actual legitimate interest group of builders asked for.

Me: I'm a builder. Also a clothing designer, animator, and - well, I can do most types of SL creativity.

Prok: "This does not make clear, in objecting to the "Linden determined default permissions" (which are the default permissions not just of "the Lindens" but of common sense and copyright and property norms), that this author is contemplating leaving the default default alone and having a separate widget for customized making of defaults."

Me: In that case, I was unclear. I apologise, and clarify: yes, I intended that the default default be left alone.

Additionally, I recommend that the presentation of the screen would include whatever the resident's current default permissions are. So the initial presentation would have the current default-default permissions.

Prok: "The more you are in a context where the template staring at you each time you rez a cube is CAN SHARE WITH MY GROUP, so that you are browbeaten and propagandized at each moment of creation, the more you will feel you must share and must make copyable."

Me: But it won't be. It will display the current default-defaults until or unless the user chooses to change them.

Prok: "I notice there's actually a curious vacuum here around the discussion of just what will happen to group objects under this lovely schemata. [...]
I'd love to see how the typical group is going to deal with the fact that one person, the founder, the officer, decides that henceforth all group objects will be copyable and shareable. "

Me: In this JIRA, the item is created by the initial creator, with that creator's personal default permissions. Then after that point .. um. Unchanged. Everything else happens as it happens right now.

This JIRA doesn't affect 'deed to group' at all. Nor does it affect group-deeded objects. If you have a dispute about the way group-deeded objects work, go have it in a different JIRA.

If we consider that people in Second Life are irresponsible, I suggest the following:

• suppress the "abandon land" button, as people might press it by mistake
• remove the possibility to grant permission to take money from scripts
• prevent people from buying more than 1,000 L$ at once on the Lindex
• disable any possibility to make items full perms
• remove any possibility to share anything with a group
• prevent people from giving money to other people with no goods in return
• check that no good is sold for free
• check that no good is paid more then 20,000 L$ for
• check the price at which people sell their land so that it is no lower than 4 L$ / sqm
• check that no land is paid more than 20 L$ / sqm
• check that no one develops addiction by using SL more than 4 hours a week
• as in other metaverses, replace any occurence of "sex" with "***" in group IM and chat
• etc, etc

Also advertise herbal tea against coffee, as coffee has proven to be bad for the health .

When this feature will be ready, I won't fear people flying around sandboxes where I work when I build full perm items since I intend to release them full perms. And if once I plan to build a paying objet, I'll switch back to restrictive defaults before. I am not stupid and most other builders are not stupid either.

Nothing forces you to change your defaults. You're the master. You're in control. You're grown ups and if you tick the checkboxes for full perms, you must know what you are doing. And if you don't, there's even a warning message that tells you that you are chosing more permissive defaults.

@Seshat: very good idea (show the perms for anything created, not only objects). I consider it a bit overkill, but it's always good to give the user more return information over what happens.

@case: yes, good remark, in every past permissions system, this feature exists. In UNIX systems, the equivalent of this feature would be the "umask" (user mask), and the equivalent of the bulk permissions change would be "chmod -R". It should be noticed that the "umask" has now existed for more than 30 years without people losing massively control over their files... It should also be noticed that setting your "umask" correctly is considered as LESS dangerous than using "chmod -R" on a regular basis... I think everyone should take this long-term experience with operating systems into consideration before claiming that the World is going to collapse with this feature.

There has always been choice in the viewer, and there was never any pressure to change this choice to become blanket preset defaults until someone felt the need to have the ability to set all permissions to override the defaults *for the sake of creating freebies with all permissions", as I've indicated. THAT need preceeded the need to have "convenience" which was never felt acutely before.

1. No major builder or designer has ever asked for this feature in four years that I've seen in SL because they found no need for blanket freebies permissions setting in this fashion. They did not need it because they didn't need to create masses of full-permissions freebie objects.
2. No major builder or designer ever had to ask for this feature because the default was generally acceptable (no copy/transfer).
3. No major builder or designer ever had to ask for this feature because they make unique creations, and the circumstances of the creations often changes – sometimes they need to put all perms on, sometimes some perms, sometimes no perms, depending on whether it is a freebie loss leader, a prefab to sell, a custom build. Seshet says he is also such a builder with changing needs; it seems odd then to demand a blanket permissions-setter that will have to be turned on and off constantly, with margin for error increasing every time especially on complex builds with multiple permissions sets.
4. If some people are builders in this thread, that's great, but once again – those who are major builders and designers have not demanded this. The person who has made this patch does not seem to run a prefabs store or custom building operation, but instead runs an Open Source Information Center and library.
5. If the screens say CAN SHARE and YOU WILL HAVE LESS CONTROL OVER PERMISSIONS because you've chosen it doesn't change the point: that you are in a setting where you are constantly propagandized because you chose that once to keep chosing it the way the language works – just like Creative Commons.
6. All analogies to other computing programs aren't acceptable, because other computing programs are not 3-d interactive virtual worlds with copyright and economies intrinsically a part of them with the same contextual set of circumstances regarding copyright. I don't have to decide whether each Word document is copyable or transferrable or sellable or face copyright consequences, nor would there be any but the most rare extreme circumstances where a document say in an email attachment wouldn't need to be transferrable and copyable.
7. Everything in Second Life affects something else. So while group roles and functions are a separate problem, it's right and proper to explain that due to the buggyness of the group tools, blanket permissions, in combination with buggy group tools, will make for many unfortunate situations.
8. Over and over again we're told "If you don't like worrying about permissions, don't use this feature" – although there is another solution to possible problems with this: don't put in such a reckless device.
9. These complaints about "reading motivations" are misplaced and also need to be readdressed. Over and over and over again I'm attacked in this thread, my motivations are made suspect, and I am told that I'm stupid, ignorant, deliberately inciting hatred/trolling, crazy, etc. Yet none of those things are true – whatsoever. My motivation is clear: preventing erosion of copyright in SL, which is already under attack. The motivation of the creators of the patch and most in this thread are clear: loosening copyright because they wish to make objects without permissions. So it's not rocket science or psychiatry: it's about world ideologies.
10. Time and again, when some lobby has agitated to put in profound changes, such as all those menus on the land menu, someone would say, "but people in SL shouldn't be stupid" or "but people shouldn't sell land if they are that careless,"etc. Yet nevertheless, the Lindens put in those extra safety menus, and the record shows that the more choices and the more safety questions they introduced, ironically, the more cases of accidents occurred precisely such safety messages breed dependence, learned helplessness, and lack of awareness – and also confusion.
9. I'm not the one writing these following lines, each one of them indicates profound, far-reaching consequences and margins for error that did not exist in SL and were not considered necessary for the sake of the purported goal:

o "I'm sure Andrew Linden is currently wearing a sports headband to keep the sweat out of his eyes as he studies the permissions code and tries to be certain he'll get it right. I'm sure he's trying to foresee everything - and would welcome suggestions about avenues of permission-clash to investigate."
o "When this feature will be ready, I won't fear people flying around sandboxes where I work when I build full perm items since I intend to release them full perms."
o "In fact, I won't be terribly surprised to see a JIRA after this rolls out, with builders wanting it rolled back over something that was unforeseen"

Let me take this opportunity to note that I've been issued "a warning or suspension of your account" threatening me with ultimately expulsion from Second Life and loss of my business and property i.e. linking "speech offenses" with "property loss". That more than anything lets me know the real agenda here with this patch, and with trying to silence a critic.

I haven't called anyone names here, although I've been called names myself repeatedly by others. I haven't "trolled" even by the lights of the Linden rules – and in any event "trolling" is something I reject as a concept because it is overbroad and subjective and frequently misused . Having sincere and honest disagreement and a completely different worldview than the JIRA regluars that starts from the premise of copyright and private property rather than the premise of opensource and collectivism isn't "trolling," it's merely persistent dissent in an "open source" setting.

I'm willing to bet that not a single other person in this thread got any warning, though their violations are clear by these lights.

No speech in this thread is so "offensive" that it is removed – yet I am threatened. I'm going to appeal this threat and warning; it's wrong.

There is still no pressure. I was the one who started this JIRA, and as I have mentioned, I did so in the full understanding that if it was not voted for, it would eventually age out. As I have said, it was not 'for the sake of creating freebies with all permissions'. In fact, one of my major motivations is that 90% of my clothing is sold mod/copy/no trans. IE: proprietary, but different from the default-defaults.

"These complaints about "reading motivations" are misplaced and also need to be readdressed."

Throughout your comments, you make statements such as "The copyleftism inherent in this proposal is a forced-march blanket granting of permissions." I am the creator of this JIRA. Asserting that this proposal is inherently political - which you repeatedly do - is asserting that you know my motivations. You do not. We have never met, never spoken before this, you don't know me from a bar of soap. How can you possibly know my motivation?

"No major builder or designer...."

Major builders and designers are not the only users of Second Life. The 'little man' has the right to post JIRAs as well.

"All analogies to other computing programs aren't acceptable"

I think it was you who raised the 'italics' analogy. However, if it was and you drop your analogy, I'll drop mine.

"Everything in Second Life affects something else."

Agreed. And agreed that whichever Linden is working things out should be notified where an unforeseen connection might exist. Tracking those unforeseen connections is the reason I made the 'sports headband' comment. I am content to leave that job to Andrew Linden, though if I think of an unforeseen connection not yet mentioned in this JIRA, I will do so.
But such connections only need to be mentioned once. Once. Andrew can take it from there.

The rest of your comment, save for the 'warning/suspension', is material which has been addressed before, and I see no need to address those points. And the warning/suspension is between you and the Lindens, and none of my business. Take it up with them.

• In that respect having the possibility to set default permissions in the viewer which is proposed in this JIRA will be invaluable for us.
• Second part is the possibility to set bulk permissions once we finish our product, which is now part of 1.23 (great addition!).
• The last piece of the puzzle would be the ability to give inventory temporarily disabling the application of next owner permissions (this is very similar to "next-after-next owner permissions").

Let me try to explain the scenario where it would be useful to have the 3rd possibility above. Once we have a finished product, before we put it for sale, we need to set permissions on the object itself (mod-no copy-transfer) plus the permissions on all containing scripts and animations (no mod-no copy-transfer). This is made easy with the blik permissions patch. In that way in my inventory I maintain always production version which is full permission and the sale version with restricted permissions.

The problem is, it's easy for me to pass the production (full permission) version of the product to my partners, but impossible to give them the sale version, since the mere act of me giving them the sale object would invoke the application of next owner permissions. So, we each must go through the step of converting a production full perm version to the sale version in our inventories. This is where the ability to make one-off inventory transfer where one would be able to say "don't apply next owner permissions now" would be really nice to have.

This will be a great help to content creators who wish to use it. And, as others have pointed out, but a few ignore, this will have absolutely no impact on content creators who do not use it. I can understand some concern over someone setting the permissions to a less restrictive state, and then forgetting about it and accidently selling content with unwanted perms. I would suggest that if someone is really and truly concerned that they will make a mistake of that nature, then they should consider simply not using this feature. It's up to them to choose to use it or stay with the default. I guess that's what makes it a choice.

It does occur to me, though, that a possible enhancement of the client-side feature, would be the option to change the default permissions for the current session only (i.e. until you closed SL). So, if you know you're going to be working on a group build all day, you can set appropriate default permissions for that, but the next time you logged in, your default permissions would be back to the way they were before. This would be a genuinely useful enhancement, as well as helping to allay fears of accidental freebie-geddon.

But anyway, that and other extra enhancements could be done client side, and could be implemented, tested, and submitted to JIRA without pestering LL to to make more server modifications (beyond the current undertaking).

So, go go Andrew!

Sure, the little guy has the right to post all he wishes. But the people voting for this aren't the little guy. They are all very prominent advocates of AWgroupies, opensource, etc. The same people who always vote this plank. And my point is that those in a position to have lobbied this feature ages ago didn't feel the need for it. I remain avidly curious about why that is so. I guess it's because they didn't need to liberate their permissions.

Any argument that works like this "Well just don't use it if you are afraid to make mistakes" or "well just don't use it if you don't like it" is an argument that has utterly failed to make the case for its use. There's no identifiable mainstream use, or even very representative specialized professional use, of this feature.

'If FULL were truly interested in serving the membership, they'd let us specify, per account, what we wanted default creation permissions to be. I suppose people would complain about that as well; but at least it would support "Your World, Your Imagination."'

Which (assuming that was really Khamon Fate), does seem to be at least one person you consider a major builder saying that this change would be "serving the membership"?

Khamon also never asked for this feature after once seeming to endorse it back in 2003; he never pushed it all this time. THAT is the point. He would never even have noticed this "feature" if I hadn't mentioned it and opposed it.

Oh.

The plot thickens.

So you're saying that this genius patch was conceived to override the Linden defaults over on OpenSim, and now the pressure is to migrate it here, too?

Can I ask if this patch is likely to make it into the viewer before next release or will it be delayed by all the silly politics?

@jacek: about changing the default permissions for the current session only: this idea is good in itself, but I can see a major problem with it, it's that's there is no other setting that I know of, which is session-only, and it's a bad idea to break consistency in the client's behaviour.

@dahlia: I did not realize that my patch could be used to switch from OpenSim's default fullperm model to a proprietary model. It makes me wonder whether there is an agenda from the Republican Party to undermine the opensource model by proposing this Jira. Yes, there must be a conspiracy...

@gareth: the File => Upload part of the new feature is certainly going to make its way to 1.23 viewer (thanks again Coco). But I think it would be unwise to have the inworld creation part published before 1.24, as any patch related to the permissions system should undergo important peer review and quality insurance, and this one makes no exception.

I noticed that Frao Ra is among the voters. For those who don't know him, he's a major builder, and a very innovative person. We owe him the Bibliothèque Francophone for example. So much for the legend that this Jira is not supported by major builders.

I think that your idea brings us back to an old idea that appeared at the very beginning of this jira: predefined profiles. Like "full perm" profile which would stand for "copy / perm / trans". The user would choose among his/her set of predefined profiles, and his/her choice would not stand till next session. For example, a user with two preferred profiles would have two entries on his/her list of predefined profiles to choose from. Then SL viewer could switch back to default "proprietary" profile each time you restart it.

I did not go the "permission profiles" way for the sake of simplicity (see comments at the very beginning of this jira). Also, it could become a pain in the neck if you stick to only one preferred model and you have to reselect it at each new viewer session. Is the fact to lose your settings at each session a gain or a loss? Personally, I would tend to say "a loss".

So basically yes it could work, but... KISS and usability principles perharps command to stick to simple classical checkboxes that match the low level permissions (copy, mod, transfer, share with group and anyone can copy).

But if there is really a popular demand for predefined profiles, we could change to that UI, yes.

A mixed system of permanent and volatile settings looks even worse to me (very confusing).

Update: I just realized that the "presets" system was your idea (second post on this jira). LOL.

but again, I evaluate it as unnecessarily complicated.

This feature, imho, only addresses PART of the permissions usage needs. To be complete we should also have:

1) The ability to (recursively) Change Permissions on all contents of selected FOLDERS in our inventory. (without having to step through each and every single item as we do now, even when selected as a group). (Yes it may allow someone to spam the inventory database with tens of thousands of updates. Limit it to 999 items and put a delay on it if necessary.)

2) A recursive permissions tree that allows us to view/update permissions on a rezzed object and its contents (and it's contents content, etc), something that could very well be shoe-horned into the INSPECT widget rather nicely. It would help end the need to play "hunt the wumpus" for sub-parts with incorrect permissions.

And Prok... I'm amazed at your ability to turn a convenience issue into a charged political debate.

@jopsy: yes, I worked on this patch with the "umask" image in mind. I am an old UNIX hack too... The complementary "chmod -R" patch exists. The jira entry is VWR-5082 and it's called "bulk permission change". As far as I know, it is recursive. It only applies to inworld objects, not to inventory. I think it would be a good idea to extend it to inventory too, very good suggestion. I'll add a comment on VWR-5082 on your behalf, if I may.

@Jopsy: uh... what catherine said about the bulk perms JIRA. Ahem.

@Eirynne: Regarding Prok & ARing - the Lindens do read the JIRAs. It's kind of the point of JIRA. As for arguing - you're right. Let's keep this to the technical stuff. We can debate the ethical side of things like this in some other venue.

@jacek & catherine: my first pass thought about implementing the 'session-based' or 'profile-based' defaults would be that if the necessary server-side support for this JIRA was implemented, it would be a client-side-only change to add session-based/profile-based defaults. It might be worth prototyping them just enough to confirm or deny that. (OTOH, I'm not volunteering to prototype it myself, so it's obviously not worth THAT much to me. Heh.)

But these are features, not bug reports, and as such, of course they often have political, ethical and other "non-technical" aspects that can and should be discussed; in fact even bug reports, especially when someone determines to say they are feature requests, not bugs, can be very politicized too.

Jopsy, it's not a convenience issue merely; that's just the flag under which it is flying. BTW, you're a venerable oldbie, perhaps you can explain why you lived without this convenience request all these years until opensource proponents suddenly began to flog it.

Speaking of political, "proprietary" is not a word that appears in the SL viewer anywhere at this time.

@seshat: I confirm that a switch from current checkbox-based UI to a presets-based UI would be client-side only. That would allow us to switch to a presets-based UI only after the ObjectAdd server-side changes have been implemented. And only if the need outweigths the increased complexity, as Melinda pointed out.

And for the second part: YAY! Excellent. So we can do some constructive waiting on that one, and see if anyone actually finds it necessary, given implementation of both this JIRA and 5082.

But that's a separate, future issue. For now, I definitely agree with sitting back and waiting to see how the server changes and this initial patch play out.

Prok- In SL, there are times when I feel like a monk in a scriptorium, carefully flipping each and every bit with quill and ink by candlelight... longing for the more modern authoring tools that others have been using for decades. This is one of the tools I take for granted elsewhere. Yes, like most new features it is a compromise, more complexity for more convenience. As it is with nearly everything that gives us more control over our tools.

To answer your question: I've lived without this one, as I have without out MANY of the modern amenities that SL lacks... by grumbling, putting up with it, and waiting for better. Personally, there are many things that are higher on my wish list... but most of those would be far more difficult to implement than this. I'll take what I can get.

You can cast suspicion towards the people asking for this feature... and you can disparage how recently this idea has gained support... but I find neither tactic sufficiently convincing for me to reconsider my desire for it. Sorry.

When I first read this JIRA I voted for it, primarily because of my hair-tearing frustration with perms. Trying to build something with someone else, passing the prims back and forth, building a house and realizing there's a script hidden somewhere that has the wrong perms, hunting and pecking for the object that's set to "no transfer" when everything else is fine - on more than one occasion it has felt like a test of Zen patience, something I don't apparantly have.

But I've been thinking some more about it, and there are a number of assumptions that I've started to question.

My first assumption is that the solution lies in how prims are rezzed, rather than in the accessibility of a transparent view of the perms, nested and otherwise. In other words, if I had the tools through inventory or in-world building to select an object and view a nested hierarchy of prims, scripts, textures, etc. and their related perms and 'authorship' I'd have the majority of my problems solved - especially if bulk changes were possible.

The second assumption I've questioned is whether choice necessarily relates to intelligent outcomes. Without getting too esoteric about this, I'm struck by the notion that in economics they're suddenly waking up to the idea that not everyone is a "rational actor". More and more data shows that we don't always make intelligent decisions when faced with choice. Choice, therefore, does not always equate with intelligent choice - and so the idea of incentives and the "nudge" come along...that we develop choice architectures for people which nudge them in the right direction without denying them the ability to choose.

Sometimes these nudges are friction points rather than facilitators: in other words, if you make one choice HARDER to make than another, you may choose the easier. Or, a nudge can be in the direction of a default: we don't often take the time to understand the implications of a yes or a no, so we accept the option on offer. I know for myself I do this every time I click the "Accept" button when yet another EULA or TOS is presented, in spite the fact that this is something I KNOW I should pay attention to, I care about it...but the cost of figuring it all out often doesn't seem worth it, I'm only planning to visit, not move in.

So what does this have to do with perms?

I'd propose that the Lab has developed a choice architecture which goes hand-in-hand with an object or content-based economy. Perms are inextricably linked to a platform that allows us to set those perms towards either selling them, collaborating on them, or giving them away. The default perms reflect a philosophy which says "these prims have a value, that value is transferable, but I'm the only one who can decide whether that transfer should be flipped to be "mashable" or used by others freely, or flipped to be worth something economically."

Each time we make these choices we are engaged in an architecture of choice - one which makes us conscious of this decision, and which leans towards the 'transferable' but which pings us to choose either to give them away, allow their modification, or to sell them.

Now - we're all intelligent people. And maybe there's some stuff I'm smarter at than others: but in spite my conscious attempts to do otherwise, I still make mistakes with perms. Thankfully, those mistakes are usually mitigated by the default choice so I don't end up flooding the grid with, well, ugly boxes but still MY boxes. But I also think back to when I was new: perms meant nothing to me, and if someone had told me "flip your default using the menu, and switch to "full perm"" I probably would have and never really thought about it again until I got it in my head to start selling stuff.

None of this is to say that offering people the choice for a "change to default" is necessarily a non-starter. But I can't help thinking that we miss half the equation if we simply look at "ease-of-use through choice" without also thinking about how this change in the choice architecture could play out in decision paradigms that have a deep or a subtle impact on a creation process which may be frustrating, but which is perhaps a NEEDED frustration along the path to rezzing prims: we have a model, the model includes a choice architecture, that architecture is supportive of making us conscious of the value of perms as a platform feature, and the number of times we need to MAKE that choice may be inextricably linked to protecting that fundamental idea.

What is being proposed is a reduction in the frequency by which a user needs to make those choices, and thus could change the architecture by which content protection and value is embedded.

I'd propose, therefore, that this not be viewed as an "ease-of-use" question, but rather an interesting opening to a wider discussion of how the choice architecture of Second Life is constructed to facilitate the ongoing philosophy that perms have a meaning, and that until that wider choice architecture is established towards the protection of this basic principle that any changes to how prims are rezzed or the options for doing so be shelved until a summary of these choice paradigms and pathways has been articulated.

I've long viewed the permissions system in SL as an inherent obstacle to productive collaboration, all it takes is one teammate who forgets to check their permissions and your entire project trips and stumbles as you wait for them to log in and fix the problem.

While this feature does not completely resolve the problems with collaboration, it does address part of it, and that's a positive culture change that I'm certain outweighs the hypothetical 'negative culture change' associated with a feature that most casual users will be entirely ignorant of, or simply ignore.

It's interesting that the measurable benefit that you highlight is collaboration - I suppose that's in keeping with the Lab's current philosophy of SL being a meeting and collaboration space for enterprise - although I fully recognize that collaboration has always happened, and happens at all levels, whether building your beach house, an RP sim, or a corporate locked down meeting space or whatever. However, this wider shift into collaboration should be done strategically and with due consideration, and not as a 'cast-off' of usability.

I have to say though, that while the upsides seem straight-forward, I'd love to understand what metrics you base your conclusions on: you mention the positive change from collaboration versus the negative cultural change.

When we built out the Metanomics sim, I think we had ONE log-in required in order to change a perm or setting, and that was primarily related to estate-level controls rather than something to do with prims. We managed to have a team of people working at different hours on different parts of the build, and while the main portion was built by Keystone, he was still swapping prims with our guys who can twist the megas like nobody's business. My point being that the hypothetical gain implies that there's a loss - and I wonder how that's measured? How many minutes or hours are lost due to 'forgotten perms' and people sitting around waiting for someone to log in to change them?

I mean look - there's lots of stuff I wish was better, but that doesn't always mean that the trade-offs for investing in those improvements are worth it.

On the other side of the equation, the "hypothetical negative culture change" has two possible outcomes: negligible, or profound. On the one hand, I don't understand what metric we're basing this "need" on, and on the other there's a quiet dismissal that a change to how C/M/T is managed, in any form, has only hypothetical and therefore, I suppose you're saying, immeasurable consequences.

I'd argue that without being able to extrapolate how that negative cultural change is measured, through forming an understanding of the choice architecture and coming to conclusions about what behaviors that architecture is meant to protect (namely, the protection of an embedded understanding by residents of "C/M/T") this is a decision that is only being made at the level of usability....which is fine, because it's the Lab's job to worry about strategy, I suppose, but I don't see any harm in adding a voice of conscience to the debate just in case one of them is listening.

I don't see any evidence that the losses because of projects "stumbling" are a major sink of time or money, nor do I see any validity in your saying that the negative culture changes are "hypothetical" - C/M/T is the basis of what SL is built on, and by casually dismissing a possible shift in the C/M/T paradigm as "certainly outweighing" the upsides of helping out a team that isn't organized enough to check their perms before they log out (to extend your example), it either dismisses C/M/T as a foundation of SL, or dismisses inquisitive inquiry which would see us measure it, define it, architect it, and hold it up against a well-articulated goal set rather than proceeding on the assumption that usability trumps economic and cultural stability, however hypothetical it might be,

To be honest the entire permissions system needs an overhaul, as I'm sure many Lindens would agree.... but that is a difficult thing to do.

As for complicating the perms system introducing bugs - why can't we have power and simplicity both? Why don't we implement this (and perhaps other granular enhancements to perms) but leave them hidden unless the "advanced" menu is enabled. That keeps things simple for newbie builders and provides the functionality for professional folk or oldbies, who can wear their mistakes if they make them with this extra functionality like grownups. If they enable advanced perms options and make mistakes, well it's their fault - not a fault of the complexity of the perms interface.

The thing we forget oftentimes in any argument that touches on permissions is that they effect not only things bought and sold in the world, but the fundamental units of "physics" - the atoms the SL universe is made of. There may be private islands where folk jot down and prototype architectural ideas for example and want everyone to be able to tinker with each others stuff... or groups of folk who wish to engage in certain types of trade where the default permissions for their objects need to be different to the norm.

Please do it and soon!

Thanks!

Now I do agree that people that insist that everything they make needs to be full permissions need to declare this as an irrevocable choice at the account level and all their creations be made publicly available without copyright for use and/or free market resale for profit by anyone that wants to that is not an open source creator. I.e.; the open source crowd willingly gives up all copyrights to any content they create in Second Life. And they can never change their mind back.

Now that I have your attention...
I think this entire discussion needs to be grid wide and involve everyone that is account verified and only those who are account verified and be removed from the pjira now and escalated to a forum policy discussion amongst all account verified residents. In fact perhaps LL needs to remove posting privileges for non account verified accounts so we can ensure only legitimate adult customers have a voice. There is much more work needed on the content intellectual property rights management aspects of Second Life as well as intergrid transport permissions. Concepts such as next owner and subsequent owner permissions need to be developed.

As for people that want to declare all their creations public domain then as I mentioned above why not allow them to have special public domain accounts that have no property rights whatsoever? Just log into your no rights account and you no longer have any worries about permissions. The rule is you can never use any copyrighted content in anything so you have to use only public domain materials created by public domain accounts. Any public domain account that incurs a DMCA take down that does not file a counter and subsequently win in court would revoke that human's rights to Second Life and all content they ever created would be deleted from the asset system as suspect. Anyone that used any of it would simply have to perform damage control.

As you can see these are policy discussions and are well beyond the scope of a technical feature discussion so perhaps LL would care to freeze this proposal and escalate to a policy discussion right away and get the account verified community at large involved.

Further pjira access needs to be immediately restricted to account verified accounts only and all votes, comments, defects, and features entered by free/basic throwaway anonymous accounts be removed. That would be another policy discussion I guess but it is another issue that must be addressed since we have no way of knowing how many votes or comments for any issue are made by the same person using aliases and IP address proxies.

Do we need a pjira issue feature request to deal with all these policy matters or will LL agree and freeze this policy discussion that has been masqueraded as a feature request and get it moved to the appropriate blog forum area for proper discussion?