gitlab.com? No. https://youtube-dl.org/ ’s host? That’s almost exactly what they did. (Edit: here’s my comment on a story that details their response somewhat: https://news.ycombinator.com/item?id=24909982).

The webhost had a different situation: neither code nor binaries were hosted with them. Although DMCA specifically doesn't apply to a German hoster of course, and uberspace is run by the kinds of people that'd probably try and take this to court instead of just rolling over.

I don't follow, a few days ago I downloaded the tarball of the code and 'binary' (it's a Python script) from their website. Both seemed to be hosted there.

https://youtube-dl.org/downloads/latest/youtube-dl-2020.11.1...

It's hosted on gitlab.com:

    $ curl -sS -D- -o/dev/null \
       https://youtube-dl.org/downloads\
       /latest/youtube-dl-2020.11.12.tar.gz
    HTTP/1.1 302 Found
    Date: Mon, 16 Nov 2020 15:04:10 GMT
    Server: Apache/2.2.15 (CentOS)
    Location: https://youtube-dl.org/downloads\
      /2020.11.12/youtube-dl-2020.11.12.tar.gz
    Content-Length: 3
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

    $ curl -sS -D- -o/dev/null \
       https://youtube-dl.org/downloads/\
       2020.11.12/youtube-dl-2020.11.12.tar.gz
    HTTP/1.1 302 Found
    Date: Mon, 16 Nov 2020 15:05:03 GMT
    Server: Apache/2.2.15 (CentOS)
    Location: https://gitlab.com/dstftw/\
      youtube-dl/uploads/99d745f22ca3c2a8e9a2\
      3def5446289a/youtube-dl-2020.11.12.tar.gz
    Content-Length: 3
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

Weird. It's hosted by github.com when I run identical commands:

    (base) /tmp  curl -sS -D- -o/dev/null https://youtube-dl.org/downloads/latest/youtube-dl-2020.11.12.tar.gz
    HTTP/1.1 302 Found
    Date: Mon, 16 Nov 2020 15:52:13 GMT
    Server: Apache/2.2.15 (CentOS)
    Location: https://youtube-dl.org/downloads/2020.11.12/youtube-dl-2020.11.12.tar.gz
    Content-Length: 3
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

    (base) /tmp  curl -sS -D- -o/dev/null https://youtube-dl.org/downloads/2020.11.12/youtube-dl-2020.11.12.tar.gz
    HTTP/1.1 302 Found
    Date: Mon, 16 Nov 2020 15:52:27 GMT
    Server: Apache/2.2.15 (CentOS)
    Location: https://github.com/ytdl-org/youtube-dl/releases/download/2020.11.12/youtube-dl-2020.11.12.tar.gz
    Content-Length: 3
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

Either they just switched back, or they have it pick from multiple mirrors.

Yeah, makes sense!

Either way, though, they are not hosting it on their website contra the GGGGP (https://news.ycombinator.com/item?id=25112011)

This is a little meta, but you can use the the -I / --head argument to tell curl to download headers only. This will ignore the rest of the response and means you can eliminate all of those other flags. E.g.:

    $ curl -I https://youtube-dl.org/downloads/latest/youtube-dl-2020.11.12.tar.gz
    HTTP/1.1 302 Found
    Date: Mon, 16 Nov 2020 19:10:37 GMT
    Server: Apache/2.2.15 (CentOS)
    Location: https://youtube-dl.org/downloads/2020.11.12/youtube-dl-2020.11.12.tar.gz
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

Not quite: when you pass "-I" curl makes a HEAD request instead of a GET request:

    $ curl -sS -v -I \
        https://www.jefftk.com 2>&1 | grep '^>'
    > HEAD / HTTP/1.1
    > Host: www.jefftk.com
    > User-Agent: curl/7.58.0
    > Accept: */*
    
    $ curl -sS -v -D- -o/dev/null \
        https://www.jefftk.com 2>&1 | grep '^>'
    > GET / HTTP/1.1
    > Host: www.jefftk.com
    > User-Agent: curl/7.58.0
    > Accept: */*
    >

It turns out that, often enough to be worth worrying about, servers do not return the same headers in response to a HEAD request as a GET request, so I always send a GET request when debugging strange behavior.

Same, but interestingly enough today when I click the link my browser Palemoon’s popup dialog (asking whether to open in an extractor app or just download) says the file is from https://gitlab.com.

That link redirects to a file on gitlab.com, and that they don't host it was given by uberspace as part of the reason for ignoring the request.

Huh, so that's basically the excuse TPB uses right? "We don't host content, just links to content."

I think he's referring to a self hosted gitlab instance, not gitlab.com

The youtube-dl removal was not a DMCA takedown request, under no situation could you consider the repo to be hosting copyright material.

gitlab.com, btw, does clearly advertise that they comply with DMCA takedown notices.

https://about.gitlab.com/handbook/dmca/

Others in this sub-thread have identified that the downloadable releases are actually currently hosted on gitlab.com.

Gitlab has their internal workflow for handling DMCA takedown's public (as with most/all of their internal policies, which is cool!). https://about.gitlab.com/handbook/engineering/security/opera... It may be that they go a little bit slower with more chance for the alleged infringer to respond (with a counter-notice or voluntary takedown) than others.

But in the end, any major US company (or company doing business with the US) is probably going to comply with the DMCA, which says that if you get a takedown notice that is formatted correctly, you take down. Then there's a process with user filing a counter-notice, then the original filer having a chance to respond to THAT, etc., that you can see in the gitlab workflow, but most of that is just how DMCA works. "If there was a valid counter-notice and no response has been received from the plaintiff within 10 days of the counter-notice being forwarded" then the content might go back up.

> Actually, I guess I'm not sure of the consequences to a company of ignoring DMCA takedown requests (whether or not they are US companies; but Gitlab is now btw), but I assume they are not good, or why do companies bother complying? Rather than assume, I should look into it.

The request is essentially a precursor to a lawsuit, so the consequences are a potential lawsuit and all of the legal fees that go along with it.