[SwellJoe]

> Which is great, except you are punishing the crime, before it even occurred.

No, they aren't. They're enforcing the terms of use that Dropbox users agreed to when signing up.

I don't think asking folks to take stuff down was the correct solution...I think fixing the bug was the right solution, which they've also done. But, I don't see how Dropbox is "punishing" anyone, when they're just asking people to use the service as it is intended.

[tlrobinson]

It's clearly a violation of ToS to use Dropship, however, it's less clear whether it's a violation to store code that has the potential to violate the ToS.

[pbhjpbhj]

Presumably if someone has reverse engineered Dropship¹ then we're not far off having an FOSS Dropbox-a-like to use it with? I'd have thought that is the problem Dropbox is most likely to be addressing?

Run your own organisation-wide Dropbox? Yes please.

Edit: ¹ I mean of course created Dropship by reverese engineering Dropbox's protocols.

[SwellJoe]

> Presumably if someone has reverse engineered Dropship¹ then we're not far off having an FOSS Dropbox-a-like to use it with?

That's a pretty big stretch. You believe the client-side code to trigger download of a file that doesn't exist on the system is "not far off from having an FOSS Dropbox-a-like"? That's like finding a hub cap in the woods, and deciding you've almost got all the parts needed to construct a car.

I don't believe Dropbox is using any techniques that are secret; I believe anyone with the know-how, and time, and inclination, could use publicly available algorithms to replicate everything Dropbox has done. The "secret sauce" is not the protocol. There are a number of protocols for doing versioned filed storage (WebDAV, for instance) and a number of protocols for transferring only the parts of files which have changed (rsync, for instance). The hard part is in putting them all together, not in any magic to be found in a few lines of code.

I highly doubt this is all a conspiracy to prevent people from building a FOSS "Dropbox-a-like". People can already do that, without needing any Dropbox magic. Oddly enough, no one has. I reckon it's because it's really hard to put all those pieces together in a way that works easily for end users. Highly technical users have had these kinds of capabilities for years in the form of version control systems, rsync, etc. Open Source developers have solved the hard algorithmic problems already (and Dropbox is standing on their shoulders). What Dropbox did is make it accessible and usable by anyone.

Do people really need any explanation other than, "Somebody made a mistake and sent out the wrong email"? They don't strike me as being particularly evil guys when I've met some of them, and while they aren't bastions of Open Source generosity as far as I know, they also never seemed to be anti-Open Source, to me.

[pbhjpbhj]

>The "secret sauce" is not the protocol.

Verily.

>People can already do that, without needing any Dropbox magic. Oddly enough, no one has. I reckon it's because it's really hard to put all those pieces together in a way that works easily for end users.

These two sentences are contradictory. The magic clearly doesn't lie in the protocol per se or the specific idea but in the implementation. Having a client that emulates Dropbox _seems_ to be the hard bit strange as that may sound.

I have used the web interface, but the client is generally the only point of contact I have if I have a new client that does exactly the same and that client can be switched to a new server my experience will be >99% unchanged and, in my scenario, the effectiveness will be the same.

If I can switch service without noticing any change in interaction (dropbox just sits there after all) and in fact can use the same client with either dropbox itself or a different server then it seems like a bad thing for dropbox.

[Shorel]

iFolder seems to me very much like an open source Dropbox replacement.

Sadly, the server only runs on Linux, but to me this contradicts the assertion that an OSS Dropbox-like software has never been developed.

[phlux]

>...Run your own organisation-wide Dropbox? Yes please.

YAY!

this is how Dropbox should pursue an enterprise offering, selling a Dropbox Server as a VM, a set of client licenses and instructions on how to run an internal dropbox server.

With encryption. With additional security features...

[random42]

Yeah, I agree to enforcing the violation of ToS. I was writing for the DMCA take down notice for the possibility of illegal file sharing via dropship. (as mentioned by arash/drew in comments.)

I am actually curious to know what ToS were violated (based on which Dropbox decided to take the action), except that I have not read about the real reason on either the Original Article or the discussion on HN.

Can Drew/Arash clarify what Terms were being violated actually by dropship?

[res0nat0r]

> Can Drew/Arash clarify what Terms were being violated actually by dropship?

http://www.dropbox.com/dmca#terms

Access, tamper with, or use non-public areas of the Site (including but not limited to user folders not designated as 'public' or that you have not been given permission to access), Dropbox's computer systems, or the technical delivery systems of Dropbox's providers;

Attempt to access or search the Site, Content, Files or Services with any engine, software, tool, agent, device or mechanism other than the software and/or search agents provided by Dropbox or other generally available third-party web browsers (such as Microsoft Internet Explorer or Mozilla Firefox), including but not limited to browser automation tools;

[argos]

yes, but that has nothing to do with having the code, as I said in a port below... using it would be a violation, but why block open source code.

[shad0wfax]

Even I am struggling to understand how exactly did this violate ToS? Was it "illegal code/file"? No! It was a file to a s/w that had the potential to be used maliciously, but the file uploaded itself wasn't, but hadn't really manifested in that form (yet). I feel asking the dev to take down the Github project is ok, but blocking/restricting access to the file itself, until proven malicious was a bad idea. And if that part about taking down the HN is true, its a dick move. Yes, its their platform and from an ethical stand point, being proactive this way helps everyone, but it could have been handled better.

[random42]

To my understanding (after several downvotes, and few uncalled-for language), it is simple.

1. Dropship violated Dropbox ToS, by reverse-engineering Dropbox proprietary code.

Thats all.

Nothing to do with DMCA notice, which was sent by accident.

[shad0wfax]

Agree the Dropship s/w itself was in some violation of the ToS, but was the file that was uploaded to the public dropbox share in violation? What I am trying to separate here is, how could Dropbox the company "determine" the uploaded file indeed was the Dropship s/w? [I know in this case it was obvious as the dev had probably linked to it]. I am trying to pose a question to a different level, where how can/will dropbox scrutinize each uploaded file in this manner without actually receiving a DMCA from a third person?

[pbhjpbhj]

Are those ToS legal?

[gommm]

Yes, now that the bug is fixed I would have liked looking at the source code of Dropship just to see how it worked... So it's a pity that they asked people to take it down.

[SwellJoe]

According to several other comments the source code is still quite widely available.