241–250 of 273 posts
Great. I posted two forks, if GitHub takes action then I've got standing to sue RIAA (under the declaratory judgement act), which I'd love to do pro se. Btw, if anyone is associated with any fork that did go down and is interested in bringing a pro se case, feel free to contact me. I'm not a lawyer and can't give legal advice but I can help point you at some helpful laws and cases. I've been fighting false infringeme…
Earlier quoted context omitted.
That isn't a counter claim, it is a lawsuit by a company that isn't affiliated with youtube-dl and the claims of the suit predate the youtube-dl incident. In 2019, the RIAA got a court order to have Google remove the Yout domains from search results. Yout is arguing that their service provides time shifting, which is fair use, and their domains should be restored on Google search. Plus, they want damages. FYI -- Yout…
I watched the talk some days ago. You apparently came to another conlusion. Do you have references about the case you mentioned?
Earlier quoted context omitted.
> 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…
>the mailing list does not serve the function of email address discoverability in any form. Instead, the source is the source code itself, in which the target email addresses will be recorded ad nauseam. 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…
You have missed the point entirely.
The email Git workflow is based around—you guessed it—git. Git, being designed entirely around email-based workflows, stores the email authors and committers of every commit (they often differ), and furthermore, often also marks the reviewers. This is fully automatic.
If you are looking for email addresses, you either A) do not have the prerequisites for doing the work in the first place, or B) do not understand git.
Any Git tree that has not been intentionally butchered will contain the email address of every single maintainer and contributor to ever have contributed to the project, and that is always the only thing you need when doing email workflows.
(Linux stores more than that, for convenient official subsystem maintainer lookup—but focusing on the extra processes that a project that in 2019 alone had over 74k commits from 4k authors with over 5 million lines of code changes needs is a little silly when we're talking about comparatively tiny projects where git info is fine.)
> How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!?
You are derailing significantly. If you have not yet figured out how to obtain a git tree, then you have clearly gotten ahead of yourself with most of your arguing. How can you be discussing how to create issues if you don't even know how to get the software in the first place to discover issues with? How do you even know of the software if you had not already found a place which could contain the starting point for your process?
Nothing with relation to workflows and VCS has any important before you manage to get ahold of the software in the first place, whether that is on a website, forge, IPFS, USB dongle smuggled by a packer over a border, or whatever you'd like.
The starting point, however, is nothing more than that. It serves no purpose once "recruitment" is complete, as you work on your machine-local repo from there. You may occasionally sync with other individuals trees, in what can be considered peer-to-peer transactions, but even that is mostly optional, and it can be done with any individual. You do not need full consensus in the tree.
(The tarballs you refer to are not for development. They're only releases for end-users, which cannot be used to make patches from.)
> I can only guess that you're using mental model of Linux kernel development.
The development model are used for many other projects, including a handful of mine.
If you think that there are no adversaries out to kill Linux, you'd be sorely mistaken, but it's moot as it has no single points of failure. Everyone works on their own trees, and send around patches, occasionally syncing in various directions.
---
The fact that you have now assigned several disconnected components as focal points underlines the fact that there are, in fact, none. I have also come to the conclusion that you are not very familiar with neither git itself nor the email workflows it was developed to sustain.
Granted, there will always be central individuals, in the form of the maintainers of the subtree you are contributing to (note: there can be any number of maintainers and subtrees for a given project). This is not due to infrastructure, but due to code changes losing meaning if arbitrary patches are applied in arbitrary order. But, there is no single point of failure and no single point of gathering.
But, even then, they are not focal points. The various maintainers act as focal area of a particular subtree, but they are organic and redundant, and loss of one is is easily routed around as any holder of a tree can accept patches and act as a maintainer. And loss of one implies loss of an individual, not loss of a random hosting service.
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.
I’ve heard this over and over, but I never understood it. How is Git supposed to be decentralized when you push and pull from one place? Would you just set up multiple “origins” with each one pointing to a head maintainer’s computer (and named appropriately)? Because that sounds like a massive pain compared to a centralized system like GitHub. Of course, there is the benefit of a VCS built on the idea of decentraliza…
You clone a maintainers personal tree (which can be anywhere), make the change, and email them the patch with git send-email. They then apply it with git am -3. Trusted maintainers might tell another maintainer to pull their tree from wherever they put it, but they can place it wherever in the moment, including just on their own machine - it only needs to work for a single fetch as well, and could be a new location every time.
Earlier quoted context omitted.
I watched the talk some days ago. You apparently came to another conlusion. Do you have references about the case you mentioned?
Are you hard of hearing? The link you posted has the filing clearly visible in the video. I read it. All claims are based on actions taken in 2019. Not one mention of the youtube-dl DMCA violation.
Yes. Thanks for reminding me.
Earlier quoted context omitted.
None of those matter if a US court has declared that there's no infringement. Also, many of those probably don't cover circumvention.
Literally everyone who is a member of WIPO covers circumvention, so that's 193 countries.
I still think a US ruling would be very beneficial, even if it doesn't definitively settle the issue globally.
Earlier quoted context omitted.
>the mailing list does not serve the function of email address discoverability in any form. Instead, the source is the source code itself, in which the target email addresses will be recorded ad nauseam. 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…
> Not every project records email addresses in the source code. You have missed the point entirely. The email Git workflow is based around—you guessed it— git . Git, being designed entirely around email-based workflows, stores the email authors and committers of every commit (they often differ), and furthermore, often also marks the reviewers. This is fully automatic . If you are looking for email addresses, you eith…
Why is this question so strange to you? The end user usage of a tool can be much more widely known than the workflow development of it.
Let's take a look at Youtube-dl specifically:
Go to "http://youtube-dl.org/" ...
There are only 3 obvious web pages: (1) Home (2) Download (3) About
From there, you can download some binaries to use the software but there is no mention of any source host to enter a "git clone" to then later do a "git shortlog --summary --numbered --email".
It is way easier to get the end user software to run than clone the git tree. For some reason, your reasoning assumes they are always tied together but youtube-dl is an example where they are not. (It sorta used to be tied together when the youtube-dl webpage's "dev repository" link to Github actually worked. It doesn't work now. See the "ex nihilo" problem?)
And btw, a git clone doesn't help for sensitive (aka legally uncertain) projects where contributors don't enter real valid email addresses and/or the use fake email to avoid spam. (This is a general statement and not a email address validity test of youtube-dl maintainers specifically.)
Also, a "git clone" is a barrier for non-programmer end users who just want to report a bug. The Github repo (or mailing list) was a logical place (Schelling Point) for that type of activity rather than cloning a repo that the end user doesn't need.
>The starting point, however, is nothing more than that.
But some starting points matter more than others.
>If you think that there are no adversaries out to kill Linux, you'd be sorely mistaken,
This is not engaging with the spirit of what I wrote. Surely, you realize we were talking about adversaries such as RIAA/MPAA/DMCA using legal threats for takedowns and not business competitors such as Microsoft that tried to squash Linux.
>, but it's moot as it has no single points of failure. Everyone works on their own trees,
This is a 100% true statement about no SPOF that is not relevant for this youtube-dl discussion. We already know hundreds (thousands) of people have already git cloned youtube-dl and some have even re-uploaded copies back to Github. But all that copying misses the point of all the various threads in the last week where people wonder where the "blessed repo" with PRs/issues/etc will live that's resistant to censoring. Repeating the "no SPOF nature of distributed git" is not making progress in that discussion.
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…