- youtube-dl should be re-named to something like webvideo-dl

- I'm not familiar with the ytdl codebase, but I believe its already structured as a general framework, with separate per-site extraction functions. The central framework should be stored in a "webvideo-dl" repo, and the separate extraction functions should be contained under separate repos - e.g. "wvdl-plugin-youtube".

This solves two problems:

1. If "wvdl-plugin-youtube" is DMCA'ed, the rest of the project continues to function.

2. Separate "plugins" can be maintained by separate teams. It sounds like the original youtube-dl was already running behind on responding to issues and PRs, prompting the creation of the youtube-dlc fork.

I think you're right, this is a great way to move forward, especially if it's possible to put a bit of distance between the old youtube-dl and the new project.

Hopefully, it wouldn't require as much effort as when a lot of the UNIX utilities were rewritten to get properly licensed versions back in the 80s - I remember a description of how they were rewritten from being cpu-optimized to being memory-optimized to avoid any code similarities.

The trick, I guess, would be to restructure the code so that the new "dl-webvideos" project would be hard to construe as a continuation of the original project.

The other trick would be, that the new solution has to be started fast to avoid losing momentum.

Incidentally, that is what calibre does: the DRM-cracking parts are separate plugins, so if those get DMCA'd the rest of the program is unaffected.

When the OP(top commenter) mentioned building the "Next Thing", I thought we finally are going to discuss about building an alternative to YouTube. But here we are trying to save what's already lost like OP said

Youtube-dl was great and it's huge loss but it seems any efforts in improving or maintaining it will just be harder now. Instead if we could focus that energy on building something robust and resistant to such actions we might actually have solved this.

> I thought we finally are going to discuss about building an alternative to YouTube.

There are plenty of alternatives to Youtube, a bunch of them defunct. Youtube is irrelevant to this conversation; the DMCA takedown would have been equally effective had the copyrighted URLs been from Vimeo or Dailymotion or any other project that dies in a year because its creators don’t understand what makes a video site (and `youtube-dl`) is the community, not the tech behind it.

"youtube-dl should be re-named to something like webvideo-dl"

I think a better choice would be to fork/branch wget or curl and maintain a "supercurl" or "curl2" whose superset of curl functions just happens to be the merged functions of youtube-dl.

I think this is best strategy. However, how would you download plugins then? Make a whole package manager for handling youtube-dl plugins?

That would be ideal, however, you could just re-use the existing `pip` infrastructure.

e.g. pip install wvdl-plugin-youtube

Notably, youtube-dl is currently offered as a static binary that doesn't require Python to be installed. It would be a shame to loose that.

Presumably that's a blob that bundles the python runtime, pip dependencies, and ytdl itself? You could do the same thing, with the various "plugins" added to the pip dependency list.

...good point, not sure what I was thinking there. I'm pretty sure it's just pyinstaller, which can certainly handle bundling dependencies.

I actually don't think they should rename. The only party who can reasonably have a problem with the name is YouTube, who have been well aware of it for a very long time.

The name is good, there's a lot of really legal use cases -- downloading properly licensed videos for offline usage, archiving your own creations, etc.

The fundamental problem was that in the README and elsewhere, there were examples of ripping copyrighted content.

It would've been better to use examples of libre/public domain content, but I'm not sure how they can un-sail that ship.

The real solution is that we use the decentralized version control system as intended, and make this impossible to DMCA-away.

The reason I propose a name change is mainly for clarity of purpose, rather than for any kind of legal protection (although I do think it contributes there too). Youtube-dl downloads from many other sites. If I was a potential new user googling for "vimeo downloader", and the first result was titled "youtube-dl", I'd skip over it assuming it was just a bogus search result.

From what I read earlier the problem is bound up in the solution. Youtube has mechanisms to prevent download of copyrighted content which youtube-dl circumvents deliberately, which is why it works on every video. That's what the unit tests were all about and why they had to use examples of strictly protected copyrighted material.

The only options are to move development to a server located somewhere beyond the reach of the DMCA and similarly take it off all repositories or to give up on making it possible to download every (or even most) videos from youtube.

But the tool expanded significantly from its original purpose of acquiring YouTube videos, and it supports at least a hundred platforms through all its extractors. An opportunity to rename it to a more purposeful name will not come very often.

Pretty much every western country has implemented the WIPO treaties equivalent to the DMCA. You can't flaunt copyright law without causing headache for the vast majority of contributors.

The productive next step is to make youtube-dl compliant with copyright law, namely by removing the TPM-circumventing code from youtube-dl (`YoutubeIE._decrypt_signature`), and making the marketing material reflect that it's designed for non-infringing or exempted uses only. Unfortunately, you can't 'put the genie back in the bottle', so it's unlikely the original authors can continue to be contributors.

In the long term, put energy into reforming copyright law.

> make youtube-dl compliant with copyright law, namely by removing the TPM-circumventing code from youtube-dl (`YoutubeIE._decrypt_signature`)

I fail to see how this code is non-compliant with copyright law, considering it is a necessary step to complete the transaction. Is the TLS decryption code in every browser non-compliant?

There are fair use reasons to download otherwise-copyrighted videos, and you would need to run this code to do that.

See also: DeCSS

Why can't the original developers continue work on the kind of non-infringing alternative/fork that you just outlined? Are they somehow legally "tainted" and debarred from ever creating this type of code again?

On that I'm just speculating, but you'd need to be able to argue that the "new" youtube-dl has a different design purpose than youtube-dl, which seems difficult to do if it's all the same people that made the previous infringing software.

*flout

Someone just needs to create a swiss army knife headless browser streaming file saver/converter and leave out any text about how to download youtube videos with it.

Then the community can be like Popcorn time and say, ahem, no copyright infringing code here.

Or a version could even be released w/out the test cases and or README files that make any reference to any type of "illegal" activities.

Contribute to the Lynx browser to download embedded video's to mp4. Add flags to the command line to download them. Then it serves as an integral part of a web-browser and you don't break the Youtube TOS.

Edit: Add to firefox a right-click option "Save Video As".

We can create a repository just for issues, like Microsoft does with WSL: https://github.com/microsoft/WSL

I would start by using a distributed bug/issue tracker to ensure the contributors can communicate and manage the project in events like this one.

Git is already distributed and the availability of a lot of clones of the repository out there shows it is working as intended.

A good start would be using Fossil ( https://fossil-scm.org/ ) for its distributed issue tracker, wiki, and forums -- but not for the source code control! Let the code stay on Git as it belongs.

     ____________________________________

Unrelated soapbox moment: Fossil is a great idea built upon the bad idea of recreating Git in the wrong way... it would be perfect if it just all other things except source control, leaving this part to git.

> Should we re-locate to a different space?

Move parts of the infrastructure to decentralized platforms, like a Matrix chatroom, or mailing lists. Link that on the website. As long as the community keeps together, the rest can move around.