It’s a fair question IMO. The YouTube APIs presumable come with “terms of service” for use, or some such. What exactly, legally speaking, can they specify? Can it be enforced (by Google lawyers and courts) to the point where Apple would be compelled to do things to force users to comply, like removing this App?
I think the answer _should_ be no, but that’s different to asking what is your actual rights on your device vs their “right” to control use of their system.
He isn't even using YouTube's APIs. From the dev himself:
> I’ve said from the initial launch, Juno is built as a web-wrapper for YouTube, akin to a browser extension, and purposefully built with full respect for the YouTube website and experience, and as a result does not block ads in any capacity, nor does it introduce extra functionality like downloading videos offline that could facilitate that. Further, Juno doesn’t even use any YouTube APIs, as it has no need to: it just wraps the website, and uses CSS and JavaScript to style the website and functionality more in line with visionOS. This is in contrast to other third-party tools that for instance scrape the YouTube website for applicable video URLs and use those directly, or those that integrate ad-blocking functionality.
If you separate out "how should things be" from "how things are", then from duke-nukem levels to you name it, caselaw is very clear that they can control this through fairly simple copyright law principles (derivative works, etc), without even having to resort to more complex theories.
Your best argument is fair use, but it's not a particularly good fair use argument in this case.
This isn't even a close case.
Your only secondary argument is antitrust but it seems like a really weak one in this case as well.
Not that you're under any obligation to suffer the peanut gallery, but I'm curious as to how it is that Micro Star v. FormGen (which I assume is your Duke Nukem reference) obviously applies more readily here than Galoob v. Nintendo and Sega v. Accolade. As far as I can tell, the key distinctions are in how permanent the derivative works are and to what extent the erstwhile infringement is forced by the platform owner as a condition of interoperability, which seem like they're debatable questions for third-party client apps.
Granted, maybe the DMCA makes these distinctions practically moot because a service can get away with just applying arbitrary restrictions via a "technological measure" now.
(too lazy to look up the resolution, but thought you might find it amusing)
So this is a totally reasonable question/debate to have.
I'll mix practical and academic views, but happy to discuss more of one or the other in detail.
The first answer I can give you is single-purpose apps/things have faired quite poorly in the copyright realm, any principled caselaw/etc aside. It just turns out to be really hard to convince a judge/jury (to the degree there are any fact specific questions) that an app you made with a specific purpose of displaying someone else's content, whose entire value is in displaying that content, is not a derived work of that content. It fits fairly squarely in the definition: "A “derivative work” is a work based upon one or more preexisting works, .... [in] any other form in which a work may be recast".
But even to the degree it doesn't end up a derivative work, it almost certainly ends up a distribution or reproduction or public performance the other work. So as a defense attorney trying to defend it, you have a pretty hard non-infringement argument simply because you have to simultaneously argue "it's not a derivative work, it's not a distribution, it's not a reproduction, it's not a public performance"
The line does get fuzzy somewhere, obviously - but one thing to keep in mind on that front is that derivative works are not like a single-parent-only structure. Something can be a derivative work of multiple works simultaneously :)
They usually are. This app is a derivative work of apple's libraries/frameworks, LLVM libraries or whatever it was compiled with, etc.
I also expect you'd agree that if someone copied the HTML/etc of youtube's website into the app and shipped it directly, it would a derivative work of that too. That is a clear transformation/adaption of an existing work.
So what's the practical difference here? That it's dynamically loaded and then modified? that seems like a hard place to hang your hat :)
Now mind you, i've actually made this argument before in the LGPL context, so i have taken both sides before depending on the facts/complexities :)
As an example, if i make a book, and there is no text on the pages, instead each page says something like "for the text of this page, please see characters <x>-<y> of page <a>-<b> of book <c>-<d>, ISBN number <e>", is my book a derivative work of the works it references?
it has no text or content on its own, and is only incorporating by reference.
There are reasonable arguments on both sides.
All that said, the practical line that gets drawn, for better/worse, is often around usually who is the agent/controller, and what dependencies exist.
IE it usually end up like this:
Me loading HN in a normal web browser - i'm creating a derivative work of the HN site in my browser, on my display. The web browser, shipped alone, not a derivative work of HN.
Me using an HN app that downloaded all of HN and updates it once a week on its own - the app is a derivative work of HN, and it's creative derivative works of the content on a regular basis. i'm using/ browsing these derivative works.
Here we are somewhat in the middle, but given the entire point of the app, who is doing the loading/modification, and the actual modification of content/styling, i think it falls a lot more on the latter side than the former.
At least for derivative works.
These days, to you other point, it rarely gets to the question of derivative works at all due to TOS/DMCA enforcement. You don't have a right to access the content at all except to the degree you are licensed to, app or not. Rather than argue about derivation, they'll just sue you for unauthorized reproduction or distribution, since that is more clear.
