so, when something like this gets called to our attention, we have to do something about it. note that this isn't even by choice -- if we don't take action, then we look like we are tacitly encouraging it. the point is not to censor or "kill" it (which is obviously impossible and would be idiotic for us to try to do), but we sent kindly worded emails to the author and other people who posted it to take it down for the good of the community so that we don't encourage an army of pirates to flock to dropbox, and they voluntarily did so.

there were no legal threats or any other shenanigans to the author or people hosting -- we just want to spend all our time building a great product and not on cat-and-mouse games with people who try to turn dropbox into an illegal file sharing service against our wishes. (for what it's worth, dropship doesn't even work anymore -- we've fixed the deduplication behavior serverside to prevent "injection" of files you don't actually have, for a variety of reasons.)

that said, when we disabled public sharing of that file by hash, it auto-generated an email saying we had received a DMCA takedown notice to the OP, which was incorrect and not what we intended to do, so i apologize to dan that this happened.

(*edited the last paragraph: we didn't send a takedown notice, we sent a note saying that we received a DMCA takedown notice, which was also in error)

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'.

The CTO of a service as technically interesting as Dropbox certainly knows that he can't prevent the disclosure of their proprietary protocols. So impassioned arguments about "security through obscurity" and "the futility of trying to hide protocols" aren't adding much to the discussion. Everybody understands those things. To the extent that Dropbox's protocols factor into this story, they are obviously a fig leaf.

Thus far, the only thing Dropbox is purported to have done here is to politely ask a developer to remove an application; then, presumably believing that the mirror posts were simple nerd-rage, and that the author of the application agreed with Dropbox, Dropbox's CTO filed takedowns at Github. This is not the end of the world. As has been amply demonstrated, Dropbox can't effectively suppress MIT-licensed code, and probably won't try to.

Instead, consider that maybe all Dropbox is trying to do here is establish a track record of "not wanting Dropbox to become Rapidshare". This story then is not a "PR nightmare" for them; it's the expected outcome of their actions. They are trying to communicate both through words and actions that they are going to do what they can to not be Rapidshare.

That Dropbox cannot technically keep determined nerds from trying to coerce them into Rapidshare's use case is also not worth arguing about. I think we all know that's true. But how many of us are going to go out of our way to stick a thumb in Dropbox's eye?

As a rule this is a pretty impoverished epistemic strategy.

It made me realize one important, no, crucial! thing: If you're mad at your client for any reason, it only means you're not charging him enough. It's very hard to be mad at a client who's paying you a ridiculous amount of money for something you're fabulous at.