I think you have narrowed it down with what our core disagreement might circulate around.
But that’s the thing it’s a question regarding the software being deployed are enacted by the user. How will you argue that the software developer is violating IP rights when they are at no time violating said rights.
Even if we assume some of your points are correct, your overall interpretation still doesn’t hold water under EU law and leads to legal paradoxes nobody wants.
Let’s take your strongest claims as given:
- Apple’s APIs and libraries are fully protected copyrighted works (even though SAS v. WPL clearly ruled APIs and functionality aren’t copyrightable).
- Any invocation of those APIs by a developer’s app counts as “use” of Apple’s IP that requires a license.
- Apple’s platform restrictions are justified under Article 6 or similar provisions.
How can a developer infringe Apple’s IP when all software execution happens on the user’s device, under their control? Even if we assume Apple’s APIs and libraries are fully copyrighted, and calling them requires a license, your view still fails under EU law.
Directive 2009/24/EC Article 4 grants exclusive rights over reproduction, adaptation, and distribution—but Article 5 allows lawful users to run software and make temporary copies as needed. If calling APIs counted as infringement, these exceptions would be nullified, which contradicts the directive’s purpose.
This is critical: if a user has lawfully acquired the device(as has already been established as a purchase and transfer of ownership)(with iOS and its libraries), then execution of iOS APIs on that device including when invoked by third-party apps are permitted without further authorization. This is settled EU law. The lawful acquirer (the device owner) has rights that are not extinguished just because a developer’s code triggers preinstalled APIs.
When they install a third-party app that calls Apple’s libraries, it’s the user, not the developer, who’s actually “using” Apple’s code.
You're misundestanding and misinterpreting the law.
Article 5 says
users have the right to run lawfully acquired software and make temporary copies, but that right doesn’t automatically extend to developers who build commercial apps that rely on invoking Apple’s proprietary libraries. Developers aren’t just passive beneficiaries of user rights, they’re
actively creating software that depends on and exploits protected platform code.
When a developer writes code that calls Apple’s APIs, they are reproducing and functionally adapting Apple’s software—an act covered by Article 4 and still subject to licensing. The fact that the code executes on the user’s device doesn’t shield the developer from needing permission to use Apple’s IP. Apple’s SDKs, headers, and libraries are protected works, and using them in a commercial product requires more than user possession—it requires a license from the rights holder.
Remember, in the Nintendo case, the consoles were legally acquired. And yet the court ruled Nintendo could block the mod chips from being sold,
even if they had legitimate uses. How do you square the circle? The consoles were legally purchased.
2. Misunderstanding of Exhaustion and Lawful Use
The claim that apps invokes Apple’s IP (even if preinstalled), the developer must get a license. But this misreads how copyright exhaustion and user rights work in EU software law.
Distribution right is exhausted once Apple sells the device with iOS and libraries preinstalled. The buyer (end user) is now a lawful acquirer.
What the developer does is provide code that interacts with the user’s device. The developer is not distributing iOS or Apple’s IP; they’re distributing code that expects certain OS features to be present.
It’s akin to writing a Word macro, you’re using MS Word’s runtime behavior, but you’re not copying Word.
As a lawful acquirer of iOS and the iPhone , the user has the right to run and execute that software (Article 5(1)). So when they install a third-party app that calls Apple’s libraries, the actual use of Apple’s code is by the user, not the developer.
The developer does not reproduce or distribute Apple’s code
Your interpretation conflates calling a library with copying or distributing that library. The developer’s binary is their own code and does not contain Apple’s code. Apple’s software is already on the device. EU law requires reproduction or distribution to infringe copyright (Article 4). None of that happens here.
If API invocation were infringement, everyday software development would be illegal
Your theory would mean the moment I run software on any device I would invoke copyright infringement by proxy of the software developer.
And This logic would impose indirect liability on developers for lawful user behavior Developers would be indirectly liable whenever users execute apps that call into preinstalled system libraries.
That would create a bizarre strict liability regime, where lawful user behavior (running software) causes third-party copyright infringement by proxy. That’s a form of copyright by proxy that EU law does not recognize.
So even if we assume that Apple’s APIs and libraries are fully protected IP (which they arguably aren’t, per SAS Institute), the C-159/23
Sony v Datel confirms that using those APIs at runtime is not an infringing act by the developer.
In other words, your position that developers must have a license simply to call Apple’s system libraries fails under this ruling. It rejects any theory that runtime use or invocation is equivalent to reproduction or distribution.
If Apple really wanted to control this, they’d have to prohibit users themselves from running apps that call these libraries, which of course they can’t do because the user owns the device and software copy as a legally purchased product.
Again, I think you are misunderstanding and misinterpreting how the law works.
First,
user rights under Article 5 don’t extend to third-party developers. Article 5(1) allows
the lawful acquirer to run software and make temporary copies, but that covers the user, not a developer who builds and distributes code that relies on and calls proprietary platform libraries. Developers aren’t just writing neutral code, they’re building commercial products that depend on and execute Apple’s protected software at runtime.
Second, invoking APIs isn’t like writing a Word macro. A macro is executed within a licensed app the user has opened. But apps on iOS link to Apple’s protected libraries at runtime. That’s a technical act of reproduction (even if temporary), and under Article 4(1)(a) reproduction requires the rights holder’s permission es,pecially when the developer knows and intends that the code will rely on Apple’s IP to function.
Third, copyright exhaustion only applies to the distribution right. It doesn’t exhaust the rights to control reproduction or adaptation, which are the rights at issue when a developer creates an app that invokes Apple’s libraries. Just because the code runs on the user’s device doesn’t mean the developer isn’t leveraging Apple’s IP.
Finally, Sony v. Datel (C-159/23) doesn’t say what you claim it does. That case focused on compatibility and anti-circumvention, not on whether invoking protected libraries at runtime requires a license. It didn’t overturn
Nintendo v. PC Box, which, again, confirmed that platform owners can restrict unlicensed software access through TPMs (if your theory was correct, they wouldn't have ruled that was legal) and that executing platform code without authorization can still infringe rights, even if it’s initiated by the user.
Under your theory of how this all works, any developer could freely build commercial software that calls into proprietary platforms like Photoshop or MS Office, so long as the end user owns a legal copy. You could sell an app that depends on Adobe Photoshop’s internal libraries to render or manipulate images, without ever licensing Adobe’s SDKs, because the app “just runs on the user’s machine.” You could build and sell tools that programmatically call into Microsoft Office’s internal APIs, because “the user owns Office.” This logic would let any developer feely commercialize and exploit someone else’s protected software, without permission, as long as they avoided bundling the target’s code. That’s not how IP law works, in the EU or anywhere else. IP protection isn’t nullified just because the user has a legitimately acquired copy.
If we accept their legal interpretation of how copyright and licensing obligations would apply
that triggering preinstalled code on a user-owned device is a copyright infringement, then every developer needs a license from Microsoft, Google, or Canonical just to call standard OS functions. Scripting a print job on Windows or accessing a camera API on Android would be unlawful without explicit permission from the OS vendor.
The fact the user is independently using the software would mean all modern software development is illegal unless pre-cleared by platform holders, turning runtime interaction into de facto copyright infringement. And every software developer would be under legal obligation to acquire a license to every single platform to protect themselves from any users who might deploy their software unlawfully an violate the copyright
You're conflating public APIs on open platforms (like Windows, Android, Linux) with proprietary SDKs tied to closed ecosystems like iOS. Microsoft and Google
explicitly license their APIs under clear developer terms, developers agree to those licenses when using the SDKs. That’s how lawful use is granted. They
have given explicit permission.
But Apple’s iOS APIs and tools are not freely licensed or open by default. They’re available only under Apple’s Developer Agreement, which includes terms about App Store distribution, payment, and use of proprietary frameworks. If you sidestep those terms but still write code that relies on Apple’s proprietary libraries, you’re not just interacting with public infrastructure you’re leveraging protected IP without a license.
This doesn’t mean all development requires individualized licenses for every OS. It means that you need a license when your code relies on protected, non-public platform software that isn’t freely licensed for general use. That’s true in the EU and everywhere else.