Open Source Licenses in Your App Can Create Legal Risk

Open-Source License Compliance in Mobile Binaries

You added a library for image processing. That library depends on a compression module. That compression module links against a fork of FFmpeg. And FFmpeg is licensed under LGPL, which comes with distribution obligations you probably haven't met.

This isn't hypothetical. It's one of the most common ways open-source license violations end up in mobile app binaries. The developer who added the image library didn't know about the transitive dependency. The developer who wrote the image library didn't realize their compression module pulled in LGPL code. Nobody intended to violate a license. But the compiled binary contains the code, and the license applies regardless of intent.

This post discusses license compliance patterns. It's not legal advice. For specific obligations related to your app and its dependencies, consult qualified legal counsel.

How do copyleft licenses end up in your binary?

Most mobile developers stick to permissive licenses: MIT, Apache 2.0, BSD. These licenses allow you to include the code in commercial, closed-source apps with minimal obligations (typically attribution in your notices file).

Copyleft licenses like GPL and LGPL are different. They require that derivative works also be made available under the same license. For GPL, this can mean your entire app needs to be open-sourced if you statically link against GPL code. For LGPL, the obligations are narrower but still real.

The problem is transitive dependencies. Your Podfile, build.gradle, or Package.swift lists the libraries you chose. But each of those libraries has its own dependencies, and those dependencies have dependencies. Three levels deep, you might find code with a license you'd never intentionally use.

Common paths for copyleft code to enter your binary:

• Media processing: FFmpeg (LGPL by default, GPL with optional components) and x264 (GPL) are widely used in video processing pipelines
• Database engines: Some SQLite forks and extensions add GPL-licensed features on top of SQLite's public domain core
• Compression libraries: zlib is permissive, but alternative compression libraries sometimes aren't
• Networking: Some HTTP parsing and TLS libraries carry copyleft terms
• Image manipulation: Libraries wrapping ImageMagick or GraphicsMagick inherit their licensing

What are the actual obligations?

Not all open-source licenses are the same. Here's a quick reference for how common licenses affect mobile app binaries:

License	Commercial Use	Source Disclosure	Static Linking Risk	Mobile Binary Impact
MIT	Permitted	Not required	None	Safe, include license text
BSD (2/3-clause)	Permitted	Not required	None	Safe, include license text
Apache 2.0	Permitted	Not required (notice needed)	None	Safe, keep NOTICE file
LGPL 2.1/3.0	Permitted	Required for modifications	High if statically linked	Must allow relinking
GPL 2.0/3.0	Permitted	Required for entire work	Very high	Entire app must be GPL
AGPL 3.0	Permitted	Required, even for network use	Very high	Rarely used in mobile

Here's what each means in practice:

MIT and BSD

Include the license text and copyright notice somewhere accessible. Most apps handle this with a third-party notices screen or a file in the app bundle. Minimal friction.

Apache 2.0

Same as MIT/BSD, plus you need to include the NOTICE file if one exists. You also get a patent grant, which is why many corporate open-source projects prefer Apache 2.0.

LGPL

You can use LGPL-licensed code in a closed-source app, but you must allow users to replace the LGPL component with a modified version. For dynamically linked libraries, this is straightforward. For statically linked code in a mobile app binary, it's complicated.

On iOS, static linking is the norm. Apple's App Store doesn't allow dynamically loaded code (see guideline 2.5.2). This creates a tension: LGPL expects the ability to swap out the library, but Apple's platform doesn't allow it. Some legal interpretations consider this a violation. Others argue that providing object files for relinking satisfies the requirement.

On Android, dynamic linking is more common, but many apps still statically link native libraries for performance. Check your build configuration.

GPL

GPL requires that the entire combined work be distributed under GPL terms with full source code access. If your app statically or dynamically links against GPL code, your entire app may need to be open-sourced under GPL. For commercial mobile apps, this is usually a non-starter.

The distinction between GPL and LGPL matters enormously. An accidental GPL dependency has far more severe implications than an LGPL one.

AGPL

AGPL extends GPL to cover network use. If your backend uses AGPL code and serves results to your mobile app, the AGPL obligations may apply. This doesn't typically affect the mobile binary directly, but keep it on your radar if your team shares code between backend and mobile.

