Avination, Singularity create “export” permission

Metaverse security took a big step forward today as Avination donated OpenSim code implementing an “export” permission setting. The company also worked together with Singularity viewer developers to add support for this new permission to the viewer.

Today, OpenSim has three permissions — copy, transfer, and modify — that determine what users are able to do with their content. However, there is no permission setting for exporting content out a grid because the permissions were inherited from Second Life, which does not allow this functionality.

Creators can now decide whether their content can be exported or not. (Image courtesy Avination.)

Creators can now decide whether their content can be exported or not. (Image courtesy Avination.)

OpenSim, however, has three ways in which users can export content — OAR exports which save everything physically located on a region, IAR exports which save a user’s entire inventory, and hypergrid teleports which allow content to be carried from one grid to another. In addition, people who run their own OpenSim servers can give themselves “God powers” that allow them to change existing permission settings.

To keep content safe, commercial grids prohibit their users from connecting regions run on home-based OpenSim servers, disallow “God powers,” don’t offer OAR or IAR exports, and turn off hypergrid teleports.

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

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

The new “export” permission setting will allow grid owners to configure their grids so that only exportable content can leave via hypergrid teleport, or via OAR or IAR exports.

As a result, commercial grids will be able to offer hypergrid connectivity and backups to their users and, as long as “God powers” are prohibited, still be able to protect proprietary content.

Melanie Thielker

Melanie Thielker

“The code will be released ‘as we go,'” Avination grid founder and OpenSim core developer Melanie Thielker told Hypergrid Business. “People will be able to see, comment and improve on it while we work. Other viewers can extract the code from the Singularity code base, which is, of course, open source, and integrate this feature.”

Avination has donated code to OpenSim before, most recently the multi-attach feature. Typically, however, donations by commercial grids come after enough time has passed for the grid to profit from its own invention.

That is not the case this time, said Thielker.

“There will be no delay between the development and the release to OpenSim core,” she said. “This feature is an important milestone and should go out there without delay. We recommend that viewer developers wait a few weeks before taking code from Singularity because the viewer side still needs debugging — as does the server side.”

Although creators will need to use Singularity or another viewer which adds the code in order to set the “export” permission, the permission will still be in effect even if the eventual purchaser of the content uses a different viewer.

Attempts to export non-exportable items will have no effect, just as if the user had attempted to copy a no-copy item, or modify a no-modify item. The viewer simply allows the user to see what the setting is, or change the setting if they are a creator — the actual decision to allow the export or not will take place on the server.

The export flag not only allows users to take some content from one grid to another, but also to have the same appearance wherever they go.

Creators who allow the “export” functionality on some of their items will be able to see their brands spread throughout the hypergrid, the company added.

The new export permission will not keep determined hackers from stealing content, however. Various tools and methods are in use in Second Life, for example, where the much larger array of available content makes it an attractive target for content thieves.

The new export permission code will become part of the OpenSim core code, Avination said in its announcement today.

OAR and IAR export checking are not part of the donated code base, however. Adding export permission checking will be up to other developers, said Thielker, who work on that part of the code.

Similarly, the code donated today does not address the issue of saving objects as XML files.

“The viewers do their own permissions checking,” she said. “Viewers with export functionality could implement support.”

The most popular viewer today for XML object exports is Imprudence, but that viewer is no longer actively supported.

Justin Clark-Casey

Justin Clark-Casey

OpenSim core developer Justin Clark-Casey, who also heads up the Overte Foundation that manages OpenSim development, suggested that other viewers either wait for the work to be complete, or actively work with Singularity and Avination on the development.

Those interested in finding out more, or in contributing to the effort, can follow the OpenSim developers mailing list, or check in on the OpenSim Developers chat channel, he added.

“This is a work-in-progress,” he said.


Changes in licenses

Today, there is a default, implied content license associated with the OpenSim permissions system. Users are allowed to transfer some items but not others, copy some times, modify some items, and these rights can come in any combination.

And, by default, all content is licensed only for its grid of origin, unless the creator specifically steps up and says otherwise — say, in an attached notecard.

The new permission setting comes with a new implied license.

“Exportable items can be taken to any grid without worrying about licensing issues because an item marked as exportable means that the creator has licensed the item under a permissive open license that allows use of the item anywhere,” the announcement said. “Exportable items can be taken to any grid and can be given, traded and sold as the current owner sees fit, without any royalties and without violating any laws.”

