This is Arash from Dropbox. We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service. By our TOS, we reserve the right to terminate the account of users in this case.
However, we chose to remove access to the file instead of terminating the account of the user.
We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that a DMCA takedown email would be auto-generated and sent. This was a tool built for our support team and I'd never personally used it. That said, we feel strongly that the code is a violation of our TOS and don't believe the removal of the content from our site is censorship.
I'd also like to clarify that nobody's accounts were threatened: in every case my phrasing was as follows: 'I hope you can understand our position and can agree to remove the Dropship code'.
Of course you're well within your rights to remove the content from Dropbox itself as it violates your TOS - I think most people are objecting not to that, but to you requesting that copies of the source be removed from third party sites like github.
The attempt to quash knowledge is the offensive part - not the enforcing of your TOS. At least that's my 2 cents.
I agree that the removal of the code from your site is not censorship, but I think that misses the point. Asking for the code to be removed from GitHub is very different than removing it from the Dropbox website.
Even so, my main issue is not whether it violates the terms of service or not -- let's just say using it does violate those terms -- the question is whether taking it down is the right thing to do, for Dropbox and its users. In this case, I don't think it is: the issue here is not the code itself (which does not appear to be malicious) but how that code accomplishes its purpose. That method is not something you can block with requests to take down source code.
Basically: this may violate the terms of service, but maybe the real issue here is that if those terms are blocking this, maybe those terms are wrong.
I find it hard to believe that you did not anticipate exactly this happening when designing (a) an online file backup service, (b) a "de"-duplication algorithm. That said, you should have planned for exactly this a long time ago, whether by the means DropShip used, or any of several other potential file sharing hacks. I think a lot of us here are disappointed with how your actions reflect that planning, or lack thereof.
I agree. I actually proposed this idea a while back but never went through with the implementation. I hope Dropbox turns a blind eye to this because I think its fair use of Dropbox. Instead of someone sending you the file and then you adding it to Dropbox manually, you can just send the hash for the file and receive without P2P. This is where the world of online storage might head anyways.
"We have received a notification under the Digital Millennium Copyright Act (“DMCA”) from Dropbox that the following material is claimed to be infringing."
Doesn't this seem to imply that Dropbox is the owner of the code and is both the DCMA submitter as well as the company executing upon it?
An automated system would still require a company name that is requesting the DCMA to be entered, or your automated system is implying that all DCMA requests are coming from Dropbox. Something isn't right about this...
Accidents happen, but you sure do not want your startup to have an accident involving a DMCA takedown notice sent in error. There are penalties for doing such. It is generally best to vet this stuff with a lawyer.
Congratulations on becoming a large enough company to start getting hated on. The web recently started piling it on you guys which I think is something you should take pride in.
While you guys have (and always have had) a technically exploitable issue with de-dupe/hashing (which I think is a feature) now that you're the big kid on the block I hate to see you forced to close it.
It was a nice feature, but it isn't going to stand up to random hackers trying to make a name for themselves with a public release of relatively simple code and blog post about how they used/abused your service. Good luck!
And I definitely think it's time to change your demeanor from your local friendly startup to your impersonal corporate entity. At this point you're just going to be stirring up bees.
I personally feel that Dropbox removing files from someone's account is completely wrong, regardless of your ToS. Your service is there to backup files. When you delete references to files from someone else's accounts, you're violating the trust that people put in your service.
This contradicts your earlier statement -- that you removed the file from the person's account.
I'm on your side here, but you need to be as transparent as possible here. Are you also saying that your system automatically generates emails that make false claims about having received a DMCA takedown notice?
Despite that, I'm reading your terms of service, and it sounds to me like you reserve the right to terminate service (which sounds like it would include deleting files) with or without notice, if you deem there has been a sufficiently egregious violation of your ToS.
This whole situation is pretty revealing about Dropbox. If hosting software that COULD be used to violate the TOS were also a violation of the TOS, and if Dropbox had been in the practice of banning such files, then 2 outcomes would have obtained:
1. The system for banning files would not send out copyright infringement notices automatically. It would be set up for banning things like source code that could be used to violate the TOS.
2. Someone on the support team you claim the system was designed for, would have done the ban, instead of you having to come in and implement "higher-level business logic" by using the ban system for something besides copyright violations.
I don't understand why you would bother? If they still had the file, wouldn't they be quite able to post it elsewhere? Why the censorship? I'm not comfortable in the knowledge that Dropbox can willy nilly refuse to allow me to share files on a case by case basis.
Pimp slapping developers works well for Facebook and Apple so why you miss out on all that fun, right? Next time don't take the personal touch and email them personally. Instead wait for their app to gain a following then suddenly ban them and let them cry like bitches. Then send them a form letter saying their account was banned for violating the new ToS you haven't even posted yet, and by the way this communication is considered a national security secret so they can't talk about it to anyone including their spouse. That's big pimping. Then sign the email with "You've been Dropboxed, bitch!" That'd be your tag line. You're my hero.
We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that the email auto-generated and sent a DMCA takedown email. This was a tool built for our support team and I'd never personally used it.
The form letter the OP got wasn't a DMCA takedown notice. The letter stated that a takedown notice had been received. That was untrue (the file was being removed for a different reason) but since no takedown notice was sent it certainly isn't perjury.
Best thing you can do now: offer the dropship guy a job.
He knows your product well enough to "break" it and he has the motivation to create something strong enough that it is causing a fuss. Learn from Geohot. Don't scare away people who want to play with and extend your product.
If I may ask something quite specific: how do you justify _automated_ transmission of DMCA take-down requests? Shouldn't a human being be reviewing them first to prevent this sort of thing? Do you guys care? I mean, who's idea was that? As a customer and a developer, I'd really like to know.
"We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service."
Arash, you're confusing the software and its potential uses as if they were the same thing, which is standard DMCA brain damage. It's the FUTURE communication with the servers that COULD violate the terms via such communications, IF it actually happens because of an unknown person (possibly not the hoster) using the software at some (unspecified) later time. If that TOS-violating communication actually HAPPENS then you can gleefully shutter HIS account. You don't get to ban the software itself, if the hoster has permission (via MIT license) to host the file. Illegal sharing of copyrighted files is what's prohibited, and that is what the "automatic DMCA takedown" suggests---to wit, that your banning-files-by-hash system is designed to take down copyrighted files in response to DMCA takedown notices. If it was meant to ban files you don't like, you would have had a clue that it would send an erroneous DMCA message about the file.
So it's obvious you just wanted to ban the file. Can you really cite the TOS language that says hosting software that COULD be used for TOS-violating communications with Dropbox, is also a violation of the TOS?
I also think it would be interesting for readers of this forum to see whether or not you've already quietly changed your TOS to cover this case (or will soon do so.)
DMCA notices aren't a joke that you can idly send to anyone who annoys you. You are legally liable for them, and telling a judge "Oh, we just send them automatically without checking" is not going to help your case.
To razorfast guy:
Can you look at the SMTP headers of the DMCA takedown to see if they're coming from a desktop e-mail client or indeed some sort of auto-mailer? Might give a clue if the e-mail was indeed "auto-generated" or not
It is a shame your developers allowed you to commit perjury in such an automated fashion.
With all due respect to you and your company (and while I fully support your right to invoke your TOS to take down content within your own service) I'd actually love to see one of the people you DMCA'd slam you on that aspect of this situation legally if for no other reason than to make other companies think twice (or three times) before they improperly invoke the DMCA to scare people into submission.