Many open source licenses ask that copyright and license notices travel with the software, and a mobile app is a distribution of that software. An in app licenses screen is the usual way to meet this. Google documents a plugin that generates one for Android apps. Whether your exact set of licenses requires it is a question for counsel.
Why a mobile app is different
A web service you run yourself does not hand a copy of its libraries to users. A mobile app does. Each install carries the libraries you compiled in, so notice and attribution conditions can apply.
The MIT text, for instance, says its copyright and permission notice shall be included in all copies or substantial portions of the software. Apache 2.0 asks redistributors to give recipients a copy of the license and to carry forward applicable NOTICE file attributions. A single app may contain dozens of such libraries.
What Google documents for Android
Google's guide says you are responsible for showing notices for the open source libraries your app uses, since Play services SDKs sometimes include or depend on open source libraries. It describes a Gradle plugin and a Play services dependency that together provide an activity listing the libraries, where a tap shows each license. At build time the plugin reads the license entries in each direct dependency's POM file.
That last point is a limit worth knowing. The plugin reads metadata from direct dependencies. It does not replace a full inventory, so check coverage for transitive libraries, native code and bundled assets.
What to include
| Item | Why |
|---|---|
| Library name and version | So a reader can find the source |
| License name or text | Required by many licenses |
| Copyright notice | Often required |
| NOTICE content | Required where an Apache NOTICE file exists |
| Fonts, icons, images | Assets have licenses too |
Steps
- Generate an SBOM for each release build, not just the source tree.
- Compare it to what the licenses screen shows.
- Add the missing items, including native libraries and assets.
- Keep a copy of the notices file with the release record.
- Re run the check each time dependencies change.
For iOS and desktop
The same logic applies. Apple apps often put notices in a settings screen or in the app's acknowledgments. Check each platform's conventions and the license terms for what you ship.
See also MIT attribution: what to ship.
Safeguard does dependency scanning and SBOM generation across your repositories, and you can set policies and gates on what may merge. You can try a free scan of a public repository to see what a component inventory looks like.
Quick check
Is a licenses screen legal advice compliance?
It is a common practice, not a guarantee. Each license has its own conditions, so review the ones in your app.
Does the Android plugin cover everything?
Google says it reads direct dependency POM entries. Check transitive libraries, native code and assets yourself.
Sources
Last reviewed: 19 October 2026.