As a result, items that can be exported become, in effect, transferable and copyable.

This may be due to the fact that with export allowed, users can take content to a grid where they have “God powers” and then change any permission setting they want.

Kitely CEO Ilan Tochner

Kitely CEO Ilan Tochner

But this view of the export permission could also cause some confusion, said Kitely CEO Ilan Tochner.

“A permissive content license shouldn’t be forced on merchants or very few of them will agree to sell items this way,” he told Hypergrid Business. “I think that Copy, Modify, and Transfer permissions should continue working as they do now even when an item is brought over via hypergrid.”

Someone who uses “God powers” to break those permissions would be guilty of breaking copyright law, Tocher said. This would be the same as if someone had use another hacking tool to, say, “copybot” an item.

“It would be very bad for the metaverse if people associate allowing content to have Export permission with the content creator losing control of what can be legally done with their creations,” Tochner said.

Kitely is currently implementing its own export permission as part of its Kitely Marketplace. Kitely has also donated code to the OpenSim community that allows grid owners to filter OAR exports so that, say, users can only save content they themselves have created, or only full-perm content.

According to Thielker, there is no way to control what happens to content after it leaves the grid, and letting creators think so would give them a false sense of security.

“Grids may not have any permissions, or allow any region owner to zap permissions, like OSgrid,” she said. “It must be understood from the start that permissions restricting the use of an item are plainly unenforceable once grid borders are crossed. Therefore our implementation requires the items to be set to full perm before the export flag can be set.”

Creators who want to set further restrictions can do so in the form of an attached license, she said.

“And the current state of the metaverse shows clearly how much store people set by such licenses,” she added. “This is why allowing normal permissions on an exportable item is a sham that will lead to disappointed creators, irate users and possibly lawsuits against the grid operator.”

Securing hypergrid access

In addition to keeping proprietary content in, some grid owners are also concerned with keeping hypergrid travelers out, particularly griefers and hackers.

Currently, there are few options available.

Griefer spheres on FleepGrid. (Image courtesy Chris Collins.)

Griefer spheres on FleepGrid. The same attacker also hit the Hyperica grid, scattering spheres and moving furniture. One solution to this particular kind of mayhem is to turn off building rights for everyone except approved users. (Image courtesy Chris Collins.)

“Grid operators can restrict hypergrid visitors based on their grid of origin,” said hypergrid inventor Crista Lopes, professor of informatics at the University of California, Irvine.

Crista Lopes

Crista Lopes

And grids can turn off hypergrid access altogether.

“But I am planning to restart working on access control very soon,” Lopes told Hypergrid Business.

Turning off hypergrid access to a single grid in order to deal with a small number of griefers can cause significant public relations problems for a grid, as has recently happened with OSgrid, as innocent people get caught in the ban.

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.

