Come DMCA notice

The Come DMCA notice covers the takedown process and the contact route.

What a valid takedown notice must include

A valid DMCA takedown notice is a written communication that identifies the copyrighted work, the URL on appcome7.com where the work is alleged to appear, the contact details of the requester, and a statement of good-faith belief. Verified: the support desk reviews each notice against these four fields before any action is taken on the URL. Unverified: a notice that omits any of the four fields is returned with a pointer to this page rather than acted on, so the requester can resubmit a complete notice.

The four fields a notice must include:

1. Identification of the work. The title or a description of the copyrighted work that the requester claims has been used without authorisation. A link to the original work on the requester's own surface is helpful but is not a substitute for the title or description.
2. URL on appcome7.com. The exact URL where the work is alleged to appear. The URL is read against the same snapshot the support desk reads on every other ticket.
3. Contact details. The requester's name, address, telephone number and email address. The contact details are kept on the ticket record and are not published.
4. Good-faith statement. A statement that the requester has a good-faith belief that the use of the work in the manner complained of is not authorised by the copyright owner, its agent or the law. The statement is read against the same fields on the takedown form.

What happens after a notice is received

After a complete notice is received, the support desk reviews the URL against the snapshot. Verified: the review is non-destructive; the URL is not taken down before the review completes. Unverified: a notice that asks for an immediate takedown without a review is returned with a pointer to this page rather than acted on, so the support desk can complete the review against the snapshot.

How the review is conducted:

1. Acknowledge the notice. The support desk acknowledges the notice within the published response window (24 hours on weekdays). The acknowledgement includes the ticket ID and the snapshot timestamp on the URL.
2. Review the URL. The support desk reviews the URL against the snapshot. The review is read against the four fields on the notice; a field that disagrees is returned with a pointer to the relevant field on the notice form.
3. Action on the URL. If the review confirms the notice, the URL is taken down and the requester is notified on the same ticket ID. If the review does not confirm the notice, the requester is notified on the same ticket ID with the field that disagrees.
4. Counter-notice. If the URL is taken down and the affected user believes the takedown was in error, the affected user can submit a counter-notice. The counter-notice is read against the same four fields as the original notice.

Counter-notices and the response window

A counter-notice is a written communication from the affected user that responds to a takedown notice. Verified: a counter-notice must include the affected user's name, address, telephone number and email address, a statement of consent to the jurisdiction of a federal court in the affected user's district, and a statement that the affected user has a good-faith belief that the material was removed or disabled as a result of a mistake or misidentification. Unverified: a counter-notice that omits any of the four fields is returned with a pointer to this page rather than acted on.

How a counter-notice is read against the snapshot:

• Affected user contact details. The counter-notice is read against the same contact-detail fields as the original notice. The contact details are kept on the ticket record and are not published.
• Jurisdiction consent. The counter-notice is read against the same jurisdiction rule as the original notice. A counter-notice that omits the jurisdiction consent is returned with a pointer to the relevant field on the counter-notice form.
• Good-faith statement. The counter-notice is read against the same good-faith statement as the original notice. A counter-notice that omits the good-faith statement is returned with a pointer to the relevant field on the counter-notice form.
• Response window. The support desk replies to a complete counter-notice within the published response window (24 hours on weekdays). The reply includes the ticket ID and the snapshot timestamp on the URL.

Designated agent and how the support desk handles the notice

Come designates the support desk at /contact/ as the agent for DMCA notices. Verified: each notice is read against the four fields on the notice form and against the same snapshot the support desk reads on every other ticket. Unverified: a notice that is not addressed to the support desk is returned with a pointer to this page rather than acted on.

How the support desk handles a notice:

1. Acknowledge. The support desk acknowledges the notice within the published response window (24 hours on weekdays). The acknowledgement includes the ticket ID and the snapshot timestamp on the URL.
2. Read the four fields. The support desk reads the four fields on the notice against the snapshot. A field that disagrees is returned with a pointer to the relevant field on the notice form.
3. Review the URL. The support desk reviews the URL against the snapshot. The review is non-destructive; the URL is not taken down before the review completes.
4. Action or return. If the review confirms the notice, the URL is taken down and the requester is notified on the same ticket ID. If the review does not confirm the notice, the requester is notified on the same ticket ID with the field that disagrees.

Repeat infringers and how the policy is read

Come's policy on repeat infringers is read against the same snapshot the support desk reads on every other ticket. Verified: a URL that has been the subject of a confirmed takedown is removed from the directory and the snapshot records the removal timestamp. Unverified: a URL that has been the subject of a returned notice (a notice that omitted one of the four fields) is not recorded as a confirmed takedown; the support desk treats a returned notice as a new ticket on the next review pass.

How the repeat-infringer policy is read:

• First confirmed takedown. The URL is removed from the directory and the snapshot records the removal timestamp. The requester is notified on the same ticket ID.
• Second confirmed takedown. The URL is removed and the publisher is notified. The publisher is given the opportunity to dispute the takedown on the same ticket ID.
• Third confirmed takedown. The URL is removed and the publisher is notified that further takedowns will be reviewed under the repeat-infringer policy. The publisher is given the opportunity to dispute the takedown on the same ticket ID.
• Fourth and subsequent. Further takedowns are reviewed under the repeat-infringer policy. The publisher is notified on the same ticket ID.