Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005892opensim[GRID] Asset Servicepublic2012-02-17 06:012015-01-11 11:41
ReporterWhiteStar 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformAllOSAllOS VersionAll
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0005892: Addition of Export Asset Flag
DescriptionThis was discussed loosely in November 2010 but no feature suggestion was posted to OpenSim Mantis (did however get one in Simian).

Idea Origination:
    In November of 2010 when Aurora-Sim was going public open-source, there was some discussions about adding an additional asset flag within the simulator software itself. These discussions included folks @ SimianGrid developers, Aurora-Sim dev's, a couple of OpenSim Dev's and some viewer developers from Imprudence. It was felt at that time, that from a viewer stand point this could be accomplished without a major effort. The required changes were identified by Armin Weatherhax within the viewer source for object_flags & llpanelpermissions as reference for these changes, in addition to the obvious UI panels that would have to be adjusted...

The Problem:
    At present, neither the viewers available nor OpenSim have a method that can be used to restrict assets for Exportation. The standard Copy, Modify, Transfer restrictions are the only ones available to users & content creators. As everyone is aware, OpenSim has the ability to create backups of personal inventory by using IAR or backing up an entire region to OAR will properly backup all material / content as is. Additionally, with the growing use of Hypergrid, many content creators are hesitant with putting new products into OpenSim as there is a potential for this content to be pulled out and reused in other venues like SecondLife(tm) or other grids. This lack of capability/functionality has also kept many excellent content creator's from venturing out into the Greater Metaverse as their concerns for the security of their created content is quite reasonable & valid. The end result has been a dampening of the desire to create extensive content, including scripted systems, device and builds, effectively hampering growth & adoption of OpenSim across a broader audience. There are several closed grids in operation with currencies / economies and they remain closed to Hypergrid partly over the content security issue which is ever prevalent.

The Solution:
    The addition of an extra asset flag Server & Viewer side so that creators would have the option to allow “export” a piece of content or not. Effectively, this could provide an in-viewer permissions option as Copy, Mod, Transfer, Export. The use of the export permission flag would, if checked (allowed) allow an individual to export content via XML, IAR or OAR as is the case today. If the export permission flag is set to disallow, then the material could be prevented from XML, IAR, OAR and HG (Hypergrid), effectively keeping that content within the “origin grid” that it is located in. Hypergrid content transfer is addressed here because by virtue of using HG, the content is effectively being moved from one physical data server to another and therefore is considered as “exported from origin”.

I personally feel that such a measure would not only enhance OpenSim & the Metaverse at large, it's an appropriate response to the concerns of creators and the security of the content they are making. I also realize, that in "some camps of thought" this idea would be rejected out of hand as this is divergent from the LL/SL compatibility mantra but I reitterate that SecondLife(tm) is a "baseline" from which to look at, buiild upon and extend beyond (as is the case with osFunctions, NPC, LightShare/WindLight ad infinitum).
TagsNo tags attached.
Git Revision or version numberAll
Run ModeStandalone (1 Region)
Physics EngineODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
ViewerAll
Attached Files

- Relationships

-  Notes
(0020884)
Bo Iwu (reporter)
2012-02-17 06:28

Hello,
i fear there can be just 2 results of this.
1) people will use old releases in order to export if backward compatibility preserved
2) there will be enforced upgrade and many users will leave open worlds because of content loss during testing of the feature.
And at the end of the day people will create a fork which will allow the exports.

The only real protection is LL alike "one owns all" style. With people having access to source, and DB there is no way to really protect content. Anything else just bothers fair users and is no problem for a thief...
(0020885)
smxy (reporter)
2012-02-17 06:36

All this would do is keep honest users honest. Those who want to copy things will still use modified viewers to do so. You simply cannot stop people from copying things - if their viewer can see it, it can be copied.
(0020886)
Marcus Llewellyn (reporter)
2012-02-17 07:01

I remember when this idea popped up. I think it was suggested with the full knowledge that the entire permission system requires a client that respects them. Indeed, it takes very little effort to find a client that ignores permissions altogether.