Who enforces open-source licenses?

Open-source license enforcement isn't just theoretical risk. Active enforcement happens through several channels:

The Software Freedom Conservancy enforces GPL compliance on behalf of projects like Git, Samba, and BusyBox. They've pursued legal action against companies that distributed GPL code without meeting the license terms.

Individual copyright holders can enforce their own licenses. The developer who wrote a GPL library can send a cease-and-desist or file a lawsuit if they discover their code in a commercial app without source disclosure.

Automated scanning is making detection easier. Services that scan published app binaries for known open-source components are becoming more accessible. If a GPL-licensed library's binary signature shows up in your compiled IPA or APK, it can be detected without access to your source code.

App store takedowns can result from DMCA claims filed by copyright holders. If a developer identifies their GPL code in your app and you haven't complied with the license, a DMCA takedown against your App Store or Play Store listing is a legitimate enforcement path.

The enforcement landscape is growing. As tooling for binary analysis improves, so does the ability to detect license violations at scale.

Why isn't source-code scanning enough?

Many teams use tools like FOSSA, Snyk, or WhiteSource to scan their source repositories for license issues. These tools check your declared dependencies against license databases and flag potential conflicts.

This is useful but incomplete. Source-code scanners check what your package manager knows about. They miss:

• Vendored code: source files copied directly into your project without a package manager
• Pre-compiled binaries: .framework, .xcframework, or .aar files that contain compiled code with no source declaration
• Build-time code generation: code generated during the build process that pulls in licensed templates or snippets
• Transitive native dependencies: a Swift package that wraps a C library that links against an LGPL dependency
• Dead code that's still linked: code paths that aren't executed but are present in the binary and still covered by their license

Binary analysis catches what source scanning misses. When you analyze the compiled IPA, APK, or AAB, you're looking at what actually ships to users. If LGPL code is in the binary, it doesn't matter that your source repository doesn't reference it directly.

What are the practical steps for license compliance?

Audit your dependency tree

Start with a full SDK inventory using your package manager's dependency resolution output:

# iOS (SwiftPM)
swift package show-dependencies --format json

# Android (Gradle)
./gradlew app:dependencies --configuration releaseRuntimeClasspath

Walk the full tree, not just your direct dependencies. Check each transitive dependency's license. Flag anything that isn't MIT, BSD, Apache 2.0, or similarly permissive.

Check for vendored and pre-compiled code

Search your project for:

• .framework and .xcframework bundles without corresponding source packages
• .aar and .jar files committed directly to your repository
• vendor/ or third_party/ directories with source files

Each of these needs a license check. If the binary has no license file, contact the author or find an alternative.

Generate a third-party notices file

Every app should include attribution for the open-source code it uses. Most permissive licenses require this, and it's good practice regardless:

• iOS: include a Settings.bundle with acknowledgements, or a dedicated screen in your app
• Android: use the oss-licenses-plugin for Gradle to auto-generate notices from your dependency tree

Review the generated file manually. Auto-generated notices sometimes miss vendored code or pre-compiled binaries.

Set up automated checks in CI

Add license scanning to your CI/CD pipeline so new dependencies are checked before they're merged:

# Example: license check as a CI step
- name: Check licenses
  run: |
    npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

For native dependencies, this needs to be supplemented with binary-level checks after the build step.

Document your exceptions

If your app intentionally uses LGPL code and you've determined (with legal counsel) that your usage is compliant, document it. Record which library, which version, which license, and what compliance steps you've taken. This documentation is your defense if questions arise later.

How does binary analysis help with license detection?

AppCompliance scans compiled IPA, APK, and AAB files and identifies embedded SDKs and libraries in the binary. This catches dependencies that source-level scanners miss, including vendored code and pre-compiled frameworks. No tool replaces legal review of your licensing obligations, but knowing what's actually in your binary is the first step toward compliance.

The gap between what your source code declares and what your binary contains is where license risk lives. Teams that only scan source repositories have blind spots they don't know about. And in an environment where automated binary analysis is becoming more accessible to everyone, including license enforcers, those blind spots are a liability.