Live data from Hacker News

Dropbox Attempts To Kill Open Source Project

razorfast.com

41–50 of 323 posts

Re: Dropbox Attempts To Kill Open Source Project

#41
Consider that maybe what's happening here is boring. Recognize that we all have a cognitive bias towards narratives, and especially interesting narratives. The discussion on this story is trying to build a narrative about Dropbox vs. open source developers. The real story is probably not that interesting.

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?

Re: Dropbox Attempts To Kill Open Source Project

#42
post #30

Earlier quoted context omitted.

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.

We didn't remove the file - we simply banned public access to it.

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.

Re: Dropbox Attempts To Kill Open Source Project

#45
post #21

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…

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.

Re: Dropbox Attempts To Kill Open Source Project

#46
post #21

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…

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.

Re: Dropbox Attempts To Kill Open Source Project

#49
post #41

Consider that maybe what's happening here is boring. Recognize that we all have a cognitive bias towards narratives, and especially interesting narratives. The discussion on this story is trying to build a narrative about Dropbox vs. open source developers. The real story is probably not that interesting. The CTO of a service as technically interesting as Dropbox certainly knows that he can't prevent the disclosure o…

* But how many of us are going to go out of our way to stick a thumb in Dropbox's eye? *

... and how is that not supposed be flamebait?

Post reply on HN