The main impetus behind this, as I recall it, was a good intentioned recognition that far too many otherwise honest users are confused as to what full perms means, mistakenly believing that they have permission to export items to other grids. An Export Flag gives content creators a clear and simple way to express whether or not they have decided to grant the right to take their intellectual property to another grid, without resorting to legalese in a notecard that users may never read.

This may be a worthy flag for grids to store, but exports have a number of issues that need to be addressed first. Right now content imported via a client does not preserve creator info, creation dates, permissions, etc.

A robust import/export standard that makes an earnest attempt to respect copyrights would be pretty valuable to both content creators and users, but I think we can all agree that LL will only worry about this sort of thing when pigs fly. An export flag would never be implemented there. TPVs and OpenSim would need to get together and hammer all of this out, and I'm not sure I would want to be in their shoes when they're not able to please everyone with any practical solution they could implement. But when and if this happens, that's when discussion of an export flag would make sense, as part of a larger picture.
(0020887)
WhiteStar (reporter)
2012-02-17 07:23

@Bo
- Backward compat between opensim versions would be something to deal with but could be figured out.
- If someone forks and disables it, then it's up to them... There will always be those that want to take whatever but do we want to allow / support that ? I think we know the answer.

@smxy, the viewer can see textures, parameters etc... if region server is not sending that data to viewer, they can't get at it. what is visible can be taken using different methods but that which is not visible/available cannot be taken.

@Marcus
I agree 100% that LL wouldn't consider an Export flag (they have dominion there) but it does not preclude OpenSim from being smarter about it. OS is not SL and it's growing fast.

Simply: If I tag something as non-export then just like No Mod, No Trans. The end user (viewer) would not be able to see the content of a script or notecard or get params off a build. This could be handled server side and thereby stop a hack viewer from opening something that the server does not present / send the data for. Similar in fashion to how SL does Script Security, if no mod, you cannot see contents of script, as that data is not sent.
(0020892)
justincc (administrator)
2012-02-17 17:38

I think that there is value in an export from installation flag or similar. Sure it can be circumvented, but these things can still act as valuable social signals.

It would be a lot of effort to implement and would certainly need agreement and discussions by third party viewer coders, if nothing else.

Just fyi, WhiteStar, we now restrict the mantis to bug discussion (as per [1]). Instead, we prefer to have this discussed on the mailing list (where more people are going to see it anyway). Thanks!

[1] http://opensimulator.org/wiki/Bugs#When_not_to_file_a_bug_report [^]
(0021075)
WhiteStar (reporter)
2012-03-10 11:17

After looking through the mail group which I joined for a while, I see the 3 years of on/off chatter about something along these lines... and while you suggest going to the mail-list which is all fine for discussion purposes the "feature" option should then be removed from Mantis, if you don't want features requested / mentioned in here. I did quit the mail list because not only is the daily digest delivered 12 times a day and stuffing my email the invalid berlios.de cert is always making a heap of noise about it.

As for the issue.... after having spoken to creators in SL like Cel Edman and others who are also putting stuff out at Avination & In-Worldz it's not only the fact that these grids have economy, they have more asset security. Cels' in-world sculpty builder tools & in-world mesh builder tools will never see OpenSim ... a great loss to all in OpenSim environments.

Feel free to close this if you wish or whatever you want to do with it. It's unfortunate if this functionailty is not considered for implementation.
(0024957)
aiaustin (developer)
2014-01-09 03:04
edited on: 2014-01-09 03:11

Can I note that since the export flag was introduced there seem to be constant problems with this flag being shown as greyed out in viewers like Firestorm even for simple objects created by an avatar who then cannot set the export flag. Using 0.8.0 dev master latest releases right up to r/24169.

I cannot work out how and when the export flag can be set by an avatar. It would be good if someone who knows what is MEANT to happen can check if its working correctly.

I have found restrictions on moving my items between grids where I wanted permissions to be totally open, which ought in an open source world to be the default... allowing people to restrict exports explicitly where they wish.

(0025466)
aiaustin (developer)
2014-03-18 13:43
edited on: 2014-03-18 13:45

Reminder that export permission issues persist. This could use a thorough test with modern viewers to ensure that things work as they should, and also across HG. I find sometimes that objects cannot have their export flag set on even when I created the object. The option to tick it is greyed out presumably as a result of the object being created on the "wrong" flavour of viewer.

