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 over an hour 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.
“Valid” and “disingenuous” mean very different things. How would you feel about editing that README point to be explicit that you use an unofficialundocumented YouTube API?
For the record, I don’t think “InnerTube” would be considered unofficial, legally. It’s authorized by YouTube, since they made and use it internally. That’s the definition of “official.” This is a small part of why I think the wording in the TOS makes the TOS apply to “InnerTube.” What makes you think that it doesn’t?
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 minutesover an hour 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.
The InnerTube isn’t the YouTube API, far from it. So it’s still valid.
“Valid” and “disingenuous” mean very different things. How would you feel about editing that README point to be explicit that you use an
unofficialundocumented YouTube API?For the record, I don’t think “InnerTube” would be considered unofficial, legally. It’s authorized by YouTube, since they made and use it internally. That’s the definition of “official.” This is a small part of why I think the wording in the TOS makes the TOS apply to “InnerTube.” What makes you think that it doesn’t?
The fact that it isn’t “the YouTube API”. The policy only applies to the API you can get “officially”.