[#SVC-701] Copyright/license/notes fields on assets, to allow proper attribution and provide license and configuration information.

2. Second Life Service - SVC

Copyright/license/notes fields on assets, to allow proper attribution and provide license and configuration information.

Created: 25/Sep/07 08:35 AM Updated: 12/Aug/08 04:35 PM

Component/s:

Permissions, Scripts, Simulation

Affects Version/s:

None

Fix Version/s:

None

Issue Links:

Relates

This issue Relates to:

SVC-1406 Non-volatile storage for meta-information

SVC-2626 Copyleft/share-alike permission for SL Items

SVC-2508 In-world script/viewer communications

MISC-1277 Request for policy clarification concerning cross-grid copying of assets

This issue is related to by:

VWR-2909 Users are misled into thinking texture permissions do anything.

SVC-1406 Non-volatile storage for meta-information

SVC-1115 General "attributes" for accounts

~~SVC-1581~~ Modify llGetPrimitiveParams behavior to fail if copyright conditions are not met

SVC-2621 Meta-Issue: New/modified permissions

Description

« Hide

This would kill a lot of birds with one stone.

Proposal: a pair of properties associated with assets. One would only be settable by the creator, the other by the creator or owner. The properties would be viewable by the client in-world or in inventory (in the properties dialog), and (if practical) by script as well. All assets would have these properties: textures, skins, scripts, notecards, gestures, objects... think of it as the 'mattress tag' or 'back of the picture'...

The content of the field would either be a moderate sized free-form text field, or a UUID referring to a notecard. In the latter case the user interface to set it would probably involve dragging the notecard to the object's properties dialog.

The creator information for an asset would be presented to the user when they accept the asset from another user. If the asset contains references to other assets containing creator information (eg, an object's inventory contents, or a notecard's contents, or a gesture's sounds and animations) that should be presented as well. The user interface should not be so obtrusive as to allow it to be used for griefing, but the recipient must be aware that they're receiving assets that may be subject to license terms they should know about.

The owner information for the asset would contain any information that the owner wants to add, including notes and (if the information is readable by a script) configuration information.

Typical creator information might be:

Or:

Typical owner information might be:

"listen 10; label 'Sit here'"

Possible LSL APIs.

Two new LSL constants: NOTICE_CREATOR and NOTICE_OWNER.

For a text field associated directly with an object:

string llGetNotice(integer type);

For a notecard:

key llGetNoticeUUID(integer type);

In this case actually reading the notice would be done using the dataserver.

PS: JIRA needs a 'Components' field value for 'Inventory'.

Description

This would kill a lot of birds with one stone. Proposal: a pair of properties associated with assets. One would only be settable by the creator, the other by the creator or owner. The properties would be viewable by the client in-world or in inventory (in the properties dialog), and (if practical) by script as well. All assets would have these properties: textures, skins, scripts, notecards, gestures, objects... think of it as the 'mattress tag' or 'back of the picture'... The content of the field would either be a moderate sized free-form text field, or a UUID referring to a notecard. In the latter case the user interface to set it would probably involve dragging the notecard to the object's properties dialog. The creator information for an asset would be presented to the user when they accept the asset from another user. If the asset contains references to other assets containing creator information (eg, an object's inventory contents, or a notecard's contents, or a gesture's sounds and animations) that should be presented as well. The user interface should not be so obtrusive as to allow it to be used for griefing, but the recipient must be aware that they're receiving assets that may be subject to license terms they should know about. The owner information for the asset would contain any information that the owner wants to add, including notes and (if the information is readable by a script) configuration information. Typical creator information might be: "Copyright (c) 2007 Agent Stonecutter, All Rights Reserved. This script is distributed under the modified BSD license." Or: "Copyright (c) 2005 Texture Insanity, see http://textureinsanity.example.com/ for more information." Typical owner information might be: "listen 10; label 'Sit here'" Possible LSL APIs. Two new LSL constants: NOTICE_CREATOR and NOTICE_OWNER. For a text field associated directly with an object: string llGetNotice(integer type); For a notecard: key llGetNoticeUUID(integer type); In this case actually reading the notice would be done using the dataserver. PS: JIRA needs a 'Components' field value for 'Inventory'.

Show »

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 26/Dec/07 02:59 PM

Linked from SVC-1115 because these attributes could be a part of a more general attribute mechanism if it was extended to include assets.

llGetNotice(NOTICE_CREATOR) -> llRequestAttribute(KEY_NONE,"creator/copyright");

With a "creator" attribute tree on prims that could only be modified by the creator.

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 31/Dec/07 02:58 PM

Also note, https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 01/Feb/08 08:52 AM

Linked to SVC-1406

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 19/Feb/08 04:43 PM

~~SVC-1581~~ is completely unrelated to this.

[ Permlink | « Hide ]

miss hera added a comment - 27/Feb/08 02:55 AM

Implementing this would be good, but if DMCAs continue to take as long as they do now and the misbehaving individual is not punished at all like they arent now, people will continue to steal.

Linden Labs needs to think about a better way to react on a DMCA, because they can add copyright notices, but if taking down an items takes months in which people can earn, and they receive no punishment then what's the use?

Remember that certain brazilian shop that earned a lot on stolen items? They still have are active and they haven't payed back any money their earned on the stolen items to the original creator.

Linden labs could in this case have easily suspended the acount, taken down that persons sims, until he payed back any money to the original creator but they did nothing.

It's just a matter of time untill they will release their next stolen item.

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 27/Feb/08 06:02 AM

How do you know they go unpunished?

Has anyone filed a DMCA against the Brazilian shop?

[ Permlink | « Hide ]

Cheta Torok added a comment - 10/Mar/08 06:16 AM

Before you can enforce DMCA, you have to have a copyright. Most serious content creators probably do, but there is no reasonable way to make sure the user knows what it is. Right now you have to read a notecard or a website to find out what the copyright statement says, and that assumes that the notecard or reference to the web site is still with the object.

I think the Mattress Tag statement is very accurate. We, as average residents, need a way to know what our rights are with every object we receive. I have deleted many(100's) of objects because I felt they were legally questionable. Unfortunately, some of them may have been legit, so I was the harmed due to the lack of any copyright. At the same time it is possible that I may have something that I am not supposed to have but it did not appear to be questionable, so a content creator may have been harmed.

This proposal would address a very real in world problem in a measured way. Policing is a second step, and unrelated to this one. However, it would be a lot easier to catch people violating copyrights if the copyrights were easily accessible.

[ Permlink | « Hide ]

destiny niles added a comment - 17/Jun/08 12:01 PM

I don't see how this is different than just having a regular script using current lsl in the object that spits the license out.

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 18/Jun/08 05:36 AM

destiny: how do you put an LSL script in a dress, shirt, or other non-prim-based asset? How do you run an LSL script on an object in your inventory?

[ Permlink | « Hide ]

Sophia Tantalus added a comment - 08/Aug/08 12:31 PM

Copyrights are legally different from licensing rights. The gap between the two and the way SL implements creator's IP rights is one of the great legal grey holes of SL. Are we legally buying an object under copyright laws (as may be assumed with a mod/copy/trans) or are we licensing the use of an object (no-trans would violate the Doctrine of First Sale, for ex.). End User Licensing Agreements were widely adopted with the rise of software to bridge the gaps in Copyright law (since loading a program requires creating a copy). They are contracts and as such require acceptance on the part of the covered party- i.e. you must agree to the EULA (by purchasing this item, by opening this item, etc).

There's no question SL needs to implement the granting and tracking of IP perms and having a notes field for Creative Commons statements, licensing text etc. is important. The issue is differentiating between the two types of purchasing in the first place.