InWorldz first to test new export permissions

It was more than a year ago when developers from the Avination grid and the Singularity viewer got together and created a new permission for OpenSim, the export permission. Since then, no major grid has adopted it, not even Avination itself.

Until now. But it’s not Avination rolling out the export permission, or one of the smaller hypergrid-enabled commercial grids, or Kitely, which has its own version not supported by any viewers.

It is InWorldz, arguably the most successful commercial grid, and the one with the most to lose.

Adding the export functionality has been seen as a risky move, a potential security issue, or something that might scare away merchants and creators.

And InWorldz is the most popular grid by traffic numbers — it has as many active users as the next five grids combined  as well as the most developed internal economy. But it is already testing the export permission on its beta grid.

The "Export" permission setting is already implemented in the Alpha version of the viewer. (Image courtesy Avination.)

The “Export” permission setting in the Singularity viewer. (Image courtesy Avination.)

The primary reason for implementing the export permission, according to InWorldz partner David Daeschler, is to clearly define the content that residents are allowed to download from the grid using a viewer’s built-in export function. Several viewers allow users to download objects as XML, OXP or Collada files either to keep as a local backups, or to take them to other grids.

David Daeschler

David Daeschler

Right now many third-party viewers will allow exports of any content that has full permissions by default for OpenSim grids, but require the user be the creator of all nested content when exporting from Second Life,” Daeschler told Hypergrid Business.

According to InWorldz developer Jim Tarber, there are cases in which creators want to distribute their content on InWorldz with full permissions, but don’t want to see the content leaving the grid.

So, in its initial implementation, adding the export permission would allow InWorldz to actually reduce the amount of content that is allowed to leave the grid.

But, eventually, the export permission could allow new kinds of exports, as well.

We do intend to use this functionality at some point in the future to support the export of region backup files in OAR and other formats,” said Daeschler.

Currently, InWorldz allows selective OAR region exports on a case-by-case basis, via support tickets. An export permission would allow the grid to offer automated region or inventory exports that automatically filter out all non-exportable content. This would make it easy for residents to make backups of entire regions, or entire inventory folders.

The InWorldz Beta grid has already implemented full support for the export setting, and it may be included in the next update of the main InWorldz grid if testing goes well, said Tarber in a recent comment.

A working export setting has also been seen as a prerequisite to allowing a commercial grid to enable hypergrid connectivity, as Kitely did late last month.

So is hypergrid now on the agenda for InWorldz?

“We have no plans for hypergrid or other connectivity protocols on the work list at this point,” said Daeschler. “We simply have too much other work going on.”

The only other grid that has something close to an export permission is Kitely, but  it does not use the Avination-Singularity code. Instead, this permission is only accessible to creators in the Kitely Market interface, and cannot be changed in-world.

Ilan Tochner

Ilan Tochner

“We started development of our export control system before Avination and Singularity announced they’re working on their own implementation,” Kitely CEO Ilan Tochner told Hypergrid Business. “Prior to implementing hypergrid we investigated the state of the viewer-based export permission and found that it wasn’t fully implemented. We therefore decided to utilize the Kitely Market export system which provides a lot more functionality than just a yes or no export flag. For example, if a buyer does a chargeback all copies of the bought item immediately become non exportable. If the chargeback is reversed  then the bought items revert back to the proper exportability setting.”

Tocher admits that their approach means that the export permission setting can’t be modified via the viewer.

“But the one provided through Kitely Market is a lot more advanced than the viewer-based system,” he said. “As we already have a better system via Kitely Market, we’re not going to spend time fixing the unfinished system that exists in OpenSim. That said, if someone else does so we’ll evaluate whether to harmonize our system to work with it and if so how.”

However, that still leaves open the question of how the “export” permission should work with the other permissions. Should items marked exportable be full-perms in all other ways as well?

“The question of what the default export permission should be differs greatly between a hypergrid-enabled grid such as Kitely and one which has a closed garden mindset,” said Tochner.

One issue is that exportability has a different meaning when it comes to downloading something from the viewer, or taking it with you on a hypergrid trip.

Traveling the hypergrid requires exportable clothing. Nobody wants to be a naked avatar. Well, mostly nobody.

Traveling the hypergrid requires exportable clothing. Nobody wants to be a naked avatar. Well, mostly nobody.

Say, for example, a user buys a shirt that is no copy, no modify, no transfer, but allows exports. This setting makes limited sense on the hypergrid — the user can now wear the shirt on hypergrid visits to other grids. But once the user downloads the shirt as a file to her computer, then the other permission settings instantly become meaningless — the download itself is a copy, it can be easily emailed to anybody, and once uploaded back into a grid, become, in effect, full perm for whoever uploaded it.

Of course, permission settings can be evaded on the hypergrid as well. For example, a user can teleport to a grid where they have “God powers” and change the permission settings, or change the setting directly in the asset database of a grid or region under their control. Or they can use copybot viewers to do pretty much anything they want on any grid anywhere, hypergrid or no hypergrid.

It’s a thorny issue that, right now, has no obvious solution.

Related Posts'

Maria Korolov

Maria Korolov is editor and publisher of Hypergrid Business. She has been a journalist for more than twenty years and has worked for the Chicago Tribune, Reuters, and Computerworld and has reported from over a dozen countries, including Russia and China. Follow me on Twitter @MariaKorolov.

26 Responses

  1. I can understand that for those who make money from their content, it is a scary thought about losing control of your creations. You have the perceived fear that people will start copying your items and ripping it off, and then you lose money – so in theory it could reduce your sales. If this money is part of your regular monthly income, and not just a little extra “pocket money” on the side, then I can see why people are worried, and why this is such a hot topic.

    However, as has been explained ad infinitum on here and on many other sites and blogs – locking content is not the answer. Copying goes on all over the internet from music tracks, to game software, DVDs and heck even with MS Windows. These large fat cat corporations cannot stop the pirating and illegal copying – even with their huge resources – it’s just not possible and to continue is banging your head against a brick wall.

    The only answer is to sell your creations to the metaverse full perms so people can use it. Focus your attentions on service and added benefits of buying the genuine article – make it worth while buying from you rather than copying.

    I have already bought an item from Kitely Marketplace – even though I am not a user of their grid. If Inworldz were to set-up a web HG marketplace. I would buy stuff no issue. Many of us in OpenSim WANT to buy decent, and genuine content, but are being prevented from doing so by an attitude of fear held by the majority of content creators.

    I know I will probably take a slating for my opinion, but I don’t care – this issue is too important.

  2.' Ai Austin says:

    The problem for me is not the export permission idea itself, its the bad way in which it seems to work with current viewers. Even items I create myself on my own grid and save as IARs seems to come back in with an export box that is greyed out or cannot be ticked or changed. Using Firestorm. Better defaults might help… but at the moment I think it just causes grief.

    •' Jim Tarber says:

      We’ve been investigating the grey box problem with the help of Singularity folks and have identified it as often being a problem of unexportable textures being used on prims. In our early tests on the InWorldz beta grid, we found the default/plywood texture was missing from the user inventory, causing an Export fail for a basic new box prim. And when using a texture that *was* in the Library (the white Blank Texture), the initial InWorldz server wasn’t marking it as exportable, so it too was a problem. We’re fixing that as part of the ongoing testing, but if you are seeing viewers with the Export checkbox but disabled/greyed out, I’d suggest checking or changing the textures to see if the Export checkbox comes on. (Although you might need to close the Edit form and reopen it.)

      •' Ai Austin says:

        Thanks Jim… that would explain a lot of the cases where the simplest things have export tick greyed out. If you find the root cause(s) and have a fix can you report it or make it available via OpenSim Mantis if its a server side issue.. or let the viewer devs know if its a viewer issue.

        The default plywood, blank, transparent and default media textures will appear in a LOT of builds and definitely should be considered as open to export.

        In the interests of open source code base and to encourage the hypergrid and an open metaverse that goes beyond OpenSim in future… I think the default should be export turned on.. unless a grid owner chooses to not make that a default… maybe it already is if this greyed out box issue is resolved?

        •' Jim Tarber says:

          Yes, I think that issue will catch a lot of users by surprise, but in our case it was mostly a server configuration problem. The five predefined standard texture IDs will certainly need to be treated as exportable, and that should resolve most of these cases.

          We have in fact been working with the OpenSim and viewer folks. If you check the Singularity bug report I posted at you will see that the key parties were made aware. In the end, no change was required to Singularity or the viewers; it’s my issue with not making those textures exportable in the InWorldz beta configuration (fixed now).

          Certainly in cases where Hypergrid exchange is your priority, it may make sense for the default to be export-enabled for existing content. However, that is not the case for so-called “closed” commercial grids like InWorldz where respecting the intentions of creator licenses is considered a key requirement. In that environment, the default for existing content must remain non-exportable, until the creator okays the item for export. InWorldz might enable inter-grid connectivity at some point in the future but it would not allow an open-ended export of existing content. (!)

          From my perspective, it’s important for content that gets exported to Hypergrid destinations to be full-perm content in the first place. I think the OpenSim model of the Export permission (requiring full-perm before you can enable Export) is a good one. It does help to encourage more full-perm grid-sharable content and I think that is a good thing. It is a nice compromise between the two camps of protecting creator content restrictions/licenses and encouraging full-perm open content on the Hypergrid. The OpenSim-defined Export permission will enable those users who want to respect creator licenses to legally bring content from InWorldz to other grids, because the Export checkbox enabled will be a clear indication from the creator that this is okay. I think this is a win-win for creators, InWorldz users, and OpenSim/Hypergrid (in fact all grids since none of this requires Hypergrid. A lot of InWorldz content will be tagged as exportable (there are a lot of free/open items in InWorldz) and support in the viewer means objects can be exported in the more convenient .OXP export format for use on any grid when the creator okays it.

          InWorldz wants to promote OpenSim and virtual worlds in general. We’re all one big industry that is under-represented. We all have our different opinions, priorities and different concerns and needs of each separate userbase, but if we take a step back and look at the bigger picture, we’ll achieve more if we spend more time highlighting the strengths and benefits of virtual worlds in general, instead of trying to pick apart some specific things we don’t like about one grid or another. The IW “Future Initiative” described at is an example of how InWorldz can still help to support all grids in their growth.

          •' Ai Austin says:

            Good notes Jim.. and I for one do appreciate the inputs to the core server and viewer software to help everyone in the community.

            The idea that Hypergrid exportable items must have ALL elements and testures checked for exportability is a good one to prevent the sort of export greyed out issues.. and it will be great if it turns out a lot of the issues are due to the standard built in textures and that can be fixed.

            But judging by issues we have had over the years even between team members building together in Second Life, we always struggled with some deeply embedded item (script, texture or object inventory item of sine kind) that did not have the right permissions. A way to have everything by default full permission and exportable and then allow a iuer to untick the top level object export button to fix it to a soecific grid would surely help?

          • I’m torn about this, On the one hand, in any practical sense, I understand the argument that permissions are guidelines more than anything else, since there’s no real way to protect digital content. So if they’re guidelines anyway, why not allow export but also allow exportable items to have no copy or no transfer? On the other hand, if creators want to release items to the hypergrid and don’t want them transferred or copied, they can provide the same kind of guidance in the form of attached license terms.

            And, at the end of the day, ANY working export permission — whatever the conditions — is better than none.

          •' Jim Tarber says:

            Maria, I don’t think that last sentence is accurate if you are a content creator who sells anything other than full-perm items.

            For full-perm items, there is an implied trust that the creator’s license terms will be respected. One of the nice things about the OpenSim Export permission is that this *implied* trust is made *explicit*.

            For permissions-restricted items, the creator is expecting the grid to protect the restrictions. If I mark something as no-trans and give it to another user, I don’t think it ever makes sense for a grid to *assume* that it can be exported. It may be possible for a grid to export it if marked no-trans AND also exportable, but there the grid has been given specific export permission from the creator. The creator is saying “I know that once it leaves this grid, you cannot assure me of no-trans protections, but I want to enabled Export anyway.” However, anyone who does so probably should just make it full-perm anyway with a documented license in a startup message or notecard, because there are no no-trans protections once it hits the Hypergrid.

            To me, “guidelines” is propagating the myth that selling an virtual world item is giving up IP rights of the creator. These are NOT guidelines. These are usage licenses for intellectual property issued by the creator. Just because someone has provided something for use on one grid (even full-perm) does not mean it’s automatically available to be exported for use on another grid, even by the same user. (I have plenty of texture and other license that are specific to one or two grids.) So from my perspective, a grid cannot just dream up it’s own license rules for the creations of other users that supersede the license of the creator. Likewise, a grid cannot retroactively expand the license of it’s content creators to include external locations, not managed by that grid, where the content protections are weaker. So I fully support the full-perm, explicit Export permission designed for OpenSim, and that is the direction InWorldz is going as well. And to the best of it’s ability, a grid should try to respect the intentions of the creator’s license. It’s very difficult to know the intentions, but if there are permissions restrictions on an item, such as no-transfer, it certainly suggestions that the grid should err on the side of protection rather than propagation to less protective environments.

          • What I meant by perms as being “guidelines” is that no grid can guarantee the security of the content on its grid. Someone who is dedicated enough can figure out a way around DRM. Permissions don’t protect content creators against hackers — permission tell honest users what they’re allowed to do and not allowed to do with the content.

            That doesn’t mean I think creators should just give up on protecting their content, or that copyrights are meaningless. (Which leads into a whole other huge discussion but, as a content creator, I’m REALLY on the side of creators’ rights to decide on how their content can be used.)

            My point is that I can see Kitely’s point of view, and I can see the Avination/Singularity point of view, but I also think that either one would be better than what we’ve got now, which is, effectively, no export permissions on content other than on Kitely (and now, on your beta grid).

          •' lmpierce says:

            Maybe a different word to convey your meaning would be “notifications”. That is, permissions function as notifications of what is permitted, aside from any actual locking function.

          •' Ai Austin says:

            Just to be clear for my own part, I have absolutely no problem with content creators setting their licence and indication of the usage rights as they wish, or with some grids making their defaults for exportability be as they choose.

            What I am concerned about is to encourage the “out of the box” defaults for the core OpenSim to work well and encourage open source and sharing where feasible and appropriate, and especially for those that INTEND objects to be full permissions and exportable not to have the serious hassles and issues (bugs?) we current have since the export tick box was introduced.

            Its good to see Jim’s attempts to pin down the simple cases that might have been preventing this working as intended… and the follow through to make the necessary fixes in core OpenSim I hope will be possible.

          •' Jim Tarber says:

            Ai, for what it’s worth, I probably wasn’t very clear. I fully agree: the default in the OpenSim source code (“out of the box”) should probably be export-enabled. I think that is best left to the OpenSim developers and community to decide that default, but that seems like the best fit for me. This is because that is effectively the default for viewers on OpenSim networks anyway. But once it is installed on a particular grid, some grids (especially commercial ones with a lot of existing content in regions in stores) will probably want to change that to require an explicit ok from the creator for export.

            So where I differ from that is the more closed commercial grids (specifically InWorldz), where whatever protections offered are expected to continue. The “wide-open” problem (for us) with viewer exports under OpenSim builds is mostly resolved by implementing the Export permission in the viewer. Returning ExportSupported=true at region connection time is enough to switch the viewers out of that mode and look for the Export perm. And in that case, I think it’s important to protect the existing content and new builds by default. (You can’t close the barn door once the animals have been released to the outside.)

            I think the needs of each grid can vary quite a bit, based on their resident community and business priorities, but I don’t really think too many people have an issue with protecting the licenses offered by content creators. It’s the subtle interpretation of how to handle the changes to the permission system when something new is introduced. So I also agree with what Maria wrote about each grid’s point of view. It’s just that I think having Kitely introduce something *completely* different that is also called “export permission” is not going to be a good thing, but lead to confusion. Permissions are already difficult enough to understand and implementing something significantly different than what Singularity and OpenSim introduced a year ago is going to confuse many. Also, providing protections from the marketplace, trying to extend that beyond the grid, but leaving the viewers wide open when logged in on Kitely, really seems to undervalue the existing shops and creators on the grid. It seems to me that this would actually encourage people to close up shop and move only to the online Market. This is why I asked if there were plans to pivot away from grid hosting more towards the market business. Or perhaps, like InWorldz, it’s just part of a long list of work items that just aren’t complete yet, and there are plans to eventually support it in the viewer too.

            But also I think it’s a complex problem with many factors and that we are still at the beginning of this, exploring and trying to find the right fit and the right combination to work well in practice. It’s may be a year old in theory, but if InWorldz is the first to actually go live with the OpenSim-style export permission support, then we are still at the pioneer stage for Export permission. It will probably require a bit of fiddling with the controls, for each grid, until we get something acceptable to each grid. And the results of that will probably vary from grid to grid, and that’s okay. The needs differ, and that’s partly the beauty of software that comes from open source, it can be adjusted to suit needs.

          •' Rene says:

            I think that forcing the MCT perms to be full before permitting grid exportability is building on bugs and limitations that might be fixed in the future. The export flag should not be conditioned on the other permissions flags because I can well envision a future in which two grids choose to work together to enforce user permissions content harmoniously, and that they wish to permit fluid movement (however secured) between them. The same holds true with creating backups because again I can envision technical means to protect the backed up blob from changes, So, keep it simple. Use the export flag to mean just that. The AND of the export flag across all items in an assembly determines exportability (remember you can have compound objects too).

          •' Jim Tarber says:

            Actually, at this point it’s just proper user interface, providing appropriate feedback to the user, because the whole design of the OpenSim Export permission is that Export *implies* full-perm. There are server-side checks in OpenSim, but it’s good U/I feedback to the user to block invalid operations at the client end first. I think the Singularity viewer folks make the right call on that one.

            But you have a good point in terms of alternative grid implementations. We don’t need to foresee the future on this one; we already have the Kitely alternative and for that, this viewer behavior would prevent some of the legal export combinations at Kitely from being used, if they enabled the ExportSupported option in the viewer. It’s not currently a problem because they haven’t, but this can be easily extended by adding additional options, such as something like VariableExportPermission=true to allow a grid to specify that the viewer should relax the U/I and let the server handle it.

          •' Jim Tarber says:

            That is pretty much the purpose of the Permissions button on the Edit form. You can change all Contents in all prims, and do so by item type. e.g. you could make everything no-trans, then change all scripts in the object to no-mod/no-trans.

            Also in InWorldz, we have a wealth of script functions that can check on the Contents, including the items in other prims in the same object. Some time ago I provided a script that can just be dropped into a complex object that will then seek out and report any permissions settings that are inconsistent with the permission set on the object itself. So that for example if you make something copy/no-trans, and it finds something no-copy in the object, anywhere, it will report that to the owner, with the name and type of Contents item, link number, prim name, and location of that prim:

          •' Ai Austin says:

            Jim, are library textures in the core openSim code set to allow export, or just in the code branch for InWorldz? Do we need to draw this problem to the attention of the openSim devs and other non-Singularity viewers like Firestorm?

          •' Jim Tarber says:

            Yes, absolutely. The InWorldz code is quite different from the OpenSim code, but there was something simple I could search for (the Library root folder UUID) so I looked just now and it seems that the OpenSim code does have the same problem. It will be a few days before I have things sorted out but I’ve updated that Singularity report so they are aware it affects other grids too: I’ve also posted an OpenSim report at

            There doesn’t seem to be any change required to viewers, although they might want to check for the 5 predefined default texture UUIDs and treat those as automatically exportable. This would also save on inventory searches to find the matching textures, as those could be optimized out if it was one of the 5.

  3. Its good to hear other grids are starting to look at using an Export perm of some kind. I would also love to see some sort of co-operation between Kitely and Inworldz. I think it could work well for both Grids if Inworldz used the Kitely Marketplace, at least until they can get a competing one up and running.

    Kitely merchants would get access to a large potential market, and Inworldz creators would get access to a powerful Marketplace solution AND could sell to HG if they so wished. Ultimately it means more content for everyone and with so few creators around, that can only be a good thing.

    *sigh* I can dream cant I? =)

    I tried opening a store in Inworldz a while back but between SL AND Kitely I just don’t have enough time, and Inworldz was the looser primarily because of the lack of a working Marketplace.

    Ultimately it has been shown that locking content does not work. There are no easy solutions. The ubiquity of copying has forced prices down and people expect top quality at very low prices these days. With things like movies and music, with millions of potential customers to draw upon, there is still money to be made for smart businesses, but for a niche product like ours it really puts the squeeze on. Second Lifes land prices didnt/still dont help the situation as it turned every land owner into an ueber bargain hunter and now people are used to paying a certain price for things.

    People often point to things like Itunes as an example of where DRM free content is working. This is slightly deceptive in my opinion. Itunes is doing very well for Apple. For the artists that actually make the content…..not so much. I was reading recently about some very famous musicians talking about their royalty cheques from Itunes and it would be funny of it wasn’t so insulting.

    Regardless, the best strategy is to make your products as available as possible to as many people as possible. Period. If you lock content into a specific grid or format, you are simply denying yourself potential sales. Somebody last month purchased A LOT of export items in one session at my store. I would never have made that if I had chosen to just sell within Kitely. All for the strenuous extra work of ticking an extra check box.

    • Hi Ozwell, I get what you say about itunes being good for Apple, but not for the artists- but that is Apple, and I guess the artists could if they were so minded, set up a rival platform that provided them with a bigger cut.

      It is a bit like Kitely taking a huge cut from their marketplace – there is nothing to stop content creators coming together and setting up their own web based market place – cutting out the middle man (ala Kitely and others) and selling directly to the metaverse, and keeping almost 99% of the proceeds of their sales.

    •' Minethere says:

      While you certainly “can” dream-)) the reality is that many inwz creators fall into one or more of several mindsets, some by disinformation, some by blind loyalty, some by sheer lack of imagination.

      But, also, for every one creator who sells only in this grid, there are likely 4 who go in a circular login daily to several of the other closed grids trying to sell there also, and taking whatever change they can in each one to hopefully make enough to either augment decently or fully support their real lives.

      However, my reading and watching around places has shown me a growing number of creators from there moving out…those are ppl who actually do see things in real numbers via their sales, and nothing done anyplace, and nothing said anyplace, will stop them from seeing their own reality.

      Now, this latest blog from the owner of the elf clan in that grid, who also has various alts controlling other facets, while showing questions that need answering, also shows this kind of mindset of some there. Personally I see it as the front tip of the iceberg to deeper problems, as is even indicated in some of the words. One should read further of the blogs, if they wish, to get an even better picture of this. Now, snoots/wayfinder/peter/etc is someone, while I was still somewhat involved there, and still a member of elf clan because I had really liked some ppl in it, is someone whom I showed about OARs in the first place, unless it has been deleted there, anyone can find those blogs where it was discussed. However, I was already going out the door, and my personal feeling was to try and open the eyes of as many as I could there to the realities of the greater Meta, and by simply showing one cool aspect [and SOAS] it could give them something to chew on and meditate about. See this latest blog example here;

      As well, unless inwz integrates their own MP [or buys out Anna] with their grid, AND allows the folx there to exercise their free will and adult decision making to decide whether or not they will export out to the greater Meta, I seriously doubt Anna, of InBiz will do such a thing on her own.

      Anna and I were pretty tight when I was in that grid, to the point that when I got back in from my little nonsense with beth/elenia Anna offered me a job working for her, for pay, and pay commensurate with what I had been making previously with the land baron I had worked for [50k iz], and I would have had to work much, much less. I accepted initially but then decided I could no longer help her properly, and resigned. So as I had been doing in some small regards, previously, I continued to do some small things in the background [and was still EM on her InBiz region..heck, I may even be still…lol] to help her in small things she asked of me, for free, until I found the free meta and left that grid for good, after more fully realizing how backward and boring they were.

      Anna and I still email occasionally and I consider her to be both smart and a friend, to this day. I also always liked her. She knew me for who I really was, not some trumped up nonsense from ppl with agendas, she could care less for such talk.

      The point of all that tmi, lol….is that it is very doubtful that Anna, who runs the most successful MP in that grid, will ever do something such as add some kind of perm/export thing on her own for ppl to have choices.

      That said, since inwz, in all sorts of ways, lives in it’s own little perceptions of reality, and thinks it is better than the greater Meta [tho more and more are seeing a glimmer of light, even long time supporters] it is highly doubtful, if not impossible, that they would ever deign to allow the Kitely MP to sell to them….and for a very good reason [thinking as they do and knowing several of the key players]..that being that they do not wish the majority of their residents to fully understand the innovations and advancements of the greater Meta, because then they will lose even more residents and regions.

      Many people there, the rank and file, and promoted by the actual movers and shakers there, live under the illusion that inwz is the most innovative grid around, some even thinking that the recent NPC coded they brought in from us, is actually their own invention and better than anyplace else, which is utter nonsense as we all know well, but an example of what I am referring to.

      While people can wish away certain things, and refuse to see reality for what it is, or have obvious agendas behind dismissing the greater Meta, nothing there changes the real truth…and as more and more see this, this is why the greater Meta, especially the hypergated Meta, is actually growing, while those in closed systems are not, are worried, are fighting in every way they can to stop it, are trying in every way they can to convince their creators that inwz is the safest place to be…and most of us know this is just a fallacy, for all sorts of reasons.

      Frankly, I would be one of the first to applaud them enabling HG, but the fact is that they are so entrenched in saying that is not a good idea at all, I doubt it will ever happen…and their latest little townhall meeting speaks to this, quite well. Rather than embrace the tech of the greater Meta [and actually even to their detriment tho they will never see this] they are thinking they can bring in ppl from the outside, who have no clue about the rest of the Meta, and thus inculcate them to the inwz mentality.

      This will fail..mark my words-))

    •' Jim Tarber says:

      Yes, this is exactly why I think it’s important to follow the OpenSim model of allowing Export only of full-perm items. It may not take long after something leaves a commercial grid for it to be potentially abused. So it’s important to protect the content from leaving the grid in the first place, by:
      1. assuming no content is exportable by default, and then by
      2. requiring it to already be full-perm if it’s going to leave the grid (since perms aren’t really enforceable after that), and then
      3. getting an explicit okay to export it from the creator.
      The viewer-based protection for content, provided by the OpenSim-style Export permission, *strengthens* the protections for content. Without it, many viewers will default to a more open export capability, including the mainstream viewers. At least that’s my perspective on it and why InWorldz is jumping to get Export permission implemented. I know there are different perspectives but I think to make a trade-off against this protection means they clearly don’t rank on-grid content protection as high as other priorities. At InWorldz, protection of creator content is top priority.

  4.' Samantha Atkins says:

    Frankly I don’t feel good about any content creator telling their users that the content can only be used on one grid. It is like buying a car that you can only drive in one state or region. Particularly if an item has modify permission it may not be just or even primarily the creation of the original creator any more. For instance I buy furniture and other goods and add various scripted additional capabilities. Or I buy a set of full perm anims to add to my own and modifiable creations. Why should I be limited in taking these out of grid?

    The other important part of export is having a backup of your most cherished virtual possessions. I don’t see why a content creator should be telling me whether or not I can back up my property.

    •' Samantha Atkins says:

      I think something more radical is a better solution. Asset storage and management as a separate service from any particular grid plus user identity that can persist or be aliased across grids. A large part of content insecurities of this kind is that each grid is its own content silo instead of taking a page out of more distributed persistence systems.

    • A content creator has the right to decide how their content will be used. After all, they created it. Respecting their wishes is the right thing to do. Plus, it’s the law.

      However, there’s no reason for you to do business with that particular creator. I encourage readers to reward those creators and merchants who put their customers first by making it easy to do backups, to take content to other grids, and to modify content when needed.

      I do believe that putting restrictions on content, such as restrictive permissions or digital rights management, hurts legitimate users while doing nothing to stop piracy. Pirates will pirate, DRM or no DRM. The way to fight piracy is by keeping an eye on the major distribution channels to make sure your content isn’t showing up (right now, in OpenSim, that means the Kitely Market — there’s really no other place right now to sell content across the hypergrid for money) and to make it easy and convenient for legitimate buyers to buy your stuff.

      This is why most of the major digital goods marketplaces — iTunes, Amazon, etc… — have moved away from DRM. DRM means that a legitimate customer buying music (or other digital content) can’t make a local backup, can’t use it on other devices, and, yes, can’t share with friends. Pirated content, stripped of DRM, has no such restrictions. When those restrictions were in place, the music and movie industry was, in effect, giving the pirates a big marketing advantage — the pirated product was actually better for customers! By removing DRM, the quality issue was immediately reversed — now the official, legitimate content is more user-friendly, and the pirated content is now only distinguishable by having viruses and trojans.

      Again, I’m not saying that creators should give up on protecting their products just because the pirates can break DRM or permissions. I’m saying they should adopt a two-phase approach:

      1. Make the legitimate content inexpensive, easy to find, and more useful to their legitimate paying customers than the pirated alternatives.
      2. Go after the pirates whenever they become visible, by filing DMCA takedown requests with store owners, grid owners, and marketplace owners. All grids today are operating on a shoestring — none can afford a copyright infringement suit — and I don’t know of a single grid that wouldn’t bend over backwards to get infringing content off its grid and removed from user inventories.

      And, as customers, we will all benefit if more merchants take this path because we’ll have more content, better content, and more usable content. We can help steer creators in the right direction by rewarding those who distribute their content with export rights by buying their products, and by speaking up when we see their products being distributed by asking the merchants if they have distribution rights, asking for license terms to be clearly posted in stores, and notifying grid owners if you see something particularly suspicious, like a back-alley freebie store distributing a lot of high-end content from different designers even though that content is sold elsewhere for money. .

      •' Samantha Atkins says:

        Only somewhat. As Lawrence Lessig pointed out in “Code” in the digital realm we have the ability to impose much more restrictive terms on use of items. This does not mean we should. I think you are missing a main point or justification for “the law” which is the right of the creator to profit from their work. I think enabling that can be done without to onerously restricting the rights of the consumers / users of that work. This is especially important when a work may be an element within a larger creative work. Then licensing terms on the sub part can have the tail wagging the entire dog or determining if it can be a dog at all. Clearly we do not have perfect means for the legitimate intent today and need work in this area.

        There is reason if I need their work as part of mine. I do not have unlimited time and resources to learn out to do all things myself or even contract out to have something more to my liking built. It is a perennial complaint that even if I did contract out I cant actually own the result I contracted for due to limits in the permission system and the way we think of virtual world bits today. There is no way to do most open source licenses for instance in a meaningful way or even many of the Creative Commons ones.

        I agree about DRM and DMCA. What a mess! And as the physical world becomes more and more just information and bits we see the virtual world as both forerunners of things to come legally and victims of floundering digital rights and IP law in the physical world.

        I dream of a system where creators are rewarded proportional to the use/value others find for their creations without restricting use much except for matters like attribution. It would be great to get to a world where you want people to share and copy your work widely distributing it at will at it increases your own returns the more people use it.

  5.' Adam01time says:

    It has been a while since this thread came out and I have taken time to look at some of the code. Blah blah. But here the fact if you had as many paying clients premium accounts and not just land owners then you would just start to understand why SL did what they did. It was actually to protect there clients. How!. look you have to see the actual law cases that was going on. Secondlife stepped up and said ok now that you have given this to us we can actually defend this grid and this creation as a corporation.

    The Moment you think Secondlife is stealing from the registered premium account clients you show just how much you do not know, Seconmdlife doing this has laid a foundation and have stepped up and created a tool to protect the clients from law suites. And at the same time created an avenue to handle illegal material or grey area material. You grid owner should actually look at this model.

    Because the first time one of your largest land owner gets slapped with a huge law suite and there is nothing but to kiss that income good by you will begin to look at the other side of the coin. They in since became a partner ship with the clients.
    Since these so called grids that sale tokens. yes tokens not actual currency.
    When you through your little temper tantrums at people for posting stuff and you turn off the account what do you do with the money.

    I know what SL does with premium accounts they have a certain way to go and it is a simple phone call to billing. Who is really the threat Secondlife or some one that is mad at an account.
    Do not tell me it does not happen. Because it is being documented everyday. since there is no premium accounts in that so called popular grid. And i wonder how easy it is to get your tokens turned back to money. Remember you cant post in their forum and they delete your emails and now your account does not exists. You have pay pal or credit card transfers but no proof after that. So your worried about money. Hell Avination to my 10 dollars a long time ago never put it on my account I never went back. how can I prove it. or How about my tokens in Inworldz how can I prove it. people it is the money. Do not let the slide of hand think it is creator problem that is the least of your worries. That can be handled many ways.