Well sovereign citizen argument is just plain stupid; “I live on your soil but your laws don’t apply to me because I say so.”
Here, youtube is claiming something specific (that Invidious violates a TOS agreement which Invidious agreed to) which is verifiably false - Invidious never agreed to the TOS for the API, and doesn’t have to, because Invidious doesn’t use the API. Invidious works by communicating with YouTube and scraping data from the responses. There’s legal precedent that this is legal (although, LinkedIn’s ongoing battle with HiQ may overturn that precedent, but it hasn’t yet). That’s one of the reasons that most services like youtube offer an affordable API in the first place - 3rd party tools using web scraping is much more expensive for them.
YouTube could still potentially legally force them to stop by changing the TOS of the service itself, but there could be other implications of that, so we’ll see what happens. As FOSS, it’s unclear what they would even do, there are hundreds of hosts.
That explanation is the most amount of nonsense I’ve read in a long time. The amount of mental gymnastics you need to non-ironically believe that is just unbelievable
i’d appreciate it if, for outsiders, you could explain why it’s “the most amount of nonsense” and “mental gymnastics” in actual detail instead of just saying that. as is, this is a very unproductive comment.
Because of course Invidious calls YouTube APIs. They call the internal APIs the same way YouTube official client calls the API. They even have the API Key of one of YouTube client’s in their repo. The guy’s argument is that since they reverse engineered the calls, which is fine, they don’t have to agree to YouTube’s TOS to call it, which means YouTube’s cease and desist invalid. I host my own private instance of Invidious to stream youtube audio to my phone. Of course reverse engineering is fine, scarping is fine, even the code is fine, and I’d agree that YouTube going after repos on github is wrong. But of course hosting Invidious is a violation of YouTube’s TOS.
I’ll admit I hadn’t seen that, and that I was just echoing what TheFrenchGhosty said. That sure does look like official API access. They also seem to make calls through that wrapper to access comments and plenty of other things, so it’s not just sitting there unused.
The README and the refute of YouTube’s C&D letter both claim that Invidious doesn’t use YouTube’s APIs at all - not merely that the response creation/interpretation was reverse-engineered. Obviously, the TOS applies to the fact that you interact with the API, not whether you access it manually or with the help of some code pre-prepared by Google. Yet it seems that other people have vetted you and not raised this issue. So I’m assuming we’re simply misunderstanding here, and hoping you can clear it up.
The thing is that the agreement they linked apply to the official YouTube API (the one that you have to register for).
Invidious uses the InnerTube (a completely different “API” used by all official YouTube clients). Invidious basically acts like a web browser that access the YouTube website. It is therefore not required to agree to any TOS/policies.
All those findings where done via clean room reverse engineering (which is legal in the EU).
That makes Invidious’ readme (which claims no YouTube APIs at all) disingenuous at the very least.
More likely, you need a lawyer. I read that TOS, and I think it applies to any YouTube API endpoint, internal or otherwise. Best of luck, because I agree with Invidious’ goals…
Side note: a browser communicating with YouTube would be communicating with youtube. Not with com.google.android.youtube.api or whatever. What I’m seeing is that Invidious tries to act like the youtube service itself, which is very different from acting like a browser.
Edit: I’ve spent about 5 minutes looking for EU case law about this but haven’t been able to find anything except un-cited references to an exception for “producing interoperable devices.” Do you have sources? In the United States, at least, “clean room reverse engineering” has a pretty specific definition that follows four steps:
A (team of) engineers reverse-engineers an existing product, in this case, the YouTube internal API.
Those engineers write a specification of the product’s (outwardly-visible) behavior.
A lawyer reviews that specification to ensure that it does not contain anything infringing on any copyrights relevant to the product.
A separate (team of) engineers re-implement the product according to the specification.
I don’t think what you’re doing meets that definition. You achieved step 1, and possibly step 2, and then didn’t attempt the others. You reverse engineered something for the purpose of using it - but you haven’t actually reimplemented it, which is the “clean room” part of “clean room reverse engineering.” Re-implementing it would presumably require building your own server for actually hosting videos on Invidious instances.
There’s quite a history of this term in the US, going back to even before Intel vs. NEC, when it was very much in the public eye. NEC had designed a microprocessor with the same instruction set as the popular Intel 8080 [same instruction set = interoperability]. Internally, both devices use “microcode” to drive their execution. In the analogy, that microcode is the “InnerTube” API. NEC’s “V20” device was quite different from the 8080, and needed its own microcode. Intel claimed that NEC violated Intel’s copyright by basing NEC’s microcode on the 8080’s. As part of arguing this, NEC rewrote their microcode from scratch following proper cleanroom procedure, and the decision in the case partly relies on this to decide that NEC is in the clear. Had NEC simply injected the 8080 microcode into their NEC-V20 device directly, the case would probably have gone very differently. It would also be a very different case, because the NEC-V20 device would look completely different.
You didn’t re-implement InnerTube. You injected InnerTube into your own service. Had you re-implemented InnerTube as part of Invidious, Invidious would look completely different.
Anyway, all that aside, even if what you’re doing did meet the conditions of clean-room reverse engineering, I don’t think it would fall under the (again, un-cited, so maybe we’re talking about different things) interoperability exception in the EU. You’re not producing a device/service that needs to be interoperable with other devices/services. You’re producing a service with an explicit goal of operating differently.
To be clear, IANAL, but your reasoning seems shaky.
well, there was a long thread about this on /r/selfhosted where @TheFrenchGhosty@lemmy.pussthecat.org@TheFrenchGhosty@libretooth.gr was saying pretty much what I said, but with a tad more mental gymnastics mostly about EU laws regarding reverse engineering and lack of a formal agreement between them and YouTube.
Unfortunately (or fortunately?), /r/selfhosted is private atm due to the blackout, so I’m unable to find and share thread link.
The facts are:
Invidious (as an OSS project) calls undocumented internal YouTube APIs (they call it InnerTube).
Anyone can host an Invidious instance.
The main Invidious instance, i.e: https://invidious.io/ received a cease and desist from YouTube.
@TheFrenchGhosty@lemmy.pussthecat.org@TheFrenchGhosty@libretooth.gr posted all about this on GitHub, reddit, their personal blog, and contacted random media outlets like the one linked here, to complain about how “we have nothing to do with YouTube, why is YouTube bullying us”. And since everyone obviously wants to give the little guy the benefit of the doubt, everyone starts wondering how it could be that a project that’s all about providing an alternative UI for YouTube, doesn’t call YouTube.
It’s like if a movie pirating website is trying to argue
“Endgame.mp4” is just a file name. It has nothing to do with Marvel or Disney. What the hell are those greedy companies have to do with us??
I’m all for invidious, piracy, etc. But seriously?
It’s certainly possible to scrape data from interactions with a site directly, without using its API. This is even legal - there were no gymnastics in my response there. However, that decision has since been remanded, then re-affirmed, then challenged, and then LinkedIn obtained an injuction against HiQ which the two of them are still fighting over. So it could get properly overturned.
I definitely thought it seemed like it would be difficult to do this to offer a youtube frontend, but plausible enough that I didn’t look into it. Thank you for this. I’m looking more closely now :)
If they are using undocumented internal APIs, do YouTube’s API TOS apply to those? I checked the text of the TOS and it seems to me like it should apply; they say “The YouTube API services … made available by YouTube including …”. That seems broad enough to me to cover internal APIs as well, if their endpoints are accessible, but IANAL.
Also, the open response to the C&D seems to throw shade at the TOS saying “The “YouTube API Services” means (i) the YouTube API services” but ignores that this is immediately followed by parenthetical examples and qualifiers. The TOS is defining the term so that it doesn’t have to repeatedly add the qualifiers. Nothing weird about that. That’s uh… pretty bad-faith arguing, if I’m interpreting it correctly.
Edit: assuming you refer to the same reverse engineering points that they made above… yeah.
They’ve (convincingly) followed up above. I’m hoping the contributors to Invidious can clear this up. If no one replies here, I’ll open an issue on Invidious’ GitHub page asking that clarification be added to the readme on how their YoutubeAPI wrapper is not using an official YouTube API.
I love the explanation about why he (TheFrenchGhosty) won’t stop working on the project: https://blog.thefrenchghosty.me/posts/im-not-invidious/
This really is the next era of the web, after the tech bubble just can’t get enough money, people are taking it in their own hands again.
That strongly feels like the tone of those “sovereign citizens”, feels as legally flimsy as a soap bubble
Well sovereign citizen argument is just plain stupid; “I live on your soil but your laws don’t apply to me because I say so.”
Here, youtube is claiming something specific (that Invidious violates a TOS agreement which Invidious agreed to) which is verifiably false - Invidious never agreed to the TOS for the API, and doesn’t have to, because Invidious doesn’t use the API. Invidious works by communicating with YouTube and scraping data from the responses. There’s legal precedent that this is legal (although, LinkedIn’s ongoing battle with HiQ may overturn that precedent, but it hasn’t yet). That’s one of the reasons that most services like youtube offer an affordable API in the first place - 3rd party tools using web scraping is much more expensive for them.
YouTube could still potentially legally force them to stop by changing the TOS of the service itself, but there could be other implications of that, so we’ll see what happens. As FOSS, it’s unclear what they would even do, there are hundreds of hosts.
That explanation is the most amount of nonsense I’ve read in a long time. The amount of mental gymnastics you need to non-ironically believe that is just unbelievable
i’d appreciate it if, for outsiders, you could explain why it’s “the most amount of nonsense” and “mental gymnastics” in actual detail instead of just saying that. as is, this is a very unproductive comment.
Because of course Invidious calls YouTube APIs. They call the internal APIs the same way YouTube official client calls the API. They even have the API Key of one of YouTube client’s in their repo. The guy’s argument is that since they reverse engineered the calls, which is fine, they don’t have to agree to YouTube’s TOS to call it, which means YouTube’s cease and desist invalid. I host my own private instance of Invidious to stream youtube audio to my phone. Of course reverse engineering is fine, scarping is fine, even the code is fine, and I’d agree that YouTube going after repos on github is wrong. But of course hosting Invidious is a violation of YouTube’s TOS.
I’ll admit I hadn’t seen that, and that I was just echoing what TheFrenchGhosty said. That sure does look like official API access. They also seem to make calls through that wrapper to access comments and plenty of other things, so it’s not just sitting there unused.
Thankfully, TheFrenchGhosty is on the Fediverse, so let’s ask them: @TheFrenchGhosty@lemmy.pussthecat.org @TheFrenchGhosty@libretooth.gr (not sure which one of these to use) How is this not using an official YouTube API?
The README and the refute of YouTube’s C&D letter both claim that Invidious doesn’t use YouTube’s APIs at all - not merely that the response creation/interpretation was reverse-engineered. Obviously, the TOS applies to the fact that you interact with the API, not whether you access it manually or with the help of some code pre-prepared by Google. Yet it seems that other people have vetted you and not raised this issue. So I’m assuming we’re simply misunderstanding here, and hoping you can clear it up.
Hello,
The thing is that the agreement they linked apply to the official YouTube API (the one that you have to register for).
Invidious uses the InnerTube (a completely different “API” used by all official YouTube clients). Invidious basically acts like a web browser that access the YouTube website. It is therefore not required to agree to any TOS/policies.
All those findings where done via clean room reverse engineering (which is legal in the EU).
That makes Invidious’ readme (which claims no YouTube APIs at all) disingenuous at the very least.
More likely, you need a lawyer. I read that TOS, and I think it applies to any YouTube API endpoint, internal or otherwise. Best of luck, because I agree with Invidious’ goals…
Side note: a browser communicating with YouTube would be communicating with youtube. Not with com.google.android.youtube.api or whatever. What I’m seeing is that Invidious tries to act like the youtube service itself, which is very different from acting like a browser.
Edit: I’ve spent about 5 minutes looking for EU case law about this but haven’t been able to find anything except un-cited references to an exception for “producing interoperable devices.” Do you have sources? In the United States, at least, “clean room reverse engineering” has a pretty specific definition that follows four steps:
I don’t think what you’re doing meets that definition. You achieved step 1, and possibly step 2, and then didn’t attempt the others. You reverse engineered something for the purpose of using it - but you haven’t actually reimplemented it, which is the “clean room” part of “clean room reverse engineering.” Re-implementing it would presumably require building your own server for actually hosting videos on Invidious instances.
There’s quite a history of this term in the US, going back to even before Intel vs. NEC, when it was very much in the public eye. NEC had designed a microprocessor with the same instruction set as the popular Intel 8080 [same instruction set = interoperability]. Internally, both devices use “microcode” to drive their execution. In the analogy, that microcode is the “InnerTube” API. NEC’s “V20” device was quite different from the 8080, and needed its own microcode. Intel claimed that NEC violated Intel’s copyright by basing NEC’s microcode on the 8080’s. As part of arguing this, NEC rewrote their microcode from scratch following proper cleanroom procedure, and the decision in the case partly relies on this to decide that NEC is in the clear. Had NEC simply injected the 8080 microcode into their NEC-V20 device directly, the case would probably have gone very differently. It would also be a very different case, because the NEC-V20 device would look completely different.
You didn’t re-implement InnerTube. You injected InnerTube into your own service. Had you re-implemented InnerTube as part of Invidious, Invidious would look completely different.
Anyway, all that aside, even if what you’re doing did meet the conditions of clean-room reverse engineering, I don’t think it would fall under the (again, un-cited, so maybe we’re talking about different things) interoperability exception in the EU. You’re not producing a device/service that needs to be interoperable with other devices/services. You’re producing a service with an explicit goal of operating differently.
To be clear, IANAL, but your reasoning seems shaky.
well, there was a long thread about this on /r/selfhosted where @TheFrenchGhosty@lemmy.pussthecat.org @TheFrenchGhosty@libretooth.gr was saying pretty much what I said, but with a tad more mental gymnastics mostly about EU laws regarding reverse engineering and lack of a formal agreement between them and YouTube.
Unfortunately (or fortunately?), /r/selfhosted is private atm due to the blackout, so I’m unable to find and share thread link.
The facts are:
@TheFrenchGhosty@lemmy.pussthecat.org @TheFrenchGhosty@libretooth.gr posted all about this on GitHub, reddit, their personal blog, and contacted random media outlets like the one linked here, to complain about how “we have nothing to do with YouTube, why is YouTube bullying us”. And since everyone obviously wants to give the little guy the benefit of the doubt, everyone starts wondering how it could be that a project that’s all about providing an alternative UI for YouTube, doesn’t call YouTube.
It’s like if a movie pirating website is trying to argue
I’m all for invidious, piracy, etc. But seriously?
Gday matey. The difference with Invidious and endgame.mp4, is that invidious doesnt host anything, its merely a proxy.
It’s certainly possible to scrape data from interactions with a site directly, without using its API. This is even legal - there were no gymnastics in my response there. However, that decision has since been remanded, then re-affirmed, then challenged, and then LinkedIn obtained an injuction against HiQ which the two of them are still fighting over. So it could get properly overturned.
I definitely thought it seemed like it would be difficult to do this to offer a youtube frontend, but plausible enough that I didn’t look into it. Thank you for this. I’m looking more closely now :)
If they are using undocumented internal APIs, do YouTube’s API TOS apply to those? I checked the text of the TOS and it seems to me like it should apply; they say “The YouTube API services … made available by YouTube including …”. That seems broad enough to me to cover internal APIs as well, if their endpoints are accessible, but IANAL.
Also, the open response to the C&D seems to throw shade at the TOS saying “The “YouTube API Services” means (i) the YouTube API services” but ignores that this is immediately followed by parenthetical examples and qualifiers. The TOS is defining the term so that it doesn’t have to repeatedly add the qualifiers. Nothing weird about that. That’s uh… pretty bad-faith arguing, if I’m interpreting it correctly.
Edit: assuming you refer to the same reverse engineering points that they made above… yeah.
You can’t say something that profound and leave us on a cliffhanger… Ellaborate a bit please?
They’ve (convincingly) followed up above. I’m hoping the contributors to Invidious can clear this up. If no one replies here, I’ll open an issue on Invidious’ GitHub page asking that clarification be added to the readme on how their YoutubeAPI wrapper is not using an official YouTube API.
Ooh thanks for the reply, I wouldn’t have known otherwise!