
| Key: |
SVC-1446
|
| Type: |
New Feature
|
| Status: |
Resolved
|
| Resolution: |
Under Advisement
|
| Priority: |
Critical
|
| Assignee: |
Unassigned
|
| Reporter: |
beam ray
|
| Votes: |
154
|
| Watchers: |
15
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Relates
|
|
This issue Relates to:
|
|
|
SVC-676 Stopping texture theft and stop spreading of stolen items
|
|
|
|
|
|
This issue is related to by:
|
|
|
SVC-1869 Linden Lab should periodically publish statistics regarding DMCA procedures to increase transparency
|
|
|
|
|
|
MISC-1278 06-14-08 - Clarification sought on current application of DMCA by LL and how content reported is being handled now
|
|
|
|
|
|
|
| Last Triaged: |
21/Oct/09 11:25 AM
|
Linden Lab currently responds to a DMCA notification by removing specifically indicated vendors from the system. Content creators who want to claim infringement are given the impression that this is the only thing Linden Lab needs to do, or can do. It is my understanding that this is not strictly correct and that Linden Lab is in fact obliged as per the DMCA to block all infringing content from the servers.
It is my understanding that objects in Second Life have a unique identifier, the UUID. It is also my understanding that this identifier is unchanged when an object is copied, for instance into the inventory of another user who received or bought the item. If LL received a DMCA notification saying that an object with a certain UUID is infringing, LL could respond by removing or blocking all instances of this object from their servers. If such a technology does not exist today, it could at least be developed. In addition, it is important that people who have such items in their inventory should receive a notification that this object is subject to a DMCA notification, so that this is not confused with bugs or asset loss.
Unfortunately it is not possible for a content creator to determine the UUID of infringing items, as this information is not given for infringing items they did not create themselves. A content creator can however uniquely identify the infringing item to LL, either in their own inventory (they can buy the item), or by pointing to the item in a specific vendor, much like is done now. LL can then retrieve the UUIDs of the infringing objects that make up the infringing item, and block them.
Doing this instead of just blocking vendors could have two positive effects:
- it would allow LL to better fulfill what I understand are the actual requirements of the DMCA.
- blocking all copies of an item will be a far more effective measure against infringers. It is more difficult to just set up a new store selling the same items again; at the very least a new texture must be uploaded first. In addition, the customers of infringing items will notice their items have been removed and/or blocked. This will be bad for the reputation of the infringer. Of course a persistent infringer can still make trouble, but it will be harder.
A positive negative side effect is that DMCA notifications for the purposes of harassment have a bigger impact as well - a content creator and his or her customers would all lose access to the item a DMCA notification is made about. The resolution would of course be a counter-notification by the content creator, resulting in an unblocking of the identified items.
Some development on the part of LL seems to be required. Because there is a requirement to unblock, the best way to implement this would be to allow blocking (and not removing) of items by LL. Finding all objects with a certain UUID in a database may also be an expensive operation. It is also important users get some form of notification on why their items are suddenly blocked, so that this is not confused with data loss bugs or server problems - this requires client and user interface enhancements. Tools that help LL identify the UUIDs of infringing items and easily block them might also need to be developed. It is unfortunate that so much development would be required to provide this service, but it would seem to be in LL's interest to develop it.
It may be that blocking textures is a lot easier to implement than it is to block the reuse of other objects. Even if a general case cannot be developed quickly, it may still be worth it to tackle the texture case independently, as this may already block a large class of problem cases.
It is possible that my assumptions about UUID behavior are incorrect. In this case a system to track copies of objects would need to be developed as well.
-----------------------------------------------------------------------------
DMCA Section 512:
"(1) In general.—A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the storage at the direction of a user of material that resides on a system or network controlled or operated by or for the service provider, if the service provider—
"(A) does not have actual knowledge that the material or an activity using the material on the system or network is infringing;
"(ii) in the absence of such actual knowledge, is not aware of facts or circumstances from which infringing activity is apparent; or
"(iii) upon obtaining such knowledge or awareness, acts expeditiously to remove, or disable access to, the material;
"(B) does not receive a financial benefit directly attributable to the infringing activity, in a case in which the service provider has the right and ability to control such activity; and
"(C) upon notification of claimed infringement as described in paragraph (3), responds expeditiously to remove, or disable access to, the material that is claimed to be infringing or to be the subject of infringing activity.
-----------------------------------------------------------------------------
Linden Lab does not appear to comply with 512(1)(A), in that they allow copies of the infringing material to remain.
Note that this issue proposes a specific set of service enhancements to let LL handle DMCA notifications more effectively. It is not a general issue about copyright infringement or ways to combat these. Please discuss other ideas on separate issues.
|
|
Description
|
Linden Lab currently responds to a DMCA notification by removing specifically indicated vendors from the system. Content creators who want to claim infringement are given the impression that this is the only thing Linden Lab needs to do, or can do. It is my understanding that this is not strictly correct and that Linden Lab is in fact obliged as per the DMCA to block all infringing content from the servers.
It is my understanding that objects in Second Life have a unique identifier, the UUID. It is also my understanding that this identifier is unchanged when an object is copied, for instance into the inventory of another user who received or bought the item. If LL received a DMCA notification saying that an object with a certain UUID is infringing, LL could respond by removing or blocking all instances of this object from their servers. If such a technology does not exist today, it could at least be developed. In addition, it is important that people who have such items in their inventory should receive a notification that this object is subject to a DMCA notification, so that this is not confused with bugs or asset loss.
Unfortunately it is not possible for a content creator to determine the UUID of infringing items, as this information is not given for infringing items they did not create themselves. A content creator can however uniquely identify the infringing item to LL, either in their own inventory (they can buy the item), or by pointing to the item in a specific vendor, much like is done now. LL can then retrieve the UUIDs of the infringing objects that make up the infringing item, and block them.
Doing this instead of just blocking vendors could have two positive effects:
- it would allow LL to better fulfill what I understand are the actual requirements of the DMCA.
- blocking all copies of an item will be a far more effective measure against infringers. It is more difficult to just set up a new store selling the same items again; at the very least a new texture must be uploaded first. In addition, the customers of infringing items will notice their items have been removed and/or blocked. This will be bad for the reputation of the infringer. Of course a persistent infringer can still make trouble, but it will be harder.
A positive negative side effect is that DMCA notifications for the purposes of harassment have a bigger impact as well - a content creator and his or her customers would all lose access to the item a DMCA notification is made about. The resolution would of course be a counter-notification by the content creator, resulting in an unblocking of the identified items.
Some development on the part of LL seems to be required. Because there is a requirement to unblock, the best way to implement this would be to allow blocking (and not removing) of items by LL. Finding all objects with a certain UUID in a database may also be an expensive operation. It is also important users get some form of notification on why their items are suddenly blocked, so that this is not confused with data loss bugs or server problems - this requires client and user interface enhancements. Tools that help LL identify the UUIDs of infringing items and easily block them might also need to be developed. It is unfortunate that so much development would be required to provide this service, but it would seem to be in LL's interest to develop it.
It may be that blocking textures is a lot easier to implement than it is to block the reuse of other objects. Even if a general case cannot be developed quickly, it may still be worth it to tackle the texture case independently, as this may already block a large class of problem cases.
It is possible that my assumptions about UUID behavior are incorrect. In this case a system to track copies of objects would need to be developed as well.
-----------------------------------------------------------------------------
DMCA Section 512:
"(1) In general.—A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the storage at the direction of a user of material that resides on a system or network controlled or operated by or for the service provider, if the service provider—
"(A)  does not have actual knowledge that the material or an activity using the material on the system or network is infringing;
"(ii) in the absence of such actual knowledge, is not aware of facts or circumstances from which infringing activity is apparent; or
"(iii) upon obtaining such knowledge or awareness, acts expeditiously to remove, or disable access to, the material;
"(B) does not receive a financial benefit directly attributable to the infringing activity, in a case in which the service provider has the right and ability to control such activity; and
"(C) upon notification of claimed infringement as described in paragraph (3), responds expeditiously to remove, or disable access to, the material that is claimed to be infringing or to be the subject of infringing activity.
-----------------------------------------------------------------------------
Linden Lab does not appear to comply with 512(1)(A), in that they allow copies of the infringing material to remain.
Note that this issue proposes a specific set of service enhancements to let LL handle DMCA notifications more effectively. It is not a general issue about copyright infringement or ways to combat these. Please discuss other ideas on separate issues. |
Show » |
made changes - 06/Feb/08 12:57 PM
| Field |
Original Value |
New Value |
|
Link
|
|
This issue Relates to SVC-676
[ SVC-676
]
|
made changes - 18/Mar/08 01:07 PM
|
Link
|
|
This issue is related to by SVC-1869
[ SVC-1869
]
|
made changes - 31/Mar/08 07:02 AM
|
Description
|
Linden Lab currently responds to a DMCA notification by removing specifically indicated vendors from the system. Content creators who want to claim infringement are given the impression that this is the only thing Linden Lab needs to do, or can do. It is my understanding that this is not strictly correct and that Linden Lab is in fact obliged as per the DMCA to block *all* infringing content from the servers.
It is my understanding that objects in Second Life have a unique identifier, the UUID. It is also my understanding that this identifier is unchanged when an object is copied, for instance into the inventory of another user who received or bought the item. If LL received a DMCA notification saying that an object with a certain UUID is infringing, LL could respond by removing or blocking all instances of this object from their servers. If such a technology does not exist today, it could at least be developed. In addition, it is important that people who have such items in their inventory should receive a notification that this object is subject to a DMCA notification, so that this is not confused with bugs or asset loss.
Unfortunately it is not possible for a content creator to determine the UUID of infringing items, as this information is not given for infringing items they did not create themselves. A content creator can however uniquely identify the infringing item to LL, either in their own inventory (they can buy the item), or by pointing to the item in a specific vendor, much like is done now. LL can then retrieve the UUIDs of the infringing objects that make up the infringing item, and block them.
Doing this instead of just blocking vendors could have two positive effects:
* it would allow LL to better fulfill what I understand are the actual requirements of the DMCA.
* blocking all copies of an item will be a far more effective measure against infringers. It is more difficult to just set up a new store selling the same items again; at the very least a new texture must be uploaded first. In addition, the customers of infringing items will notice their items have been removed and/or blocked. This will be bad for the reputation of the infringer. Of course a persistent infringer can still make trouble, but it will be harder.
A positive negative side effect is that DMCA notifications for the purposes of harassment have a bigger impact as well - a content creator and his or her customers would all lose access to the item a DMCA notification is made about. The resolution would of course be a counter-notification by the content creator, resulting in an unblocking of the identified items.
Some development on the part of LL seems to be required. Because there is a requirement to unblock, the best way to implement this would be to allow blocking (and not removing) of items by LL. Finding all objects with a certain UUID in a database may also be an expensive operation. It is also important users get some form of notification on why their items are suddenly blocked, so that this is not confused with data loss bugs or server problems - this requires client and user interface enhancements. Tools that help LL identify the UUIDs of infringing items and easily block them might also need to be developed. It is unfortunate that so much development would be required to provide this service, but it would seem to be in LL's interest to develop it.
It may be that blocking textures is a lot easier to implement than it is to block the reuse of other objects. Even if a general case cannot be developed quickly, it may still be worth it to tackle the texture case independently, as this may already block a large class of problem cases.
It is possible that my assumptions about UUID behavior are incorrect. In this case a system to track copies of objects would need to be developed as well.
Note that this issue proposes a *specific* set of service enhancements to let LL handle DMCA notifications more effectively. It is not a general issue about copyright infringement or ways to combat these. Please discuss other ideas on separate issues.
|
Linden Lab currently responds to a DMCA notification by removing specifically indicated vendors from the system. Content creators who want to claim infringement are given the impression that this is the only thing Linden Lab needs to do, or can do. It is my understanding that this is not strictly correct and that Linden Lab is in fact obliged as per the DMCA to block *all* infringing content from the servers.
It is my understanding that objects in Second Life have a unique identifier, the UUID. It is also my understanding that this identifier is unchanged when an object is copied, for instance into the inventory of another user who received or bought the item. If LL received a DMCA notification saying that an object with a certain UUID is infringing, LL could respond by removing or blocking all instances of this object from their servers. If such a technology does not exist today, it could at least be developed. In addition, it is important that people who have such items in their inventory should receive a notification that this object is subject to a DMCA notification, so that this is not confused with bugs or asset loss.
Unfortunately it is not possible for a content creator to determine the UUID of infringing items, as this information is not given for infringing items they did not create themselves. A content creator can however uniquely identify the infringing item to LL, either in their own inventory (they can buy the item), or by pointing to the item in a specific vendor, much like is done now. LL can then retrieve the UUIDs of the infringing objects that make up the infringing item, and block them.
Doing this instead of just blocking vendors could have two positive effects:
* it would allow LL to better fulfill what I understand are the actual requirements of the DMCA.
* blocking all copies of an item will be a far more effective measure against infringers. It is more difficult to just set up a new store selling the same items again; at the very least a new texture must be uploaded first. In addition, the customers of infringing items will notice their items have been removed and/or blocked. This will be bad for the reputation of the infringer. Of course a persistent infringer can still make trouble, but it will be harder.
A positive negative side effect is that DMCA notifications for the purposes of harassment have a bigger impact as well - a content creator and his or her customers would all lose access to the item a DMCA notification is made about. The resolution would of course be a counter-notification by the content creator, resulting in an unblocking of the identified items.
Some development on the part of LL seems to be required. Because there is a requirement to unblock, the best way to implement this would be to allow blocking (and not removing) of items by LL. Finding all objects with a certain UUID in a database may also be an expensive operation. It is also important users get some form of notification on why their items are suddenly blocked, so that this is not confused with data loss bugs or server problems - this requires client and user interface enhancements. Tools that help LL identify the UUIDs of infringing items and easily block them might also need to be developed. It is unfortunate that so much development would be required to provide this service, but it would seem to be in LL's interest to develop it.
It may be that blocking textures is a lot easier to implement than it is to block the reuse of other objects. Even if a general case cannot be developed quickly, it may still be worth it to tackle the texture case independently, as this may already block a large class of problem cases.
It is possible that my assumptions about UUID behavior are incorrect. In this case a system to track copies of objects would need to be developed as well.
-----------------------------------------------------------------------------
DMCA Section 512:
"(1) In general.—A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the storage at the direction of a user of material that resides on a system or network controlled or operated by or for the service provider, if the service provider—
"(A)(i) does not have actual knowledge that the material or an activity using the material on the system or network is infringing;
"(ii) in the absence of such actual knowledge, is not aware of facts or circumstances from which infringing activity is apparent; or
"(iii) upon obtaining such knowledge or awareness, acts expeditiously to remove, or disable access to, the material;
"(B) does not receive a financial benefit directly attributable to the infringing activity, in a case in which the service provider has the right and ability to control such activity; and
"(C) upon notification of claimed infringement as described in paragraph (3), responds expeditiously to remove, or disable access to, the material that is claimed to be infringing or to be the subject of infringing activity.
-----------------------------------------------------------------------------
Linden Lab does not appear to comply with 512(1)(A), in that they allow copies of the infringing material to remain.
Note that this issue proposes a *specific* set of service enhancements to let LL handle DMCA notifications more effectively. It is not a general issue about copyright infringement or ways to combat these. Please discuss other ideas on separate issues.
|
made changes - 07/Jun/08 12:23 PM
|
Priority
|
Normal
[ 4
]
|
Critical
[ 2
]
|
made changes - 14/Jun/08 02:46 PM
|
Link
|
|
This issue is related to by MISC-1278
[ MISC-1278
]
|
made changes - 13/Nov/08 12:04 PM
|
Workflow
|
jira-2007-12-22a
[ 51828
]
|
jira-2008-11-14
[ 80665
]
|
made changes - 13/Nov/08 04:29 PM
|
Workflow
|
jira-2008-11-14
[ 80665
]
|
jira-2008-11-14a
[ 86724
]
|
made changes - 13/Nov/08 04:45 PM
|
Workflow
|
jira-2008-11-14
[ 86724
]
|
jira-2008-11-14a
[ 91842
]
|
made changes - 13/Nov/08 04:55 PM
|
Workflow
|
jira-2008-11-14
[ 91842
]
|
jira-2008-11-14a
[ 95348
]
|
made changes - 21/Oct/09 11:25 AM
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Last Triaged
|
|
21/Oct/09 11:25 AM
|
|
Resolution
|
|
Under Advisement
[ 8
]
|
|