Dropbox Attempts To Kill Open Source Project • Hacker News Board

Re: Dropbox Attempts To Kill Open Source Project

#121

Post by xnerdr » Mon, Apr 25, 2011, 9:53 PM UTC

CoffeeDregs wrote: post #22

Most interesting comment to that article: Thankfully all DMCA requests are filed under penalty of perjury. If he claims that he owns the copyright to material he doesn’t own, he has now opened himself up to civil litigation. Really. Seems so: http://www.aaronkellylaw.com/Internet-Law-and-Intellectual-P...

Would the civil litigation be against the company or the person? What sort of penalties are involved in such cases? If they lose, would the winner basically own a chunk of dropbox?

(sorry, none American and not a lawyer)

Re: Dropbox Attempts To Kill Open Source Project

#122

Post by rhizome » Mon, Apr 25, 2011, 9:54 PM UTC

dhouston wrote: post #106

drew from dropbox here. i hope you guys can give us the benefit of the doubt: when something pops up that encourages people to turn dropbox into the next rapidshare or equivalent (the title on HN was suggesting it could be the successor to torrents), you can imagine how that could ruin the service for everyone -- illegal file sharing has never been permitted and we take great pains to keep it off of dropbox. the inte…

I appreciate the nice-guy approach here, but there remains two problems with it: relying on the goodwill of internet strangers not to abuse the service and exposing Dropbox to false DMCA takedown liability. "Under penalty of perjury," I think the clause goes. That auto-takedown workflow might need a little revision, but I'm sure you already realize this.

Re: Dropbox Attempts To Kill Open Source Project

#123

Post by random42 » Mon, Apr 25, 2011, 9:54 PM UTC

dhouston wrote: post #106

drew from dropbox here. i hope you guys can give us the benefit of the doubt: when something pops up that encourages people to turn dropbox into the next rapidshare or equivalent (the title on HN was suggesting it could be the successor to torrents), you can imagine how that could ruin the service for everyone -- illegal file sharing has never been permitted and we take great pains to keep it off of dropbox. the inte…

> illegal file sharing has never been permitted and we take great pains to keep it off of dropbox.

Which is great, except you are punishing the crime, before it even occurred. Remember use of torrents are not illegal per se, sharing files which you do not copyright of, and piracy is.