(0025473)
Fly-Man- (developer)
2014-03-19 03:24

I think it might be time to ask Kitely for an advice as it seems they have implemented this already in their "edition" of Opensim.

Oren, can you shed some light upon this ?
(0025474)
Fly-Man- (developer)
2014-03-19 03:25

Reminder sent to: orenh

Can you shed some light upon this ?
(0025475)
orenh (administrator)
2014-03-19 03:39

Kitely's export permissions are implemented in a different way which relies on our custom infrastructure, so it isn't relevant to standard OpenSim.
(0025476)
aiaustin (developer)
2014-03-19 03:54

I think the export permission flag handling was added in some of Melanie's commits?
(0027206)
aiaustin (developer)
2015-01-11 01:49

Even items I create myself with my own textures and scripts I find have some elements where the export box is UNTICKED and greyed out. I often cannot simply move my own items between avatars or between my grids and not find that some embedded elements are incorrectly set.

If the defaults are all changed so by DEFAULT export is not enforced and the export tick is on for everything created, including internally added contents, embedded scripts, textures and assets, etc. This would be more in the spirit of open source community developed software, but still allow for commercial uses and content protection where that was explicitly intended.

Then any grid wanting to impose restrictions and provide that feature could turn it on and any content creator/vendor could untick the export box using a supported views if that was their intention.
(0027207)
aiaustin (developer)
2015-01-11 01:54

OpenSim.ini.example does not contain the [SimulatorFeatures] that Melanie mentioned was needed in an OpenSim users mailing list post...

[SimulatorFeatures]
    ;; Viewer Export Permission Support
    ; ExportSupported=true

But should it be true ort false to not use Export permission and use just the standard permissions system for no copy, no mod, no transfer.

OpenSimDefaults.ini apparently contains NO [SimulatorFeatures], which I assume it should for all such settings, to act as a guide to what true and false mean, or to see what the default is.
(0027208)
melanie (administrator)
2015-01-11 11:41

Export should be like any other permission, where the default value can be set by the grid operator.

There are both people who would scream if it was on on every new item, saying they are commercial creator and resent having to think about and turn off that flag on everything they create/upload and people who make only Free (as in Speech) stuff and would gripe about having to turn it on for everything they make.

Regular permissions are defaulted to what the grid owner sets, but users can set different defaults in their viewer for new items. That mechanism can probably easily be extended to cover export flags as well.

If you create items using textures you have not made, your items will be unexportable. To check for this, your texture (listing you as creator and with export turned on) must be in your inventory, in a folder. It can not be in a texture organizer or similar.

If anyone finds irregularities with the export flag they should treat it as a bug an file a Mantis on it, or comment on an existing related one.

- Issue History
Date Modified Username Field Change
2012-02-17 06:01 WhiteStar New Issue
2012-02-17 06:28 Bo Iwu Note Added: 0020884
2012-02-17 06:36 smxy Note Added: 0020885
2012-02-17 07:01 Marcus Llewellyn Note Added: 0020886
2012-02-17 07:23 WhiteStar Note Added: 0020887
2012-02-17 17:38 justincc Note Added: 0020892
2012-03-10 11:17 WhiteStar Note Added: 0021075
2014-01-09 03:04 aiaustin Note Added: 0024957
2014-01-09 03:11 aiaustin Note Edited: 0024957 View Revisions
2014-03-18 13:43 aiaustin Note Added: 0025466
2014-03-18 13:45 aiaustin Note Edited: 0025466 View Revisions
2014-03-18 13:45 aiaustin Note Edited: 0025466 View Revisions
2014-03-19 03:24 Fly-Man- Note Added: 0025473
2014-03-19 03:25 Fly-Man- Note Added: 0025474
2014-03-19 03:39 orenh Note Added: 0025475
2014-03-19 03:54 aiaustin Note Added: 0025476
2015-01-11 01:49 aiaustin Note Added: 0027206
2015-01-11 01:54 aiaustin Note Added: 0027207
2015-01-11 11:41 melanie Note Added: 0027208


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker