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.