171–180 of 273 posts
Earlier quoted context omitted.
Why would the RIAA takedown apply in other jurisdictions, when it cites US law?
The US and some of its allies have signed treaties and agreements that protect IP internationally.
Some example comments in this thread: >"People should move their youbube-dl repositories to servers hosted in Switzerland, " >"Time for a decentralized version control system?" >"The nice thing about fossil" ... those well-meaning suggestions are missing the true difficulty : The community wants a (1) Schelling Point [0] for workflow/issues/discussions/PRs that's also (2) censorship resistant. So far, (1) and (2) con…
The main issue is all the information that is Github-exclusive (like the "issues"), which AFAIK is extremely valuable for youtube-dl, and also AFAIK cannot be (easily) exported. But then developers should have know better than to put all their eggs in someone else's (Microsoft's !!) centralized and locked basket.
If Pirate fricking Bay is still up after all these years, so can be youtube-dl repository/ies.
EDIT : probably an even better example : Popcorn Time
Earlier quoted context omitted.
"Fully offline capable" would be a better term than "decentralized" when describing git. But, one relatively decentralized workflow that git has good support for is sending patches via email (git format-patch, git am). I believe the Linux kernel still does a large amount of its collaboration that way.
As does ffmpeg. Some more recent developers seem incredulous. https://github.com/FFmpeg/FFmpeg/pull/153#issuecomment-15416...
Earlier quoted context omitted.
>The fault lies in the assumed importance of the list. The "importance" of the mailing list I'm trying to emphasize is the Schelling Point . This is the social discovery aspect you're not addressing. Let's dissect your following example: >When I send a kernel patch, I send it to the maintainer, then CC anyone I myself think should be involved, and finally CC the relevant lists (plural). The list acts as feed for lurk…
> The "importance" of the mailing list I'm trying to emphasize is the Schelling Point. You have said Schelling Point enough times for me to have caught that. It is, however, not correct to assign this to the mailing list. (Also, as a side-note, "focal point" is a more natural, common, and much less awkard term.) > The list also acts as a Schelling Point to coordinate and consolidate public discussions. No, it does no…
Not every project records email addresses in the source code. Yes, the project maintainers could do that, but some don't.
I'm looking inside the latest "youtube-dl-2020.11.01.1.tar.gz" source archive and it does not have maintainers' email addresses in it. The main Python source code file "YoutubeDL.py" and other .py files do not have email addresses. The archive also has a text file "AUTHORS" for historical credits -- but no actual email addresses. I suppose the current maintainer could explicitly put his email address in that source, but he/she didn't. (Maybe there are good reasons to avoid putting an email address in the source code.)
>To carve it out: You, as a holder of the source code, will always be able to send patches, ask questions, as well as start discussions that others will organically be added to, using no other sources of information than the source, irrespective of mailing list availability, as long as you can send email, and that at least one of the maintainers or contributors of the source can still receive email.
Based on what you wrote, it seems you still have not fully internalized the difficulties of a Schelling Point for something like Youtube-dl. Even if "youtube-dl-2020.11.01.1.tar.gz" contained the actual email address of the current maintainer, if that maintainer decides to quit because of RIAA hassles and someone else (unknown to us because we can't predict identities of future authors) takes over and creates a new "youtube-dl-2021.03.15.1.tar.gz", the old "tar.gz" file does not point to the existence of the new file or new canonical location. The world still needs a Schelling Point so people know where to download the latest trusted non-malware version of Youtube-dl even if they don't know the identity of the new maintainer. You claim the "source" can be the starting point ex nihilo but you still need a trusted Schelling Point to obtain the source in the first place to enable the subsequent steps of private email correspondence that make a mailing list server irrelevant.
How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!? Your answer: start with the source code.
My response: isn't that circular logic?
I can only guess that you're using mental model of Linux kernel development. The problem with trying to transfer that collaboration workflow over to youtube-dl is the Linux project does not have adversaries like RIAA trying to kill it. Schelling Points are stable in that world of mainstream projects and seemingly trivial. E.g. just read the Linux kernel .h/.c file for email addresses.
Earlier quoted context omitted.
A lot of EU countries have explicit copyright exceptions for personal copies though due to the storage tax, so youtube-dl is legal in those countries anyways.
It wouldn't be legal in any of those territories - those explicit copyright exemptions don't apply to content that you're not licensed to have permanently or broadcasts. European law also requires member states to have laws against breaching technical protection measures, and bypassing those isn't usually legal irrespective of personal copy exemptions. And in this case Youtube-dl was taken down because it was claimed…
On my case (French laws), there's no exception for that: https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI00000... as long as it's a private copy.
> European law also requires member states to have laws against breaching technical protection measures, and bypassing those isn't usually legal irrespective of personal copy exemptions. And in this case Youtube-dl was taken down because it was claimed to breach technical protection measures.
That's actually the opposite, there's an interoperability exceptions for DRMs unlike in the US, which protecting a video certainly falls into since you would not be able to read it.
Earlier quoted context omitted.
It's like closing the door and hanging the key next to the door for all to see. Definitely not an effective technical measure to protect the house. EDIT: And not to forget that Youtube hosts many CC-BY licensed videos which explicitly allow unlimited use (incl. decryption if necessary), and that Youtube has contracts with copyright collectives in most countries so for any user it is save to assume that the video is l…
> (and thus download and store for personal use is legal in most countries). That's a highly questionable statement. Certainly, most European countries do not have such a law in all circumstances, and it's dependent on if the personal use copy is made of an asset you are licensed to have permanent access to (which you aren't of a collectively licensed work) or a broadcast for timeshifted purpose (which an on-demand a…
Apparently you're in a Common Law country. In European countries making a copy for personal use is generally legal, unless the user should have been aware that the content was uploaded illegally; in the case of Youtube, the user may generally assume that the content has been uploaded legally, because Youtube has concluded contracts with most copyright collectives and the compensation is made in the form of a flat-rate surcharge on all storage media.
In Switzerland you may even legally download illegal content for personal use and also circumvent a copy protection for the purpose of creating a personal copy. EDIT: and did I mention that I studied law in Switzerland?
Earlier quoted context omitted.
I'm not sure how this is any different than how it's been for years now. GitHub has been complying with DMCA takedown requests since 2011[1]. What precedent needed to be set here? The RIAA could always do this and GitHub has been complying with it (because they legally have to). 1: https://github.com/github/dmca/
A lot of the things listed on the DMCA repo (if not most of them) are not software that could be used to download content, but the literal content you could obtain using them, such as textbooks, proprietary fonts, and so on. By taking down youtube-dl, Github has opened a window for copyright trolls to speculate about what a repository is used for, and take it down if one of its use cases involves downloading copyrigh…
Earlier quoted context omitted.
youtube-dl does not circumvent any protection measures, so hosting it should not be illegal in any country, including Switzerland. The only problem here is the absurdity of how the DMCA and similar works in the US, which allows companies to easily spam invalid claims and require content removed unless the victim puts in the work to prove the claim invalid. And, of course, that legal cases tend to be settled not moral…
> youtube-dl does not circumvent any protection measures, so hosting it should not be illegal in any country, including Switzerland. That's a different argument to "Swiss law is different to the US and permits this" though. Bluntly the international treaty wording that is integrated into all national laws is vague enough that I just don't know if what youtube-dl does would be found to trigger it. I certainly wouldn't…
Earlier quoted context omitted.
Has anything like that ever happened?
In Germany it is quite common to get a fine for that (an adhortatory letter or Abmahnung in German). Media companies monitor torrents, and as soon as they see a new German ip address seeding, they send a letter to the ISP with the IP address and timestamp. The ISPs send the law firm the real user address and then they send you a letter demanding a fine for illegally uploading copyrighted material often between 1000-3…
My experience is that instead most people switched to Netflix, Spotify, YouTube (et al.) because they were more convenient and cheap enough, and the MAFIAA mostly stopped caring about torrents.
And people that were worried about getting fined started using VPNs/seedboxes.
I still haven't heard of anyone in my circles getting a fine.
Earlier quoted context omitted.
> >"Time for a decentralized version control system?" I have to laugh at this one. Git is a decentralized VCS, that was effectively re-centralized (via Github) for the sake of convenience.
Git is not truly decentralized, in the sense that you still need to provide a few specific remote hosts, all of which could disappear due to law enforcement. Instead of one centralized server you've moved to maybe 3-4 centralized servers, which isn't that helpful against the issue at hand, especially if those servers are all within the US, Europe and other law-enforcement-cooperating countries. In a true decentralize…
Some time ago, I and a friend worked together on a project in a place where there was no centralized git server; both of us ran git-daemon (https://git-scm.com/docs/git-daemon) on our desktops, and we often pulled from the other as we developed each feature. It was fun, and worked really well.
Git is truly decentralized, in that each developer has a full copy of the code and its history, and any of these copies can be used as the source for other copies.
> In a true decentralized system (e.g. Bittorrent, Bitcoin, etc.) it's practically impossible to delete something, and there would be plenty of accessible copies of data in jurisdictions that are out of reach of any single country's law enforcement, and even out of reach of the original creator to delete, so the original creator's government would not be able to force them to delete it.
That's how it works with git; everyone who cloned the repository to their desktop (for instance, to develop and contribute a patch) has a full copy of the history up to that moment, and that copy is out of the reach of both other jurisdictions and the original creator. There's no way to even know how many of them there are, much less who has them.