> there were no legal threats or any other shenanigans to the author or people hosting. (EDIT - No applicable. Read Drew's edit.)

DMCA takedown notice is a legal threat. Worse part is, its not even valid, IANAL, but do you own the copyright of the data or the copyright owner approached you to issue a DMCA takedown notice?

> it auto-generated a DMCA takedown notice to the OP, which as many pointed out here was invalid and particularly inappropriate in this case, and was absolutely not what we intended to do.

Please do not send legal notices, without lawyers reviewing them?

Re: Dropbox Attempts To Kill Open Source Project

#124

Post by driverdan » Mon, Apr 25, 2011, 9:55 PM UTC

SoftwareMaven wrote: post #118

The DMCA notice came as a result of an automated support system. The CTO's understanding was the system blocked access to individual files, but the real purpose is blocking access as part of DMCA requests, so it automatically sends the DMCA notices out. This wasn't somebody trying to strong-arm somebody else. It was an understandable mistake.

I agree with your assessment. It seems that the DMCA notice was a mistake, there was no real takedown issued to Dropbox.

Re: Dropbox Attempts To Kill Open Source Project

#125

Post by random42 » Mon, Apr 25, 2011, 9:55 PM UTC

slackerIII wrote: post #120

huhtenberg wrote: post #112

Earlier quoted context omitted.

> we've fixed the deduplication behavior serverside Great, and that's all you should've done in this case.

> Great, and that's all you should've done in this case I doubt that is what the lawyers said.

Then they should fire the lawyer who a-OKed to send the invalid DMCA takedown notice(s), which makes Dropbox culpable for it.

Re: Dropbox Attempts To Kill Open Source Project

#126

Post by kragen » Mon, Apr 25, 2011, 9:56 PM UTC

wewyor wrote: post #58

shad0wfax wrote: post #44

Strike 2, dropbox

What was strike 1? I can understand them not wanting the files to be public, but as tptacek said this is probably fluffed up quite a bit. As far as I'm concerned the only issue with how they handled it is the DMCA takedown request, and if the CTO acted as said but that is less of a factor. If the files were never removed from the persons dropbox and only public urls disabled I'm okay with that. However if the files w…

Strike 1 was when they got caught lying about whether their employees could decrypt your files or not.

Re: Dropbox Attempts To Kill Open Source Project

#127

Post by iamjustlooking » Mon, Apr 25, 2011, 9:56 PM UTC

wewyor wrote: post #58

shad0wfax wrote: post #44

Strike 2, dropbox

What was strike 1? I can understand them not wanting the files to be public, but as tptacek said this is probably fluffed up quite a bit. As far as I'm concerned the only issue with how they handled it is the DMCA takedown request, and if the CTO acted as said but that is less of a factor. If the files were never removed from the persons dropbox and only public urls disabled I'm okay with that. However if the files w…

I assume strike one is this:

http://dereknewton.com/2011/04/dropbox-authentication-static...

Re: Dropbox Attempts To Kill Open Source Project

#128

Post by amock » Mon, Apr 25, 2011, 9:57 PM UTC

runjake wrote: post #102

mtogo wrote: post #80

Earlier quoted context omitted.

Four seconds on duckduckgo: https://secure.wikimedia.org/wikipedia/en/wiki/List_of_onlin...

Thanks for the sarcastic response, but I'm already familiar with that page. What I'm more interested in is what HN users like and dislike and recommend, as opposed to a bunch of features charted into a table with nothing valuable in terms of reliability, usability and actual security. Lately, I've been leaning towards Jungle Disk for file syncing & some S3 solution for cloud backups.

I've used SpiderOak and I was happy with it. I only used it to synchronize files across my laptops and desktops so I don't have any experience with mobile clients for it. I now use cron, rsync, and ZFS snapshots for versioning of all of my home directories. Both solutions worked well for me and which one, if either, is best depends on your situation.

Re: Dropbox Attempts To Kill Open Source Project

#129

Post by crocowhile » Mon, Apr 25, 2011, 9:58 PM UTC

power78 wrote: post #86

crocowhile wrote: post #76

Earlier quoted context omitted.

Or you can just share a folder with someone or give them the public link - and both are even easier solutions.

Again, that requires you to: A) move the files to the public folder B) watch out for bandwidth limits on the public folder C) give your Dropbox account ID to everyone as it is tied directly to the URL With this method, you get anonymous file transfers without bandwidth limits

>With this method, you get anonymous file transfers without bandwidth limits

Yes, only if dropbox let you do that. They can make you stop with a fix in 5 minutes and they will do it very soon.

Re: Dropbox Attempts To Kill Open Source Project

#130

Post by marshray » Mon, Apr 25, 2011, 9:58 PM UTC

dhouston wrote: post #106

drew from dropbox here. i hope you guys can give us the benefit of the doubt: when something pops up that encourages people to turn dropbox into the next rapidshare or equivalent (the title on HN was suggesting it could be the successor to torrents), you can imagine how that could ruin the service for everyone -- illegal file sharing has never been permitted and we take great pains to keep it off of dropbox. the inte…

Help me, I'm trying to get my head around this.

You developed a file sharing system that allows anyone to obtain the full contents of a file by simply knowing its hash?

Then when developers make tools to allow using this for simple cross-account file transfer you send DMCA takedown notices, claiming you are the rightful copyright holder of their code, to places like GitHub?

You seem to equate other file transfer services with "illegal file sharing".

Did you ever consider the possibility that someone could steal the contents of another person's file by knowing the hash of it? Sometimes hashes are public info and the file contents are not.

Or am I not understanding what just happened here?