Developer Licensing Restrictions and Exclusion Risks

1. Introduction

Developer licensing restrictions are contractual, technical, or commercial conditions imposed by a platform, operating-system provider, software vendor, API provider, cloud provider, app store, or other ecosystem controller on developers who wish to build, distribute, integrate, or monetize software within that ecosystem.

Such restrictions are often legitimate. A platform may need rules concerning security, privacy, interoperability, intellectual property, quality control, malware prevention, consumer protection, payment processing, or technical compatibility. The competition-law concern arises when licensing conditions are used not merely to protect the ecosystem but to exclude rival developers, competing platforms, complementary products, or alternative distribution channels.

The central competition question is therefore not simply whether a licensing restriction exists, but whether the restriction materially forecloses competition and whether its justification is proportionate to the legitimate objective pursued.

2. What Constitutes a Developer Licensing Restriction?

Developer licensing restrictions can take several forms:

A. Access restrictions

A platform may require developers to obtain approval before accessing:

• APIs;
• software development kits;
• operating-system functions;
• app stores;
• developer tools;
• payment systems;
• cloud infrastructure;
• hardware interfaces.

B. Distribution restrictions

Developers may be prohibited from:

• distributing applications outside an approved store;
• using alternative app stores;
• linking to alternative payment systems;
• distributing competing software through an application;
• offering alternative marketplaces.

C. Technology restrictions

Licences may prohibit:

• reverse engineering;
• interoperability tools;
• alternative APIs;
• access to undocumented functionality;
• competing middleware;
• interoperability with competing systems.

D. Commercial restrictions

A platform may impose:

• mandatory payment processing;
• commissions;
• minimum fees;
• revenue-sharing requirements;
• restrictions on subscription models;
• restrictions on advertising.

E. Competitive-use restrictions

Particularly important are provisions preventing developers from:

• developing competing products;
• supporting rival platforms;
• using competing APIs;
• migrating customers to competing ecosystems;
• offering cross-platform functionality.

3. Why Licensing Restrictions Can Create Exclusion Risks

Licensing becomes particularly important where the licensor controls an essential ecosystem gateway.

For example:

Dominant operating system → developer licence → API access → application distribution → consumer access.

If developers cannot realistically reach consumers without accepting the dominant platform's licence, contractual restrictions can have effects substantially beyond an ordinary copyright or technology licence.

The economic concern may be described as:

Platform control → contractual restriction → reduced developer freedom → foreclosure of rivals → reduced interoperability → increased switching costs → ecosystem reinforcement.

4. Relevant Competition-Law Theories

A. Abuse of dominance

Under Article 102 TFEU-type principles and analogous national laws, licensing restrictions imposed by a dominant undertaking may constitute abusive exclusion where they:

1. are imposed by a dominant undertaking;
2. concern an economically significant input or ecosystem;
3. restrict access or competitive conduct;
4. have actual or potential foreclosure effects; and
5. lack sufficient objective justification or proportionality.

The restriction does not automatically become unlawful merely because the firm is dominant.

B. Exclusive dealing

A developer licence can effectively operate as an exclusivity arrangement where developers receive access to important infrastructure only on condition that they:

• do not support rivals;
• use the platform's distribution channel exclusively;
• use the platform's payment system;
• refrain from interoperating with competing systems.

The legal assessment generally focuses on the foreclosure effect, duration, coverage, market power and availability of alternatives.

C. Refusal to supply or provide access

Where a developer depends upon a dominant API, platform or technical interface, denial of access may raise refusal-to-supply or essential-facility-type questions.

The difficulty is that competition law normally does not require firms to share every proprietary technology with competitors.

The stronger case arises where the restricted input is indispensable and refusal substantially eliminates effective competition.

D. Tying

A platform may condition access to one product on acceptance of another product or service.

For developers this can arise where:

Operating-system access → mandatory payment system

or

Developer distribution → mandatory platform advertising/payment/API service.

E. Interoperability foreclosure

