this post was submitted on 10 Jun 2023
26 points (100.0% liked)
Technology
37551 readers
302 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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. As part of arguing that case, NEC, following this procedure, produced a clean-room re-implementation of Intel's popular 8008 microprocessor's microcode. To do that, they had to re-write all of the microcode from scratch. Not figure out how to inject the 8008's microcode into their own hardware design.
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 ~~unofficial~~ undocumented 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".