GitHub hasn't been hacked. We accidentally shipped an un-stripped/obfuscated tarball of our GitHub Enterprise Server source code to some customers a couple of months ago. It shares code with github.com. As others have pointed out, much of GitHub is written in Ruby.
Git makes it trivial to impersonate unsigned commits, so we recommend people sign their commits and look for the 'verified' label on GitHub to ensure that things are as they appear to be.
As for repo impersonation – stay tuned, we are going to make it much more obvious when you're viewing an orphaned commit.
In summary: everything is fine, situation normal, the lark is on the wing, the snail is on the thorn, and all's right with the world.
Situation normal? Are you guys planning on removing other random projects due to invalid/Bogus DMCA takedowns? I really wish you guys would stand up to trolls.
Some people think RIAA’s DMCA notice is not legally valid, arguing RIAA is not the copyright holder and there is no infringing material. DMCA takedowns are for taking down works you own the copyright to; not for enforcing any arbitrary aspect of legislation.
It’s my understanding that service providers do not need to comply with illegal requests.
For example, if I DMCA’d <an oil producer>’s repository on accused violations of environmental protection acts, I don’t think it would be taken down, would it?
If GitHub was an independent company advocating for open source; would it have acted any different?
Note: Microsoft is a member of the RIAA.
Apple made waves and built lots of favour for resisting the FBI and challenging quasi-legal processes. They took risks and demonstrated their principles (Suing the FBI over a terrorist’s iPhone is unlikely to be the first recommendation from their legal counsel).
This smells like a qausi-legal process, and it would look great for GitHub/Microsoft if you do.
Some people think RIAA’s DMCA notice is not legally valid, arguing RIAA is not the copyright holder and there is no infringing material.
Almost all of the lawyers at HN, and the lawyers at the EFF, and the guy at Popehat, are all generally in agreement that there was nothing wrong with what the RIAA or what GitHub did. It should tell you something when the people most in a position to evaluate the situation don't see anything amiss.
It would seem your issue is with the DMCA, if so then the way to fix it is to change the legislation; lobby the necessary politicians to get the law changed.
If you object to people following the law because you feel they don't hold the same views on the matter at hand, the point is moot, unless of course you feel they should break the law.
Which leads back to, if you don't like a law then lobby for it to be changed.
My issue is indeed with the DMCA. Which is why, throughout this entire thread, I have not said a single word against Microsoft's actions. I'm not sure why you replied to my comment.
When faced with an oppressive law, people are entitled to do everything within their power to deal with it. Changing the law itself is certainly a great solution when practical, but it is not always practical.
I've changed the laws in two countries through my lobbying efforts, though saying which two countries (and which laws) would be too identifying given that this is my quasi-anonymous account.
But on that note, businesses change laws through lobbying all the time. That is indeed one of the complaints about our current system of government: that it is too susceptible to lobbying.
Of course laws change in response to business interests. The context of this discussion is changing laws like the DMCA, though, which protect capital interests.
My point is that’s a field of political power that even well-off members of the working class like computer programmers have zero access to. You will never affect a law which protects capital interests like the DMCA by writing your senators and congresspeople.
Sure, but you might hosting fundraising dinners, or making donations the NGOs that do have K-street lobbyist on staff. Both are activities professional-class software engineers have access to support.
EFF never stated that it was an invalid takedown request, just that they believe that youtube-dl has enough legal uses that they think the takedown request was counterproductive.
Op said "Almost all of the lawyers at HN, and the lawyers at the EFF, and the guy at Popehat, are all generally in agreement that there was nothing wrong with what the RIAA or what GitHub did"
OP lied. The EFF never said this. I can't find Ken White ("the guy at Popehat") saying anything similar either, but perhaps someone will post a link. And I don't know what "lawyers at HN" he's referring to either.
The practice of law and litigation is not concerned with normative or moral questions of right and wrong, merely whether something illegal was committed. It's sad, but it's true.
It's not sad at all. You wouldn't want a legal process that was concerned with morals instead of law. Morals are not universal; they are vague and subjective. Law is the anchor for evaluating adherence to moral norms we've agreed upon via our legislature.
No, I'm very familiar with it. Questions of whether a law was broken are not questions of justice. They may say things about justice, or lack thereof, in what the law is or how it is interrogated, but they're not one and the same.
There's a difference between "illegal" and "not legally required."
* RIAA was legally welcome to send a DMCA letter which didn't conform to DMCA requirements. Anyone can legally send a legal demand letter saying more-or-less anything, and plenty people do.
* Since this letter didn't conform to DMCA requirements, github wasn't required to take down youtube-dl, but was well within its right to do so.
* github wasn't required to take down other instances of youtube-dl, not referenced in the letter, and ban users, but github can probably fire customers without cause, so there was nothing illegal.
... and so on.
RIAA may or may not have a legal leg to stand on with the DMCA anti-circumvention stuff, depending on what exactly Google does, and I haven't dove into the system in enough detail to know. I don't think Youtube implements DRM, but perhaps it does and perhaps youtube-dl circumvents it. That should be between youtube-dl and RIAA, nor between RIAA and github.
My own opinion is RIAA can't have it both ways. If they don't want people to copy, they should use tools designed for that: iTunes, Amazon Music, etc. If they want to use viral networks used for sharing personal videos, they should respect that those networks are designed for, well, sharing. If my mom uploads a video of my son playing with her to Youtube, yes, family members might want to download that if she's okay with it.
The friction here is that centralized media, whom decentralized is disrupting, wants to now use decentralized media (and by "decentralized," I'm talking from a social perspective -- anyone can publish versus a few people can publish -- not a technology one).
According to the EFF link below they don't need to be a holder. If the software is for breaking locks they can submit a take down notice under section 1201.
It's a notice under the provisions of the DMCA, but it's not a "DMCA takedown".
What we call DMCA takedowns, coloquially, with the whole counter notification process etc, are notices submitted under Title II. That title deals with copyright infringement, not anti-circumvention.
That means treating such notices as a typical DMCA notice, as GitHub has done, is incorrect. GitHub may well choose to follow the takedown if it considers it valid and the repo infringing, but what they've done is treat it as a copyright takedown. And that is clearly, unambiguously wrong, as it goes against their own DMCA policy, linked from the youtube-dl repo's disabled notice, which says:
> The DMCA notice and takedown process should be used only for complaints about copyright infringement. Notices sent through our DMCA process must identify copyrighted work or works that are allegedly being infringed.
So yes, GitHub messed up here. That doesn't mean they shouldn't have taken down youtube-dl, but they way they went about doing it is wrong.
You'll notice that the EFF, in that article, never goes into the details of the takedown process that happened. They never said what GitHub did was proper. They are just talking about the anti-circumvention law in general.
The key here is that if they DIDN'T comply with it, the RIAA might sue them. Even if they were to win it (because a judge determines the takedown provisions don't cover it or for another reason), they'd be in for a costly legal battle. Moreover, without the Title II provisions, they would be liable for having distributed the circumvention in the past!
On the other hand, if they DO comply with it, the RIAA is extremely unlikely to sue them, whether this is covered by the safe-harbor provisions of Title II or not.
Microsoft might find itself in a costly legal battle? Oh no, software freedom must be curtailed lest poor Microsoft ever find itself in a costly legal battle for doing the right thing.
I also found it a funny comment because Microsoft employs about 500 lawyers as part of an in-house legal team that is larger than most independent firms. If standing up for what it thinks is ethically and morally right isn't something a multi billion $ company with 500 lawyers can do, who can?
That is actually not true. Many laws, in many jurisdictions, are challenged by defending those who break them.
In fact, in the US, that is the _only_ way for a citizen to challenge a law. One cannot challenge a law that they have not been charged with breaking in the United States.
... do you really expect a company, whose entire goal and motive is maximizing profit, to waste their profits? Because if so this conversation is not worth continuing.
... do you really expect a company, whose entire goal and motive is maximizing profit, to waste their profits? Because if so this conversation is not worth continuing.
I don't think the Mob could have written a more devious, anti-consumer, draconian law if they'd been given free reign.
"That's some nice software you got there... be a shame if something were to... happen... to it. So, you better keep paying us for our locked-down content, and don't even think about trying to pick those locks. Or else."
Of course they'll be more likely to not be sued if they take it down, but again: the process they used is wrong. They are playing this as if youtube-dl were a copyright violation, which it isn't. They are saying youtube-dl has a right (and needs to) file a counter-notice to have itself be reinstated, which it doesn't.
The Title II provisions are irrelevant, as they do not cover circumvention devices. The RIAA could sue them regardless of whether they comply or not.
DMCA takedowns do not need to be from the copyright holder themselves. They can be from ANY authorized agent of the copyright holder, like a lawyer, or ... the rights-enforcement association to which the copyright holder belongs.
ETA: And yes, if you submitted a DMCA takedown which has any reasonable chance (from the recipient/provider's perspective) of being valid, it would get taken down. Otherwise, the provider takes on their customer's liability. Very few (and zero free) providers are willing to do so.
>> Some people think RIAA’s DMCA notice is not legally valid, arguing RIAA is not the copyright holder and there is no infringing material.
> DMCA takedowns do not need to be from the copyright holder themselves. They can be from ANY authorized agent of the copyright holder
I think it's clear that "RIAA is not the copyright holder" is shorthand for "no member of the RIAA is the copyright holder". Even if you don't accept that, you can easily deduce that no member of the RIAA is the copyright holder by looking at the immediately following claim, "there is no infringing material".
Given that there is no infringing material, it can't really matter whose agent the RIAA purports to be.
The youtube-dl DMCA notice does not allege copyright infringement (section 512 of the DMCA) but rather breaking DRM (section 1201 of the DMCA). Arguing that there is no [copyright-]infringing material is completely missing the point.
jfrunyon's comment is an accurate statement of the law, and reflects what the EFF, a legal organization that specializes in IP and tech-related areas of the law, has posted.
OTOH, your comment violates a number of HN rules and probably should be deleted for dang kills your account for a few days.
BTW, they also did allege infringing material. Whether or not that material's copyright is in fact infringed upon by youtube-dl is not for GitHub to decide. (And, in my non-lawyer opinion, a US court would probably say it is, if this ever makes it that far.)
> The clear purpose of this source code is to ... reproduce and distribute music videos and sound recordings owned by our member companies without authorization for such use. ... We also note that the source code prominently includes as sample uses of the source code the downloading of copies of our members’ copyrighted sound recordings and music videos, as noted in Exhibit A hereto. For example, as shown on Exhibit A, the source code expressly suggests its use to copy and/or distribute the following copyrighted works owned by our member companies: • Icona Pop – I Love It (feat. Charli XCX) [Official Video], owned by Warner Music Group • Justin Timberlake – Tunnel Vision (Explicit), owned by Sony Music Group • Taylor Swift – Shake it Off, owned/exclusively licensed by Universal Music Group
The copyright holders can be harmed by actions other than direct copyright infringement. In particular, the law recognizes DRM circumvention as a harm. Other commenters had already covered this aspect before I made my comment, so I'm unsure why you expect me to cover it again.
Well, it's very similar to many other real situations like common household doors. They provide a weak level of protection and we add laws that criminalize getting unauthorized entry.
I'm sometimes baffled that people miss that point when it comes to internet security. The biggest real difference is the global nature of the internet and thus problems with jurisdiction, which obviously doesn't apply if both sides reside in the same jurisdiction.
This particular protection mechanism is bypassed by all browsers when they access the content. Are browsers infringing too?
Clearly what is most important is the intent. In this case, it is very clearly RIAA's intent to make the aforementioned videos obtainable publicly via the use of HTTP agents. Browsers are HTTP agents. youtube-dl is an HTTP agent. Either they are all infringing or they are all not infringing.
On the other hand, it is clearly the intent of my door and lock to keep people out.
You're absolutely right. From my non-lawyer understanding that's why the youtube-dl dmca mainly rests on youtube-dl showing illicit use within their code (download of copyright protected material) and not that the tool is theoretically capable. But it's indeed a slippery road.
There are other examples in the real world tho, where the distribution/creation of the tool is already illegal (e.g. certain weapons or explosives), because only reacting after damage is done is infeasible.
Not necessarily. Public domain and fair use don't require distribution to
occur. Ex: Photos taken in the 1890s are public domain, and you may know that they exist (having seen a print in a no-photography-allowed museum), but the owner of the only copy of the photo is under no obligation to distribute them.
Lets tackle explosives:
Where public interest exists for legitimate use, they are allowed: mining, fireworks, and hobby rockets. And there is real risk of grevious bodilly harm associated, even if used properly - we are not even considering terrorism.
There is massive legitimate use for downloading videos, yet the alleged harm is purely monetary.
With Microsoft's resources they could easily ignore the DMCA takedown and battle it out in the courts. But Microsoft is a paying member of the RIAA soooooooo
Why would Microsoft stand up to a DMCA takedown from any organization to a random github repo that they can't immediately tell is being wrongly taken down? Unless you pay GitHub the legal fees, no organization would lift a finger.
Under the common law, actual possession is seen as prima facie evidence of ownership — i.e., possession creates a presumption of ownership, but that presumption is rebuttable.
The U.S. Court of Appeals for the Fourth Circuit in 2006 begins a discussion of possession with:
"That possession is nine-tenths of the law is a truism hardly bearing repetition. Statements to this effect have existed almost as long as the common law itself."
Willcox v. Stroup, 467 F.3d 409, 412 (4th Cir. 2006).
It doesn’t mean whoever possesses something is automatically the owner. It means that absent evidence of superior title, possession generally suffices to show ownership.
> Some people think RIAA’s DMCA notice is not legally valid, arguing RIAA is not the copyright holder and there is no infringing material.
That doesn't make the notice facially invalid, if they have made the required representations (which they have, as they have alleged specific infringement of their works on a contributory infringement theory as well as alleging that the works in question violated DMCA anticircumvention provisions, and particularly alleging that the combination of the anticircumvention violation plus the specific identification of works of RIAA-represented owners as targets was the basis for the contributory infringement claim.)
Unless Github wants to expose itself to both upfront costs and potential liability by judging the details of the legal theories and fact claims in facially-valid DMCA takedown notices, it makes sense for them to react to facially-valid notices and wait for a facially-valid counter-notice before restoring user content.
(IANAL) It doesn't matter if people think RIAA's DMCA isn't legally valid (or even if it isn't actually valid), Github still has to follow section 512 of the DMCA as a service provider, and it's not their responsibility to determine validity of the claim. RIAA is a 3rd party authorized to act on behalf of the copyright holder, so they are allowed to send a DMCA takedown. Also the takedown is claiming DMCA section 1201, which is for bypassing DRM, not distributing infringing material.
tl;dr there probably isn't anything inherently wrong with the RIAA's claim, and there's definitely nothing wrong with github's response.
As for DMCAing an oil producer's repository for something unrelated to DMCA, github would still take it down, but it's quite likely that you'd end up with a lawsuit from the oil company for damages. As long as GitHub is run by a US company, it doesn't matter how advocating they are of open source, nothing would change...they'd still take down the repository after receiving a DMCA takedown request.
And the last point, my understanding is apple wasn't actually required to assist the FBI, but american companies are required to follow DMCA.
Microsoft is an enterprise software company that suckles at the teat of government invoicing to the tune of tens of billions of dollars, they are nothing like Apple in this regard.
If youtube-dl disagrees with the takedown, they need to take it up with the RIAA. If the RIAA - or a judge - decides in favor of youtube-dl, Github can restore the repository.
This is how things work; it may not be how you'd like things to work, but I doubt you've ever been involved in any part of a DMCA takedown request (as the sender, receiver, or the person that had their stuff taken down).
You break your own ToS and DMCA policies by banning users who repost youtube-dl code. You potentially also lose your safe harbor restrictions in the process.
Let's pretend for the moment that the original youtube-dl DMCA had been valid, or that you removed youtube-dl due to an innocuous mistake. If I post youtube-dl to MY account, you have NO reason to take it down until you receive another takedown request from the RIAA for my repo. You certainly have no reason to ban users. There is nothing in your ToS which this violates.
I work on education projects which use youtube-dl in legal, non-infringing ways. I don't think the RIAA has a legal leg to stand on for reasons I'm not going to get to in this post.
Until github starts following DMCA processes properly, I CANNOT respond to the existing takedown request, since I have no standing. It's not my repo.
The right course of action for me would be to:
(1) Consult my lawyer and figure out if this is a fight I want to pick. I'm pretty sure I'd win in court if this went all the way, but I might go bankrupt first.
(2) Post youtube-dl to my repo.
(3) Wait for a DMCA takedown notice.
(4) Respond to it with a counternotice, and litigate with the RIAA.
Because github has decided to act as an arbiter on behalf of the RIAA, rather than a neutral third party, I cannot follow this process. github short-circuits this process at #2 by threatening to remove the repo and ban my account.
I'm sorry that you've chosen to side with the RIAA against the Internet. I'm gradually moving my business to gitlab. This is approximately what people thought would happen as a result of the Microsoft purchase.
You break your own ToS and DMCA policies by banning users who repost youtube-dl code.
You need to re-read the Github TOS, because this is absolutely covered by it already (see Section F of their TOS).
You potentially also lose your safe harbor restrictions in the process.
That is false. They could lose their safe harbor if they did not respond to a presumptively valid DMCA notice.
Until github starts following DMCA processes properly, I CANNOT respond to the existing takedown request, since I have no standing. It's not my repo.
Pretty sure that the Legal Dept at Github knows more about the DMCA process than a random non-lawyer on HN. It's something they deal with on a regular basis.
Because github has decided to act as an arbiter on behalf of the RIAA, rather than a neutral third party, I cannot follow this process. github short-circuits this process at #2 by threatening to remove the repo and ban my account.
This is false.
Because github has decided to act as an arbiter on behalf of the RIAA, rather than a neutral third party, I cannot follow this process. github short-circuits this process at #2 by threatening to remove the repo and ban my account.
That is probably for the best. Customers with unrealistic expectations are not worth the effort to keep.
> You need to re-read the Github TOS, because this is absolutely covered by it already (see Section F of their TOS).
Section F says they can take down RIAA's account, not mine. Here is the section in full: "If you believe that content on our website violates your copyright, please contact us in accordance with our Digital Millennium Copyright Act Policy. If you are a copyright owner and you believe that content on GitHub violates your rights, please contact us via our convenient DMCA form or by emailing copyright@github.com. There may be legal consequences for sending a false or frivolous takedown notice. Before sending a takedown request, you must consider legal uses such as fair use and licensed uses. We will terminate the Accounts of repeat infringers of this policy."
> That is false. They could lose their safe harbor if they did not respond to a presumptively valid DMCA notice.
Had it been a valid DMCA notice, the required response under the DMCA is taking down the youtube-dl repo.
Their thermonuclear bomb was to take down other people's repos, ban accounts, and make random threats.
> Pretty sure that the Legal Dept at Github knows more about the DMCA process than a random non-lawyer on HN. It's something they deal with on a regular basis.
I'm pretty sure they do too, which is why their aggressive and technological legal response, combined with their CEO making public statements of sympathy for their victims, is so cynical, dirty, and dishonest.
They can be the good guy, and fight the RIAA. They can be a neutral party, and do their duty under DMCA. But fighting the RIAAs battles for then, and then making comments like Nat's? Sketchy and sleazy.
Even eighties/nineties Microsoft didn't do that. They went after people, but they were at least open about what they were doing -- they called Linux a virus and all sorts of other nasty things. They didn't pretend to like Linux while spreading FUD and mounting legal attacks.
On the other hand, I'm pretty sure the other random guy on the internet (you) doesn't know more than the first random guy on the internet (me).
> That is probably for the best. Customers with unrealistic expectations are not worth the effort to keep.
Depends on the cost, the context, and how those expectations manifest. Talk to any luxury good company serving the ultrawealthy for how not catering to customers with unreasonable expectations would serve them. Or any company selling to an athlete to promote a product. Or many small businesses who just won multimillion dollar B2B contracts. Or...
But in either case, I don't think expecting github to act honestly is an unrealistic expectation. Each time I've dealt with a dishonest company, no matter how good the deal looked, I came out behind. I think people were holding their breath to see what happens with github post-acquisition, and we just learned.
I love it when non-lawyers misread legal documents.
The TOS says that Github will take down the offending content (or if, necessary, account), not the copyright owner's account. Most copyright owners do not have Github accounts. Github is not a thing people use outside of programming.
Their thermonuclear bomb was to take down other people's repos, ban accounts, and make random threats.
This is the proper response to the petulant behavior of techies flaunting the original takedown. The end result would simply have been the RIAA issuing more requests, possibly even formal requests, which Github would have led Github to doing the same thing it did proactively.
You know why did it? To protect people from the legal consequences of their stupidity. Lawsuits are expensive, especially when you're in the wrong and the other side has a very large legal budget.
They can be the good guy, and fight the RIAA. They can be a neutral party, and do their duty under DMCA. But fighting the RIAAs battles for then, and then making comments like Nat's? Sketchy and sleazy.
Being the good guy in this situation is not fighting the RIAA. It's doing what the law requires to prevent disruption of services to their other customers, most of whom aren't opening flaunting the law.
Outside of the tech world, to the extent that people care about this conflict, they're wondering why techies are so intent on bullying non-techies just trying to protect their work. Outside of tech, people are struggling and many are unemployed. This is a PR battle that tech is losing.
> The TOS says that Github will take down the offending content (or if, necessary, account)
No. It doesn't say "offending content." It says "repeat infringers of this policy," referring to the aforementioned paragraphs.
> Github is not a thing people use outside of programming.
Which is increasingly close to zero major industries.
> The end result would simply have been the RIAA issuing more requests, possibly even formal requests, which Github would have led Github to doing the same thing it did proactively.
Exactly, and the opportunity for people with non-infringing uses, such as myself, to pick up the torch. It's a lot easier to take down youtube-dl than it is to take down obviously non-infringing educational tools used by kids to learn from home during a pandemic.
> It's doing what the law requires to prevent disruption of services to their other customers, most of whom aren't opening flaunting the law.
The law requires a very specific process. github went above and beyond that process, for no positive reason. The safe harbor provisions in DMCA hinge on being a "service provider," which is not very well defined, but the provisions were inspired by the concept of a common carrier.
If all I'm doing is hosting people's content, with no control over that, or providing bandwidth, or a caching layer, I shouldn't be liable for the actions of those people. Comcast has no liability for what I send over their network. If I run something illegal on AWS, that's not AWS' liability either. That's reasonable.
There's a fuzzy line from there to a service like github or Youtube, to a service like pip or npm, to something like the Debian package repository. If the Debian package repository, which is controlled and curated by Debian, has infringing content, Debian would almost certainly be liable.
github can be viewed as "like Comcast/AWS" or "like Debian," depending on how much control it exerts over what goes on github. Exerting more control than it absolutely needs to -- as it did in this case -- increases their liability in the long term. This shouldn't put them out of the service provider category, but a pattern of exerting control might.
I just looked over your post history. You've posted a whole bunch of posts which are both legally wrong, and show either fundamental, basic reading comprehension issues with your sources similar to the one in this thread, or you're intentionally spreading misinformation. I'm not sure which. Whatever it is, it's dangerous. You made false claims about the DMCA, github's ToS, and in other threads, about the EFF.
I'll post cites to sources, and then I'm done here.
Thanks, I needed the laugh. I love it when non-lawyers argue with me about the law because they always base their arguments on fundamental misunderstandings about what the law says or how the law works.
This whole thing makes me think of how Google goes "above and beyond" with Content ID on YouTube. Google had no legal obligation to build Content ID and preemptively take things down (and, as it turns out, way more aggressively than they legally need to be).
In the same way, it seems GitHub is preemptively telling people that if they re-post youtube-dl on GH, they'll be banned, even though GH has no legal responsibility to do so. It's really sad that they're siding with big business in all this, rather than their users, without whom they'd be nothing.
YouTube had to make Content ID because they were facing a multi-billion dollar lawsuit from Viacom. Had YouTube not been proactive, the court could have ruled that YouTube was widely used for piracy, and they’d be liable.
GitHub seems to be acting without a backbone. They’re owned by Microsoft, and can definitely stand up to legal challenges like this. Look at BitTorrent: The protocol and it’s code are legal despite being used for piracy. I don’t see why GitHub caves to every request to take down code that is clearly not violating any copyrighted material.
Also, the code itself does not break any copy protection and even if it did.. the code itself needs a user to execute it. Isn’t this how LAME was able to exist without violating mp3 patent laws?
"Suggest you read about how the DMCA works: https://docs.github.com/en/free-pro-team@latest/github/site-policy/dmca-takedown-policy"
That's how section 512 works. The RIAA letter referenced section 1201, not 512. There is no copyright infringing material to identify. The letter relates to distribution of copyright protection circumvention technology.
Maybe Github needs a new page explaining section 1201 takedowns.
Does the DMCA actually define these, or is the entire concept of a "section 1201 takedown" a courtesy GitHub is extending to rightsholders, but not legally required to provide? I am only familiar with the DMCA outlining a takedown process for copyrighted content.
Even if it did circumvent copy protection (I don’t think it does?).. the code itself needs a user to execute it. Isn’t this how LAME was able to exist without violating mp3 patent laws?
Section 1201 prohibits making circumvention technology available to others. Sharing source code, or binaries, that are "primarily designed" to circumvent copyrighted works arguably violates 1201. It is not a defense to assert that no one ever used what was shared.
An MP3 patent, such as 6,009,399, covers methods and apparatuses for encoding a digitised audio signal. Writing source code that uses a claimed method is arguably not infringment but as soon as anyone besides the patent owner or her licensees compiles the source code and tests the binary, then there is a much stronger argument that infringment has occurred.
That was their argument, but I strongly doubt it would have held up had they been sued (particularly in the US). Also, a major point they raised was that they did not distribute LAME in executable form.
What/who does the "You" in YouTube stand for. From where I sit, it never stood for RIAA members the commercial works they profit from. Recall the Time magazine "Man of the Year" cover many years ago circa the debut of YouTube. It was, IIRC, supposed to be mirror. The "you" that was named "Man of the Year" was not meant to be a RIAA member corporation. It was meant to be an ordinary, non-commercial internet user. The entertainment industry has "taken over" what I thought was a resource for non-commercial internet users to share video. Here we are seeing the resulting effects of acquiescing to that "takeover". I would guess most content on YouTube is in fact non-commercial, true to the website's original purpose, which arguably makes youtube-dl useful for non-commercial purposes. However, it seems that is not what Microsoft thinks. The (passive-aggreesive) "corporatisation" of the internet (via the web). Lame.
The non-commercial content on YouTube is decidedly not the content which is protected with the copy-protection which the RIAA is (presumably) alleging that youtube-dl circumvents.
It's frustrating because the RIAA is not just requesting that the "infringing" part of the tool is removed. They want the entire tool removed, even for the parts which there is no question of infringement. For example, the 100's of other websites that it works with.
I highly suspect that most of the industry does little due diligence to vet DMCA takedown notices in favor of automation.
Just curious, what would the effects be if one were to use multiple accounts to automate the submission of DMCA takedown notifications for all <content> hosted on <content provider>? Does <content provider> honor takedowns only from or in preference to blessed accounts? Could one DoS <content provider> in such a manner? If a human has to review all DMCA complaints, would a flood of false claims DoS the human reviewers?
> The DMCA requires that you swear to the facts in your copyright complaint under penalty of perjury. It is a federal crime to intentionally lie in a sworn declaration. (See U.S. Code, Title 18, Section 1621.) Submitting false information could also result in civil liability — that is, you could get sued for money damages. The DMCA itself provides for damages against any person who knowingly materially misrepresents that material or activity is infringing.
That's interesting; is US copyright law enforceable everywhere?
Did you mean "is perjury enforceable everywhere"? I bet the US government could get you extradited for something or other, if not, if it really wanted to. But I don't think they'd have much trouble getting you extradited (or at least punished for your country's version of perjury) for violating a law which you explicitly agreed to abide by...
Sorry, Nat, but reading that is doing nothing much to restore the goodwill that has been eroded by this whole affair.
The DMCA works in much the way that its authors, the telcos and the MPAA and RIAA intended it to. To indemnify ISP's in return for their becoming enforcers for rights-holders ridiculously over-broad "anti-circumvention" clauses[0] which lead to outrageous abuses of the law (including anti-trust violations, attacks on the rights of consumers, academics, etc).
Now, Microsoft's lobbying machinery must have been in its infancy back then so the blame can't entirely be laid at their feet. But Microsoft don't seem to be doing anything to help either.
Fundamental to the problem is that youtube-dl (and many others) seem to be obvious candidates for exceptions to DMCA 1201. But the process around those exceptions seems not be working at all. Something which Microsoft appears completely tone-deaf and oblivious to[1].
So, with respect, I suggest you... get a grip to how you guys are going to be being perceived in this situation.
Nat, it wasn't even a DMCA claim. It was missing key components which distinguish a DMCA claim from a grumpy threatening letter. The only valid response was a blog post to shame the RIAA. Instead, shame has been brought upon github. Yall don't even read threatening letters before taking stuff offline?
There is a way forward, Nat. You can reinstate that repo today, and tell the RIAA that they cannot use your online tool. They have to send your legal representation (in Alaska to slow it down) a certified, hand-signed letter through snail mail. Make a big public show of this process, and get public mindshare on your side.
Yep, but the article linked to by the ceo discusses section 501 which applies to copyright infringements. The riaa doesn't (that I'm aware of) have a copyright on anything in youtube-dl's repo.
A question about your DMCA policy – the 10-14 day wait before you restore access in case of a DMCA counter-notice, is that mandated by the DMCA or is that just your own policy?
It seems to me that this could be used to cause a lot of damage – target a popular open source project with a totally bogus DMCA notice, even if they instantly file a counternotice they still get made unavailable for 10+ days.
(Also, why 10-14 days? Why not just 10 days or just 14 days?)
>Assuming the takedown notice is sufficiently detailed according to the statutory requirements (as explained in the how-to guide), we will post the notice to our public repository and pass the link along to the affected user.
I think many would argue that the takedown notice wasn't "sufficiently detailed", especially when you consider the 1201 vs 512 issue.
>With potential damages multiplied across millions of users, cloud-computing and user-generated content sites like YouTube, Facebook, or GitHub probably never would have existed without the DMCA (or at least not without passing some of that cost downstream to their users).
Thanks, Nat, for standing up for the “know it all” trolls on Hacker News. For some reason, kids who can code think they’re legal experts, too. And they feel they don’t have to be polite.
Or maybe he published it himself to divert from the DMCA bad press? :)
I am going to believe that. Github CEO wanted a reason to open source it, and used a rogue leak in a win-win situation.
Why he didn't sign it to prove it was him? because the desktop client doesn't even have this basic git feature implemented ¯\_(ツ)_/¯ ...and everyone knows managers only uses GUI, Q.E.D.
I don’t think this is correct. I follow them on twitter and there’s almost nothing to indicate they even know what’s happening with youtube-dl: https://twitter.com/natfriedman
Wait... so after years of multiple security researchers including me privately and publicly demoing this issue, it took us virally trolling you with it before you would finally acknowledge it is an issue and try to fix? Why does it always come to this.
By the way the serious design flaw where GitHub forges signatures on merge commits I told you about when you joined as CEO... Still not fixed.
The fact a commit can be shown as "verified" in the interface when I didn't sign it with my Yubikey is totally broken.
> we recommend people sign their commits and look for the 'verified' label on GitHub to ensure that things are as they appear to be.
One issue is that you are loading profile images and creating links based on unverified emails (if I click the little picture next to the commit message I get to the impersonated profile). I mean I get that a proper solution might introduce unacceptable friction, but you can't really blame users for misunderstandings in the current state either.
They have a grey unverified thing that pops up if there was an error when using GPG to sign the commit, I wonder why it doesn’t show up the rest of the time when you don’t sign something at all.
You don't have to pressure them to remove a page. I remember that all you needed to do was add a line to your robots.txt to have a page excluded, and you can also just request to have a page excluded (that you own).
Thanks for the response here Nat. Upfront and to the point. Now that most of the code is out there, will you consider making the whole project Open Source?
I can see your PR staff in my head, standing behind your monitor and saying: "now you have to write everything is in order, everything is normal, this is not a bug but a feature".
It also contains linting config, ci workflows, dockerfiles, and other build related files that you probably wouldn't put in an "un-stripped/obfuscated tarball of our GitHub Enterprise Server source code"
> The docs include information about how dotcom developers and code are organized, for example getting started, process and philosophy, and tech stack.
The readme seems clearly aimed towards developers of GitHub.com
Being downvoted bc of why? I literally said THE MOST obvious purposefully and left out the 20+ other things that a good security researcher would hunt down in this - each to allow compromise of the company, build process, downstream or someone using enterprise.
I am not advocating it - I am making people aware that is what leaks mean.
[I randomly picked 20. Because it's usually a lot of options when you have source code access]
Your comment amounts to "Github's security team should be making sure the dependencies in their Gemfile don't have vulnerabilities". Which is an obvious and pointless statement, yes, of course github's security team should make sure github's code doesn't have vulnerabilities. That's the most important duty of their job.
The fact that the Gemfile has been leaked changes nothing about what the security team should be doing.
Your comment doesn't really contribute to discussion because it's not presenting novel information, and it's misleading because, per the reasons above, their security team's priorities goals/responsibilities/behaviors/etc aren't really impacted by this, and your comment sorta implies otherwise.
Good discussion - I respectfully disagree. It increases downstream risk to GH enterprise, and means the risk flows to security team setup at on-prem clients, whom often have no security team - or a few security engineers possibly. And they're looking at lots of things besides on-prem solutions.
That's what I was getting at. It means this list - has more avenues & more options for on-prem risk. For someone who has internal network access to lateral subnet (small example). Because one who chose to can start analyzing methods for privileged code access. CISOs would want to add additional review of the surrounding on-prem network and hardware. Just my thoughts.
I still don't understand what you're suggesting a couple comments up. You said "They need to protect their Gemfile". What did you mean by "protect their gemfile"? It's already out there.
> It increases downstream risk to GH enterprise
I disagree with that. People have been able to de-obfuscate and read github enterprise's source code for pretty much as long as github enterprise has existed. Researching security vulnerabilities in it is not really any different.
> Because one who chose to can start analyzing methods for privileged code access.
As above, people already could do this; the deobfuscated GHE code is pretty easy to get your hands on. And the chance of there being a remotely exploitable vuln that exfiltrates code or gives you an admin account.. well, that seems to remain at "pretty unlikely".
If this were to logically follow, than no one would run Gitlab, an open source equivalent, because the source code is available for people to "analyze methods". However, I have a similar level of respect for github and gitlab's security teams, and I tend to think the security of both of them is pretty decent, irrespective of whether the code is leaked, open source, or proprietary.
> CISOs would want to add additional review
I also disagree with that understanding. A CISO in the past would have already decided "We trust github's security practices enough to run GHE here and put our code in it." The fact that the code has leaked changes that not-a-wit. The CISO still trusts github's security practices, and those practices haven't changed.
I've now realized I need to be less obfuscating in my suggestions on HN. Literal appears to be the only way. I was suggesting around the corners for people to begin connecting further dots.
Why does GitHub add PRs into repository as new commits even before author adds a merge commit rather than doing a usual multi-remote non-FF merge when merge action gets triggered?
git downfall is the "smart" features that prevent people from understanding what git really is.
Instead of making conflict messages clearer and easier to work with using local files, contributors keep thinking the users are too dumb and adding (and changing) merge resolution hacks.
This boils up to github, as can be seen by teams who do not understand the very basic about git commits, and enable "squash commits by default" on their repos. With these teams, git commit history cease to be bit sized changes in a larger changeset, and become useless displays of the author interacting with the remote server while they upload small changes to tests to make the continuous builds get green.
I understand how this user made themself look like you, but I don't understand how they were able to push a commit to the github/dmca repo. Wouldn't that require them to be a collaborator on the repo?
They made a fork of the dmca repository, and pushed the commit to their fork.
But Github uses the same single Git repository for all forks, and they have an issue where you can access a branch/commit of a fork from the main repository if you know its hash. They should probably fix that at some point.
> Github uses the same single Git repository for all forks
Ah I see, thanks for the explanation. I didn't know this was the case. I thought each fork would have its own `.git` folder. Seems like this approach could allow forkers to mess with the original repo, but maybe Git is designed in a way that this is mostly safe.
> The year's at the spring
> And day's at the morn;
> Morning's at seven;
> The hill-side's dew-pearled;
> The lark's on the wing;
> The snail's on the thorn;
> God's in His heaven—
> All's right with the world!
What? Git absolutely makes it trivial to impersonate commits. All you have to do is change some Git config settings. Or, export your commit into a patch/email file (git format-patch), modify it, and then import it (git am). Or, set some environment variables (GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL). etc.
As you yourself mentioned, very, very, very few projects/people sign their commits. Even fewer actually verify them.
Sign with GPG for the hash, as linked. The methods you mentioned do allow malicious modification. Signing the commit with a public key makes it a lot more difficult.
In the same vein, one can spoof email - but DKIM, SPF, DMARC together as controls make it much more difficult.
Again, as you yourself mentioned, very, very, very few projects/people sign their commits. Even fewer actually verify them. That has nothing to do with how easy Git makes it to impersonate commits. In fact, whether you sign or not, you can still easily impersonate commits with any Git tool unless the person on the other end actively verifies the signature. (Which GitHub makes much easier than git, since they also maintain & automatically check a verified mapping of email -> GPG key, instead of you having to somehow get the key and then make sure it's the right one and then explicitly tell git to verify the signature)
I am well aware that you can sign commits with Git. I do, personally and professionally, and my coworkers and I are required to, by policy that I wrote. That has absolutely no bearing on the topic at hand even tangentially.
Their UI is far better at it than the git tool itself. You have to explicitly tell git to check signatures (not to mention needing to go get people's keys and verify that they're correct, which GitHub does for you).
@natfriedman - you guys need to start allowing comments in Git commits, it will help enrich Git commits with any other tracking information available. Hopefully it's helpful.
Nat while you are here addressing this related issue, any thoughts on changing Github's handling of commits by users who later can't be tracked down to directly address removal or changes of various viral license schemes your platform supports and promotes for use?
That is a legal/copyright issue of each project; if you are concerned about that you should requiere a CAA/CLA though this is not legal advice and I am not a lawyer, consult with one for the specifics.
I won't be applying any type of Open Source license to any code I am writing but people should definitely consider getting each and every developer to agree to identifying themselves legally so they can be contacted in the case of license changes.
You "hacked" yourself. A majority of commits are not "verified", and a majority of users don't know to "look for" the verified label. Why didn't you make signing mandatory if you recommend it?
As for repercussions to your mismanagement, I will certainly stay tuned.
Because the vast majority of their users don't want (or need, really) to bother with setting up GPG, making a key, adding their key to their account, etc.
Also, if users don't know the very basics of how Git works, they probably shouldn't be using it, and certainly not trusting it.
Nobody is talking about your "personal git" (I assume you mean your personal git repository). We are talking about two software programs: git, and GitHub. Both are ABSOLUTELY used by millions of people.
There are ways to monetize open source. GitHub could make the repository/PR code open source and host the repo management/hooks/actions/etc code for enterprise.
Github is a company not a community project though, they don't gain anything by going open source, it makes no sense to do so.
There are hidden costs to going open source as well as expected ones. Could you imagine the number of PRs, issues and discussions over trivial shit the GitHub userbase would create against an open GH repo? Nightmare. Not to mention code cleanliness expectations and buildability expectations and so on.
Of course they "could do this" or "do it that way," but the fact that they don't should tell you their priorities lie elsewhere, and that's fine. Closed source isn't evil and we have other open source git hosting platforms.
It is good software. We run all of dev + CI/CD off of it as well as a lot of product management. It is better than Github in terms of features and flexibility and most importantly it isn't JIRA!
All is not right with the world. The GitHub code is still closed source. You need to open the source code of GitHub up Nat. Open it up. Do the right thing.
GitHub hasn't been hacked. We accidentally shipped an un-stripped/obfuscated tarball of our GitHub Enterprise Server source code to some customers a couple of months ago. It shares code with github.com. As others have pointed out, much of GitHub is written in Ruby.
Git makes it trivial to impersonate unsigned commits, so we recommend people sign their commits and look for the 'verified' label on GitHub to ensure that things are as they appear to be.
As for repo impersonation – stay tuned, we are going to make it much more obvious when you're viewing an orphaned commit.
In summary: everything is fine, situation normal, the lark is on the wing, the snail is on the thorn, and all's right with the world.