Licensing restrictions can prevent competitors from making their products compatible with the dominant ecosystem.

This is particularly significant in:

• cloud computing;
• mobile operating systems;
• enterprise software;
• gaming;
• AI platforms;
• cybersecurity;
• developer tools.

5. Major Case Laws

1. United States v. Microsoft Corp. — 253 F.3d 34 (D.C. Cir. 2001)

This is one of the foundational cases for understanding licensing restrictions as an exclusionary mechanism.

Microsoft possessed monopoly power in the market for Intel-compatible PC operating systems. Its conduct concerning Internet Explorer and competing middleware, including Java, was examined as part of a broader strategy to prevent competing middleware from weakening the Windows platform's position.

The court considered Microsoft's contractual arrangements with software developers and other industry participants. Microsoft used various agreements and technical arrangements that affected the ability of competing technologies to gain distribution.

The case is particularly relevant because licensing and contractual arrangements were evaluated according to their competitive effect rather than simply according to their formal contractual character.

The DOJ's description of the case specifically identifies Microsoft's restrictions affecting OEMs, ISVs and Java as mechanisms that foreclosed substantial distribution of rival middleware.

Principle

A dominant platform cannot necessarily use contractual arrangements with developers and distributors to protect its monopoly from a technological threat.

Relevance

Developer licensing restrictions become problematic when they:

• prevent developers from supporting competing middleware;
• reduce rival distribution;
• protect an existing platform monopoly;
• raise barriers to technological substitution.

6. United States v. Microsoft — Final Judgment

The remedies imposed against Microsoft provide an especially useful illustration of how competition authorities can address developer ecosystem restrictions.

The final judgment restricted Microsoft from taking action against ISVs and IHVs based on their decision to develop, use, distribute or promote competing software. It also addressed Microsoft's ability to use licensing terms, discounts, technical support and developer programs as competitive weapons.

Principle

A dominant platform's control over:

• licensing;
• technical information;
• developer support;
• certification;
• marketing assistance;
• developer tools

can itself become an important competitive lever.

Relevance

A developer ecosystem can be foreclosed without formally prohibiting competition. Selective access to technical support or licensing advantages can produce similar exclusionary effects.

7. Epic Games, Inc. v. Apple Inc.

The Apple litigation is one of the clearest modern examples of developer licensing restrictions.

Apple's Developer Program Licensing Agreement governed developers' access to iOS distribution. The litigation concerned, among other things:

• App Store distribution;
• mandatory in-app payment processing;
• restrictions on communications concerning alternative payment mechanisms.

The Ninth Circuit's 2023 decision recorded that developers were required to accept Apple's Developer Program Licensing Agreement to distribute iOS applications.

The district court rejected Epic's federal antitrust challenges to Apple's App Store distribution and in-app-payment restrictions, while finding Apple's anti-steering restriction unlawful under California's Unfair Competition Law and issuing an injunction.

The Ninth Circuit affirmed the principal judgment in 2023.

Principle

A developer licence can simultaneously perform several functions:

permission to enter ecosystem + technical access + distribution access + commercial conditions.

That makes the competitive analysis more complicated than ordinary licensing.

Exclusion risk

A licensing provision may raise concerns where it prevents developers from:

• communicating alternative purchasing methods;
• establishing competing distribution channels;
• using alternative payment systems;
• creating competing ecosystem infrastructure.

8. Epic Games v. Apple — Later Enforcement Proceedings

The Apple litigation subsequently generated further proceedings concerning compliance with the injunction.

In 2025, the Ninth Circuit addressed Apple's implementation of the injunction concerning external purchasing links. The court upheld findings of civil contempt relating to restrictions imposed on developers' external purchasing links, although it modified aspects of the sanctions.

The case illustrates an important point:

A formally available alternative may have little competitive value if contractual or technical conditions make its practical use commercially unattractive.

The court considered, among other things, Apple's restrictions on the design and use of external purchasing links.

9. Epic Games v. Google LLC

The Google litigation provides another major example.

Epic challenged Google's Android app-distribution and billing practices. Following a jury trial, the Ninth Circuit reported that the jury found Google violated federal and state antitrust laws in markets involving Android app distribution and Android in-app billing services. The appellate court upheld the resulting injunction.

Significance

The case demonstrates that developer restrictions can become competition concerns where a platform combines:

• operating-system control;
• app-store control;
• billing infrastructure;
• contractual developer conditions.

Competition concern

If developers cannot practically reach consumers without using the dominant distribution or billing infrastructure, restrictions imposed through developer agreements can have ecosystem-wide foreclosure effects.

10. UsedSoft GmbH v Oracle International Corp — Case C-128/11

The CJEU's UsedSoft v Oracle decision is principally a software copyright and exhaustion case, but it has significant implications for software licensing restrictions.

The court addressed the circumstances in which the distribution right in computer-program copies becomes exhausted following a transaction involving software supplied by download and an unlimited period of use.

The case is relevant because it demonstrates that the contractual characterization of a software transaction as a "licence" does not necessarily determine its legal economic character.

This principle becomes important when software providers attempt to use licensing structures to control secondary markets or downstream use.

The continuing significance of UsedSoft is evident in later litigation concerning software licensing restrictions, including the 2026 English Court of Appeal litigation involving Microsoft and second-hand software licences.

11. UsedSoft and Microsoft/ValueLicensing

In JJH Enterprises Ltd (t/a ValueLicensing) v Microsoft Corporation & Ors [2026] EWCA Civ 872, the English Court of Appeal considered allegations concerning Microsoft's restrictions on the supply of second-hand licences and movement from perpetual licences toward subscription models.

The litigation specifically identified competition-law allegations under Articles 101 and 102 TFEU and corresponding provisions, while copyright exhaustion under UsedSoft v Oracle was central to the legal analysis.

Relevance

The case illustrates a broader competition-law issue:

licensing model → control over downstream transfer → reduced secondary-market access → potential competitive foreclosure.

This can be especially important where customers are heavily dependent upon a particular software ecosystem.

12. European Commission / Microsoft Interoperability Context

The broader Microsoft competition-law history also demonstrates the importance of interoperability.

The Microsoft proceedings concerned Microsoft's relationship with competing middleware and the ability of rival technologies to function effectively within the Windows environment.

The underlying concern was not simply ownership of software IP. It was the interaction between:

• operating-system dominance;
• technical interoperability;
• developer relationships;
• licensing arrangements;
• distribution;
• competitive entry.

The Microsoft remedies consequently addressed the use of developer relations, technical information and licensing terms as instruments capable of affecting competition.

13. Emerging UK Relevance: Microsoft's Business Software Ecosystem

The issue is particularly current in the UK.

In May 2026, the UK's Competition and Markets Authority opened an investigation into Microsoft's business software ecosystem as part of an investigation into whether Microsoft should be designated as having Strategic Market Status under the Digital Markets, Competition and Consumers Act 2024.

The CMA stated that its investigation includes examination of customer purchasing decisions, alternatives to Microsoft and customers' ability to switch.

This is significant because modern competition analysis increasingly examines an entire software ecosystem, rather than evaluating each software licence in isolation.

14. Categories of Exclusion Risks

A. Competitor foreclosure

A platform may prevent developers from supporting competing platforms.

Example:

"You may use our SDK only if your application does not support competing operating systems."

This can reduce the ability of rivals to achieve scale.

B. Distribution foreclosure

A dominant platform may prevent developers from distributing applications through alternative channels.

This can produce:

Developer dependency → distribution dependency → platform dependency.

The Apple litigation provides a major example of this type of dispute.

C. Payment-system foreclosure

A platform may require developers to use its payment infrastructure.

The competitive effect can involve:

• transaction commissions;
• reduced payment innovation;
• reduced ability to negotiate;
• reduced alternative payment adoption.

D. API foreclosure

A dominant platform may provide its own developers with superior API access while:

• restricting rivals;
• degrading interoperability;
• withholding documentation;
• limiting technical permissions.

The legal question is whether the differentiation has a legitimate technical basis or instead protects the platform's competitive position.

E. Cross-platform development restrictions

Licences may restrict developers from:

• creating Android and iOS versions simultaneously;
• supporting competing cloud platforms;
• integrating rival APIs;
• creating interoperable services.

Such restrictions may be particularly problematic where the dominant platform controls access to a large installed base.

15. Objective Justifications

Not every developer restriction is anticompetitive.

Platforms have legitimate reasons for imposing licensing requirements.

Security

Restrictions may prevent:

• malware;
• malicious code;
• credential theft;
• system exploitation.

Privacy

Developers may be restricted from accessing sensitive data.

Technical integrity

A platform may need to prevent APIs from being used in ways that destabilize the system.

Consumer protection

App-store review and licensing conditions may prevent fraudulent or unsafe applications.

Intellectual property

Restrictions may protect proprietary software and copyrighted technologies.

Quality assurance

Platforms may impose minimum standards for developers.

Therefore:

Legitimate technical restrictions should be distinguished from restrictions whose principal competitive effect is exclusion.

Apple's developer agreement, for example, contains restrictions concerning undocumented APIs, executable code, security mechanisms and application functionality, demonstrating that developer restrictions can have genuine technical and security purposes.

16. Proportionality and Less Restrictive Alternatives

A central analytical question is:

Could the legitimate objective be achieved through a less restrictive licensing condition?

For example:

Restriction

"Developers may not use alternative payment systems."

Possible justification

Security and fraud prevention.

Competition analysis

Could the same objective instead be achieved through:

• certification requirements;
• security audits;
• standardized APIs;
• disclosure requirements;
• technical compliance tests?

If yes, an authority may scrutinize whether a complete prohibition is unnecessarily restrictive.

This does not mean that a less restrictive alternative must always be adopted. It means that the availability and feasibility of alternatives can be important evidence in assessing competitive effects and justification.

17. Network Effects and Developer Lock-In

Developer licensing restrictions become more powerful in markets characterized by network effects.

The cycle may look like:

More users

↓

More developers

↓

More applications

↓

More users

↓

Greater platform attractiveness

↓

Greater developer dependence

Once this cycle develops, a licensing restriction can reinforce existing market power.

A competing platform may technically exist but still be unable to obtain sufficient developers and users to compete effectively.

18. Switching Costs

Licensing restrictions can also increase switching costs.

A developer may have invested heavily in:

• proprietary APIs;
• SDKs;
• development tools;
• certification;
• testing infrastructure;
• platform-specific code;
• customer relationships;
• payment integration.

Consequently, leaving the ecosystem may require substantial redevelopment.

A dominant platform may therefore obtain ecosystem-level leverage even without expressly prohibiting switching.

19. Developer Dependency

The strongest exclusion risks often arise where the developer has no realistic substitute.

A useful analytical model is:

Developer dependence =

importance of platform access
× lack of alternatives
× switching costs
× platform market power.

Where all four are high, licensing restrictions deserve particularly close competition-law scrutiny.

20. Contractual Discrimination

Another concern is discriminatory licensing.

A platform could provide:

Differential treatment is not automatically unlawful.

The crucial questions include:

• Are the differences objectively justified?
• Do they disadvantage competitors?
• Does the platform favour its own downstream service?
• Does the discrimination foreclose effective competition?

21. Self-Preferencing Through Licensing

Licensing can become a mechanism for vertical self-preferencing.

For example:

Platform owns operating system

Platform owns competing application

Platform controls developer licence

=

Platform may possess the ability to impose conditions on independent developers while exempting its own applications.

This can raise competition concerns involving:

• self-preferencing;
• discriminatory access;
• foreclosure;
• tying;
• leveraging.

22. AI and Modern Developer Ecosystems

The issue is increasingly important for AI platforms.

Consider:

Foundation model

→ API licence

→ developer application

→ cloud infrastructure

→ distribution marketplace.

An AI provider could potentially impose restrictions concerning:

• competing models;
• model switching;
• API interoperability;
• model fine-tuning;
• synthetic-data generation;
• competing inference providers;
• model routing;
• use of alternative cloud infrastructure.

The competitive significance depends upon the provider's market position and the practical effect of the restriction.

A contractual ban affecting a small developer in a competitive market is fundamentally different from a restriction imposed by a dominant AI infrastructure provider controlling an indispensable model or API.

23. Cloud Developer Ecosystems

Cloud licensing creates similar risks.

A cloud provider may offer:

• computing;
• storage;
• databases;
• identity management;
• developer tools;
• AI services;
• application marketplaces.

If contractual terms make it difficult to migrate applications to rival clouds, competition concerns may arise around:

• data portability;
• interoperability;
• egress restrictions;
• technical compatibility;
• marketplace access;
• contractual termination conditions.

24. Competition-Law Test

A useful analytical framework is:

Step 1 — Identify the relevant ecosystem

Determine whether the restriction concerns:

• operating system;
• app store;
• cloud;
• API;
• developer tools;
• payment system;
• software marketplace.

Step 2 — Identify market power

Ask:

• Is the platform dominant?
• Is it an important gateway?
• Are alternatives realistically available?

Step 3 — Identify the restriction

Determine whether the licence contains:

• exclusivity;
• non-compete clauses;
• distribution restrictions;
• payment restrictions;
• interoperability restrictions;
• API restrictions.

Step 4 — Determine foreclosure

Assess whether developers or competing providers are actually or potentially excluded.

Step 5 — Examine duration and coverage

A restriction covering 2% of developers may have a different effect from one covering 80%.

Step 6 — Consider switching costs

Ask how difficult it is for developers to move to another platform.

Step 7 — Examine objective justification

Identify legitimate:

• security;
• privacy;
• technical;
• consumer-protection;
• IP objectives.

Step 8 — Examine proportionality

Could the same objective be achieved by a less restrictive measure?

Step 9 — Assess consumer effects

Consider:

• prices;
• innovation;
• application variety;
• quality;
• privacy;
• security;
• consumer choice.

Step 10 — Consider remedy

Possible remedies may include:

• removal of exclusivity;
• interoperability obligations;
• non-discrimination;
• access requirements;
• prohibition of retaliatory conduct;
• alternative payment access;
• API access;
• transparency requirements.

25. Distinguishing Legitimate Licensing From Exclusionary Licensing

The same contractual provision can therefore have very different legal implications depending upon purpose, market power, design and competitive effects.

26. Key Case-Law Principles

27. Overall Legal Significance

Developer licensing restrictions sit at the intersection of contract law, intellectual-property law, platform regulation and competition law.

The key distinction is:

A platform may ordinarily determine reasonable conditions for using its technology, but market power can make those contractual conditions economically significant instruments of exclusion.

The greatest competition risks arise when:

1. the platform has substantial market power;
2. developers depend upon access to its ecosystem;
3. switching costs are high;
4. alternative distribution channels are weak;
5. the licence restricts interoperability or multi-homing;
6. the platform competes downstream with the developers it regulates; and
7. the restriction lacks a convincing objective justification or goes beyond what is reasonably necessary.

The modern cases involving Microsoft, Apple and Google demonstrate that competition authorities and courts increasingly examine the practical operation of the entire developer ecosystem rather than treating licensing provisions as isolated private contracts. The contemporary UK investigation into Microsoft's business software ecosystem similarly illustrates the growing regulatory emphasis on ecosystem dependency and switching.

Conclusion

Developer licensing restrictions are not inherently unlawful. They can be essential for security, privacy, intellectual-property protection, technical integrity and consumer protection. The competition-law problem arises when a powerful ecosystem controller uses licensing conditions to foreclose rival developers, restrict interoperability, prevent alternative distribution or payment channels, discriminate against competing products, or increase developer dependency.