40 Responses

  1. trrlynn73@gmail.com' Minethere says:

    interesting…and wonderful-))

  2. chibo.ryder@gmail.com' Chibo Ryder says:

    This is great news! Always happy to see developments which will help connect OpenSim grids, commercial or free, for the greater good of their residents and the Metaverse community as a whole.

  3. n.j.zwart@gmail.com' Nick Zwart says:

    very good news.

  4. ilan@kitely.com' Ilan Tochner says:

    The fact that grid owners can technically ignore copyright law doesn’t mean we shouldn’t allow people to set restrictions on how their content can be legally used and try to enforce those restrictions whenever possible.

    If we force merchants to give up all control of their content if they allow it to be exported from a grid then we are limiting the amount of content that will be transferable to only include freebies. What merchant that wants to sell content would agree to sell an item just once and then have it become public domain?

    This type of forced freebie licensing in order to be able to move content between grids makes the Export permission close to useless.

    Anyone copying something they shouldn’t (because they don’t have the permissions to do so) is breaking copyright law. Merchants should have the option to decide that they sell something to only one person and allow that person to take that item with them when they travel the metaverse without losing legal (and as much as possible technical) control over the content they created. Stating that an item won’t be able to leave the grid unless the person who created it allows turning the item into public domain will hurt cross-grid sales.

    This type of Export permission equals freebie logic doesn’t go hand in hand with having a metaverse where people can take content they bought with them when they jump between grids.

    • arielle.popstar@gmail.com' Arielle says:

      HYpergrid is not always safe when wearing clothing and jumping between different versions of opensim grids and standalones. Users frequenting hypergridding should always have a copy of the clothing they value because there is still the risk that an item or 2 will be lost on any particular jump.
      Protecting the creators is a wonderful thing but so is protecting the consumer.

      • ilan@kitely.com' Ilan Tochner says:

        Hi Arielle, we all want consumers to be able to not lose content they bought when they hypergrid travel, but in order for that to even be an issue they first need to have content they can buy and take with them to other grids. If we scare away merchants from adding the Export permission to items they sell then items won’t be sold with the Export permission and the only legal option consumers will have when traveling between grids is using their own creations or freebies they can add the Export permission to. If that happens then the existence of the Export permission will not enable you to take content you bought with you when you travel.

        If a bought item has Copy permission then the person who bought that item can create copies before hypergrid teleporting to other grids. The merchant doesn’t need to give Modify or Transfer permissions for that to be true.

        Protecting consumer’s rights doesn’t require forcing merchants to only be able to sell items with the Export permission if they also make the items full perm and give an implicit license for people to do whatever they wish with them. Consumers interests can be much better maintained if we allow adding the Export permission to an item without requiring the item to be full perm because then people will actually be able to find items to buy that have that permission.

        • arielle.popstar@gmail.com' Arielle says:

          Ilan I suspect the issue is that you see this new permission setting as something geared to commercial content creators looking to market their products on the hypergrid market whereas I see this setting for the Linda Kelly style creators wanting an quick way of letting people know whether or not it is ok to include a particular product inside oars, freebie shops etc.

          • ilan@kitely.com' Ilan Tochner says:

            There isn’t any reason to design this feature for only one type of content creator. People who want to offer freebies will be able to do so even if adding the Export permission doesn’t require them to make their content full perm. However, people who don’t want to offer freebies won’t be able to add the Export permission if doing so will only be possible for full perm items that come with an implicit legal license (“Exportable items can be taken to any grid and can be given, traded and sold as the current owner sees fit, without any royalties and without violating any laws”).

            For every content creator like Linda Kellie, who creates and freely gives away their own content, there are hundreds of content creators that try so sell the content they create and aren’t willing to give it away for free.

            If we adopt a solution that only works for freebies then the amount of content that people will be able to *legally* take with them when they travel the metaverse will be very limited. If we want to encourage content creators to move from closed grids to hypergrid-connected grids then we have to provide them with a way to sell their content, allow it to travel the metaverse but not make it a freebie.

            Adding and enforcing this freebie-only restriction takes more work, and reduces the usefulness of the Export permission. It is not required technically and will come at the expense of many consumers and merchants alike.

  5. services@farworldz.com' Gaga says:

    I wonder if this means Avination will be considering it’s time to enable hypergrid. I hope so and I think they are doing the open Metaverse such a wonderful service in contributing so much new code. Kitely and Avination deserve to succeed and I for one will be spending some of those savings I have been making from avoiding Second Life when I travel the grids as more open up to the greater market. The export perm is both an exciting and also an interesting development. I will certainly be taking a close look at it and try to get a handle on how it will work in practice.

  6. anonymized-843688006@disqus.com' Guest says:

    “Turning off hypergrid access to a single grid in order to deal with a
    small number of griefers can cause significant public relations problems
    for a grid, as has recently happened with OSgrid, as innocent people get caught in the ban.”

    There were no griefers, HG was turned off solely to metropolis in a lame backfired attempt to stem to tide of residents leaving due to the problems with hiro-admin verbal and posted attacks and insults on people’s avatar choices and all the rest that went on that caused people to see the light and move out to a grid that is more open.

  7. richardus.raymaker@gmail.com' Richardus Raymaker says:

    This option is good to have. But also a note,
    SOfar i see this option works best for HG regions where 1 person manager the regions and run the servers. or a grid that have only 1 central server manager and region owner. on mixed grids like osgrid i dont see any limiting of export objects.

    This can be a boost for Hypergrid, because owners can protect there items to keep it local and still give some things away to visitors to. SO, i say looking good.

  8. arpholdings@gmail.com' AviWorlds says:

    Well we cant ignore the fact that even in a CLOSED COMMERCIAL grid people can copy things from another creator without permissions and still place it in their computers. This is called COPY BOT. Does the new export or not ,function stop people from doing that?

    As you all know Second Life is the biggest exporter of copy bot items and it is a closed commercial grid.
    Please explain.

  9. hansoff@gmail.com' Hans says:

    Nothing is safe, if its in a closed grid, open Grid, Underground or in space all gets copied thats the bottom line. Now i would say be safe in HG travel use a Alt where is your main account don’t get corrupted.

  10. richardus.raymaker@gmail.com' Richardus Raymaker says:

    Useing that need extra effort to use it. but its now setup that you can transfer objects sleeping. so that bit is just extra layer that makes everything better. and offcorse you can always copy things.

  11. sylentwatcher@yahoo.com' sylentwatcher says:

    If secondlife could never stop copy botting or open gl or open al ripping of entire sims and every obj and texture in less than 6 seconds what makes ya think a bunch of hobbiests and weekenders will ever do any better…you all make me laugh very deeply …heck avination is so vulnerable its not even funny …and lead core developer …safest grid is inworldz …flat out.

    • whitestarm@gmail.com' WhiteStar Magic says:

      Anyone that wants to copy stuff and has the KNOW HOW how can do so with the tools available on the internet. Some may use a hacked viewer but that is only a miniscule percentage of users and usually only those who feel “above & beyond all entitlements”. Your propagandist attitude is offensive.

  12. frankleput@yahoo.com' youalreadyknow says:

    I want to jump in here, after reading some comments.
    First off Opensimulator does not have its own viewer ..your at the mercy of others !
    Secondly out of the box Opensimulator has extremely high vulnerability issues.
    Thirdly I see core developers have their own grids commercial and otherwise which have code that isn not in the release …BIG BAD CONFLICT OF INTEREST..should raise some eyebrows…if it doesn’t you might should just sit n be happy with what ya get.
    Fourthy I read down there where some guy said he was offended by anothers statement or propagandist something or another..lol..well speaking of propaganda, what type of forum and on what site are we posting? If your offended by bare facts..do not read what the public has to say or show.
    My Big NUMBER (5) stop building in the middle or at the end and start at the beginning..followed this thing for 4 yrs and all i see mostly in releases is shuffled files to make it look like someone made some accomplishment…if it was as serious a peice of development and software as some of you make it up to be ..it would be in completion after this many years.

  13. jim@gridmail.org' Jim Tarber says:

    Does any grid actually support the Export permission yet? It’s been a year and I tried the latest Singularity on Avination this week, and the Export checkbox is ALWAYS greyed out. I’ve filed a Singularity problem report: https://code.google.com/p/singularity-viewer/issues/detail?id=1543 I also tried Metropolis grid since Avination doesn’t actually run standard OpenSim code, and the checkbox was disabled there too. Firestorm seems to have code for this but I don’t even see the Export checkbox.

    Was this article documenting future plans or is this implemented somewhere? Anyone know?

    • I have been anxious to see a grid implement this, as well, but, so far, I don’t know of any grids that have.

      I think everyone is waiting for everyone else to go first, so they can see what problems come up, and get the bugs fixed, before they roll it out.

      It would be nice, I think, if, say, a testing grid (like, oh, OSgrid — hint, hint!) were to implement this feature, and we could all start experimenting with it. Or maybe a smaller grid somewhere.

      Kitely, meanwhile, has implemented its own version of the export permission, which doesn’t use the Avination-Singularity code, and creators can’t change the export setting in the viewer. (Only in the Kitely Market store interface.)

      • draco@spamcop.net' Rene says:

        Probably related to this beta work in InWorldz: http://i.gyazo.com/9e6556805166330d00d4f0e4aa1bcb23.png

      • jim@gridmail.org' Jim Tarber says:

        Yes, it seems that Kitely has not implemented the Export permission on the grid itself, only the market website.

        It would be great if the original developers of this provided a reference implementation running somewhere, and agreed, the OpenSim test grid (OSGrid) seems like the ideal place. Or Avination, since they announced it. But over a year later now, and still not available anywhere?

        InWorldz has now completed an initial test version and it’s available for viewer testing on the InWorldz beta grid. I’d like to make sure it’s compatible with the OpenSim version but the InWorldz code is very different from the OpenSim code, especially in the area of permissions, so I just don’t know without a reference implementation running somewhere.

        At any rate, it looks like InWorldz will be that first reference implementation.

        • ilan@kitely.com' Ilan Tochner says:

          Hi Jim, you’re statement about Kitely is not accurate. Kitely’s implementation of the Export permission works for any item originating from Kitely Market, not just for items bought directly from the Kitely Market website. Once an export-restricted item is delivered inworld it is tracked and prevented from being exported via OAR files or added to people’s Suitcase inventory folders so they can’t take it with them if they Hypergrid travel to other grids. In other words, our implementation is on the Kitely grid itself not only the market website.

          You’ll also note that Kitely’s implementation actually works with the various ways people expect to be able to export content from grids. Kitely supports both OAR backlups and Hypergrid travel. Adding the setting to the viewer is the easy part, enforcing it in all the scenarios is the time consuming project. Has Inworldz started supporting Hypergrid and unsupervised OAR exports?

          • Tranquillity (InWorldz) says:

            The full export implementation is simply to allow content creators to better specify exactly how they’d like their items to be made available (or not). It is a server side and client side follow through of the export bit and work started by core opensim.

            Our permissions system has been completely redone and Jim tarber was the lead on that. We’re aware of the complications that were present in enforcing and tracking permissions, which is why the risk was taken long ago to make that code easier to work with and extend.

            The primary usage will be to apply the export permission checks all scenarios where exporting happens such as OXP backup, and collada export where our residents have expressed concern with the full “perm equals exportable” defaults for opensim grids. This way we can better enforce content licenses without asking TPVs to make exceptions for us. Later on it will be used to provide other services.

            Jim is asking these questions because we’d like to try to keep the client side facing portion of the work compatible with the rest of opensim.

          • ilan@kitely.com' Ilan Tochner says:

            Thank you for the explanation David. Once this is done will you be enabling Hypergrid access?

          • jim@gridmail.org' Jim Tarber says:

            There are no plans to implement support for Hypergrid at this time as InWorldz, although we remain open to the possibility of cross-grid connectivity in the future.

            First, there’s no specification documentation for Hypergrid as far as I know, so it’s very difficult to implement something compatible. We haven’t ruled it out, do have a good technical solution in mind, but it really doesn’t fit well with the priorities of most InWorldz residents, and any support for content leaving the grid would have to be discussed at length with the residents before any technical proposals could be brought forward. There is very little demand for this, and many businesses see Hypergrid connectivity as a negative.

          • jim@gridmail.org' Jim Tarber says:

            Ilan, I’m referring to the export features of the *viewer*, when right-clicking on an object in the viewer and selecting the More -> More -> Save As menu : Backup (.OXP export of an object), and also export of objects as mesh (to a .DAE Collada file), available in many viewers including Firestorm and the InWorldz viewer. The InWorldz viewer also offers export as Wavefront (.OBJ) format.

            These viewer features are incredibly powerful and useful and offer selective export of rezzed objects, and .OXP export includes Contents like scripts, textures, shapes, animations, etc.

            The viewers that support the Export permission also allow the user to toggle the current Export permission option the same way they would toggle any other permission option.

            The primary usage of the export permission in InWorldz, and the usage illustrated in the screenshots in the article above, is to allow viewer-based setting of this permission, and something the article doesn’t mention at all, selective object export via the viewer. Try the .OXP export feature; it’s incredibly powerful and useful. This is the operation that InWorldz users want to ensure it respects the creator/export permission designation. Otherwise anyone can export content that the creator may not have wanted (or expected) to ever leave the grid.

            Full support for viewer and server support for Export setting and verification is now in a test build of the viewer I’ve been using and implemented in the grid software on the InWorldz beta grid, possibly coming to the main grid in the next update if testing goes well.

          • ilan@kitely.com' Ilan Tochner says:

            Do you provide any way for people to export entire regions? Something like OpenSim Archive (OAR) files provide?

          • jim@gridmail.org' Jim Tarber says:

            InWorldz provides very selective OAR exports via Support Ticket requests. It is not something a user can do in an automated way, for protection of the content restrictions, but InWorldz Support can in some cases provide an OAR for a region owner. Also since IARs were mentioned, there is a similar case of self-serve user inventory backups, which are complete but cannot be transferred to other grids: http://inworldz.com/forums/viewtopic.php?f=75&t=14812

          • ilan@kitely.com' Ilan Tochner says:

            Why not do what Kitely does and allow region owners to export OAR themselves whenever they wish but automatically filer out anything that isn’t created by that region owner or for which the region owner has export permission? The code for doing that was contributed by Kitely to OpenSim a long time ago. It’s quite simple to implement and should be viable now that you have an export permission in place.

          • jim@gridmail.org' Jim Tarber says:

            Export permission is the first step towards intelligent OAR export. Limiting it to creator-only is the most conservative way to content-protect OAR exports, but can be at the cost of much content in a region. Regions are often the result of many contributors, including creations on other (alt) accounts, and exportable freebies or cross-grid licensed creator content (exportable). Region-wide export that excludes anything other than only one user’s creations would in most cases leave the user with a partial OAR file. The Export permission allows much more inclusive export. I foresee on-demand OAR exports by users that includes not only creator-owned content but also content with Export permission, and possibly content owned by “registered alts”. This is important, e.g. for commercial regions where a store owner may operate the store under a different account than his or her main avatar account, or a land baron may have an estate account as well as a personal account.

            The code for this would be simple enough that we would not try to force the OpenSim code into the heavily-modified InWorldz code, since it’s really just a couple of conditionals in the region servers anyway. Most of the work would be in hooking this up to the website for OAR file download, which cannot leverage anything from the OpenSim code.

            But since Kitely is already running OpenSim code, why not enable the ability for viewer users to set the Export permission status from the viewer, as seen in the first two images in this article? Without doing so, I believe many common viewers default to allow the user to export anything they have full rights, regardless of the fact that the creator did NOT enable the Export permission.

          • ilan@kitely.com' Ilan Tochner says:

            There are several reasons, one is that there are two opposing camps with regards to what the default export permission needs to be. The second is that Kitely has allowed OAR exports for several years now so people expect to be able to continue exporting the items they are currently allowed to export. Requiring all those items to now have the Export permission will break that. What we have been using this far for items not originating from Kitely Market is this: http://www.kitely.com/virtual-world-news/2011/08/28/copy-world-respects-permissions/

          • jim@gridmail.org' Jim Tarber says:

            Ah I see. I guess I am in the other camp where protection of creator content comes first, and the change to respect the value of the Export permission would really be considered a significant *fix* to content protection. I can see where that might be impractical though on a grid where creators cannot set the Export permission option at all (in the viewer). But from my perspective, the grid must respect whatever license the creator deems in effect, and therefore adding support for Export puts that choice in the hands of the creator, and changes a grid significantly.

            It is indeed a tough call on what the defaults for existing content should be, but permissions are by definition a set of restrictions and a bit of a mess if not enforced because you can’t shut the barn door once the beasts have escaped. Once a product has been allowed to be exported, it’s too late to come back and restrict it, so I am firmly in the camp that says the default assumption must be to protect the content first, then ask the questions or make it optional for the creator to explicitly unprotect it.

            The article you linked to seems to imply it makes export decisions based on something other than the Export permission, and copy decisions based on something other than owner copy:

            “If they don’t own the object then the object must have the “Everyone Copy” permission in order for it to be copied into the new world.”
            It’s using the Everyone Copy permission rather than the Owner Copy permission? So even objects an owner can copy will not be copied to a new world?

            “If they own the object then it must have the “Owner Copy” permission in order for it to be copied. If the world is being Exported then the object must also have the “Owner Transfer” permission, because exported worlds can be given to other people.”

            I’m a bit confused by the references to Copy/Transfer rather than “full rights” or Copy/Mod/Transfer; you’ve mentioned it once or twice here and again in the article you just linked me to: are you saying No-Modify items can also be exported too? They don’t even need to be full rights permission to export?

            Yes, I think we’re in two different camps here on permissions. But I respect that the combination of circumstances at Kitely may produce different trade-offs than the ones faced at InWorldz. The plan at InWorldz is to only allow export of content with the Export permission enabled, protecting content by default, and that would also prevent export of no-mod items since you cannot even enable Export without enabling full rights. It also includes supporting the setting of the Export permission on the normal viewer object Edit form.

          • ilan@kitely.com' Ilan Tochner says:

            The inworld export content protections in Kitely predate the Export permission so it used a convention where only items for which you were either the creator or had both Copy and Transfer permissions would be exportable by you. Items do not have to be full perm to be exportable via this system.

            Kitely Market added the ability to explicitly state the Export permission thus enabling the content creator to allow selling items without Copy and/or Transfer that are still exportable or, conversely, selling items that did have both Copy and Transfer but prevent them from being exportable.

            The main difference in approaches is on who do you require to spend effort to change item exportability. On people who sell items to other people or on people who just want to create items they can take with them when they travel the hypergrid. There are a lot more people who travel the hypergrid than there are content creators who sell content. The people who don’t try to monetize their content want to be able to easily export it to other grids. Even the people who sell content in Kitely often sell items with export permission as they want to be able to serve customers from the entire Hypergrid not just Kitely users.

          • jim@gridmail.org' Jim Tarber says:

            Hmm. That last sentence almost sounds like you haven’t implemented the OpenSim concept of an Export permission then, but rather something else that called Export permission. It seems you can already export grid content that has no-Mod items in the Contents (which means it is very different than what is discussed in the article above). But does your Export permission also allow you to export other permissions combinations to other grids (such as no-copy/trans or copy/no-trans)? You’re referring to creators *selling* content and serving customers on other grids, and it would be strange (to me at least) for all of that to by Copy/Trans and exportable if it is *sold* content. Unless perhaps you’re referring to creator content like textures that is sold with a multi-grid license anyway?

            If so, then I think your comment on just different priorities between grids is accurate. At InWorldz it is very creator-friendly and creator-centric at times and the ones we hear from are very focused on being able to sell content with permissions that will NOT have it end up on other grids. So in that sense, it makes sense to have a different default than the one that best serves your grid-traveling crowd. Sounds like two cases of listening to a userbase that just happen to produce different results for different crowds…

          • ilan@kitely.com' Ilan Tochner says:

            Our system most definitely does not use the OpenSim concept of the Export permission. It is a much more advanced system that enables us to track items as they propagate within the Kitely grid and react to various events that may require changing their status. For example, an item for which payment has been reversed automatically becomes non exportable (and in the future we may automatically freeze it and all the copies that were made of it so they don’t show inworld and in people’s inventories while we investigate). There are many other scenarios where Kitely Market’s content protection system can come into play, exportability is just one aspect of this system.

            As for your question, yes, merchants can set the Export perm in Kitely Market on items with any combination of Copy/Transfer/Modify, as long as the system determines the merchant has the right to make the (what may be a multi-creator item) exportable.

            For clarification the handling of exportability of items originating from Kitely Market and ones that have not originated from Kitely Market is handled by related yet different systems which employ different logic. Items sold via our marketplace are always explicitely export or no-export while items not originating from our marketplace are only implicitly export or no-export
            (as determined by the Copy/Transfer perm values of the items).

          • jim@gridmail.org' Jim Tarber says:

            Thanks for the clarification, I didn’t realize there was a Kitely Market that wasn’t web-based. Though it does still sound like there’s no grid support for actually setting the Export permission in the viewer software, which is the feature showcased in the article above.

            Export is not really tied to OAR backups or HyperGrid travel. It is just useful in those cases as well, and both of those are cases where Export support would need server-side checks. The other case, and the one pictured above, is for creators to be able to designate their on-grid creations as exportable in the viewer. The default for this should be off, so that creations are protected by default, and an explicit permission is given for export. These viewer-based export functions are very important as well, perhaps the most important; certainly at InWorldz it is the viewer support that is critical. We have received many requests from content creator for more control
            over their content, specifically full-perm items that they wish to have
            restricted to the grid. There are many in-world sales and for those to be excluded from Export support, for us, would be unthinkable. Likewise if in-world full-permissions content was exportable by default. Content creators have uploaded products that are not intended to leave the grid, and introducing support for the Export permission requires that we respect that by default. The idea is that it should be possible to set or clear this option on all full-perm content, and for it to be used for all methods of content leaving the grid.

          • ilan@kitely.com' Ilan Tochner says:

            Hi Jim,

            Kitely Market is a web-based online store but it’s tightly integrated with our grid when it comes to export controls. Exportability is controlled via the Kitely Market interface not via the viewer.

            I’m still not clear what your export controls actually prevent (or allow). If Inworldz users can’t export their content via OAR/IAR files or the Hypergrid then how exactly do they export exportable content from your grid? Is this just a theoretical indication of what may or may not be removed from the grid or do you provide them with a way to actually get exportable content from your grid into other grids?