AboutLibraries: build-time dependency and license collection for Gradle and Kotlin Multiplatform

The license screen problem AboutLibraries solves

Every app that ships third-party code accumulates an obligation to name it. On Android that obligation usually lands as a static list typed by hand, and the list drifts the moment someone adds a dependency. AboutLibraries takes the position that this list should be a build artifact, not a document. The Gradle plugin inspects the project's dependencies and emits metadata, and the UI modules render that metadata.

The intended audience is narrow but real: Android and Kotlin Multiplatform teams that build with Gradle and want an in-app licenses screen without maintaining it manually. The README frames the output around compliance, listing CSV and text exports, compliance reports and a license strict mode among the plugin's capabilities. It also surfaces funding options of the projects you depend on, which is a secondary feature rather than the core one. If your project does not use Gradle, none of this applies.

Build time collection, generated JSON, Compose rendering

The pipeline has three stages, and the README's own hero image names them: a build.gradle.kts file, a generated aboutlibraries.json, and a LibrariesContainer that displays license pills.

Stage one is the Gradle plugin. It hooks into the build and collects dependency and license information. The README states that everything is collected at build time and strongly cached, which is the project's answer to runtime cost: the app does not resolve licenses while the user is scrolling.

Stage two is the JSON. The quickstart loads it as an Android raw resource, R.raw.aboutlibraries, which means the file lands in your resources during the build. The repository also documents an enterprise or manual JSON path for teams that want full control over generation and checked-in metadata, so the generated file can be treated as a reviewed artifact rather than a build byproduct.

Stage three is rendering. The core module exposes the data programmatically, and the Compose modules build on top of it. LibrariesContainer accepts variant, density, detailMode and actionMode, and the README's showcase varies one of those knobs per screenshot, so the same component covers the Refined and Traditional variants, Compact and Cozy densities, chip or icon actions, and inline, dialog or bottom sheet details. Nothing in that list is a separate widget you have to assemble.

Adding the plugin and showing your first libraries list

The README's quickstart is three steps. First, apply the Gradle plugin in the app module. The README notes that the id com.mikepenz.aboutlibraries.plugin.android is the variant that hooks into the Android build automatically, so an Android-only project should use that one rather than the plain plugin id.

// App build.gradle.kts
id("com.mikepenz.aboutlibraries.plugin")

Second, add the UI module that matches your Material version. The README's example uses the Material 3 artifact and a version placeholder from the project's release naming. Substitute the actual release you want rather than copying the placeholder literally.

implementation("com.mikepenz:aboutlibraries-compose-m3:${latestAboutLibsRelease}")

Third, load the generated resource and hand it to the container. The produceLibraries call reads R.raw.aboutlibraries, which is the file the plugin wrote during the build, and LibrariesContainer fills whatever size you give it.

val libraries by produceLibraries(R.raw.aboutlibraries)
LibrariesContainer(libraries, Modifier.fillMaxSize())

After a build, expect a generated aboutlibraries.json under your app's resources and a scrollable list in the running app. If the list is empty, the plugin did not run or did not see dependencies, which is a build configuration problem rather than a UI one. The README points to a Reference section for multiplatform loading and plugin configuration, and the sample directory in the repository contains android, desktop, ios, shared and web modules that show the setup per target.

Where AboutLibraries is the wrong tool

The plugin only knows what Gradle knows. Dependencies resolved outside the Gradle graph, code vendored into the repository, or licenses attached to artifacts that carry no metadata will not appear in the generated JSON. That is a property of build-time collection, not a bug, but it means the output is a faithful picture of your Gradle dependencies and not a complete legal inventory.

The UI is also opinionated toward Compose. The repository ships aboutlibraries-compose, aboutlibraries-compose-m2, aboutlibraries-compose-m3 and aboutlibraries-compose-wear-m3, plus a core module for programmatic access. A team on the older View system with no Compose in the app gets the core data and has to build its own screen; the README describes building your own on core as an option, which is honest about where the prebuilt components stop.

There is a versioning cost too. The generated JSON is tied to the plugin version that produced it, and the repository keeps a MIGRATION.md at the top level. Projects that pin an old plugin and later jump majors should expect to read that file rather than assume the JSON shape is stable.

How it differs from hand-rolled license lists and other generators

The closest alternative is a manually maintained licenses screen: a string resource or a Markdown file copied from a template generator, checked in once, and updated when someone remembers. The difference is where the truth lives. A manual list is a document that can be correct on the day it is written and wrong the next week; AboutLibraries derives the list from the dependency graph on every build, so the failure mode becomes a stale build rather than a stale document.

A second alternative is a generic license-report plugin that produces a text or CSV file for release engineering. Those tools also read the Gradle graph, but they stop at the file. AboutLibraries ships the rendering layer as part of the same project, with Material 2, Material 3 and Wear variants, and the README lists CSV and text exports and compliance reports alongside the UI, so the report and the screen come from one source. If your only consumer is a compliance archive and no user ever sees the output, a report-only tool is a smaller dependency. If a user has to see it, the prebuilt container saves you writing one.

Maintenance, licence and what upgrades cost

The repository is not archived, and the last push was on 2026-09-08. Releases in the 15.x line appeared through August 2026, with 15.2.0 on 2026-08-28, so the project is being worked on rather than left behind. The default branch is develop, which means the README you read on GitHub reflects unreleased work; pin your dependency versions rather than tracking the branch.

AboutLibraries is licensed under Apache-2.0. That is a permissive licence, and the practical implication for adopters is that you are not adding a copyleft obligation to your app by using the plugin or the UI modules. It says nothing about the licences of the dependencies the plugin collects, which is the entire point of the generated file. This is not legal advice; the compliance output you ship is your responsibility, not the library's.

Upgrade cost concentrates in two places. The plugin generates the JSON, so a major bump can change what the file contains, and the repository's MIGRATION.md exists for that reason. The UI modules follow Material versions, so a project on Material 2 uses aboutlibraries-compose-m2 and one on Material 3 uses aboutlibraries-compose-m3; moving between them is a module swap, not a configuration flag. The README does not document rollback for a failed plugin upgrade, so keep your previous plugin version pinned until the generated JSON looks right.

Editorial conclusion

Adopt AboutLibraries when you ship an app that must show third-party licenses and you already build with Gradle, because the plugin runs at build time and the UI modules cover Android, Compose Multiplatform and Wear without runtime cost. Do not adopt it if your build is not Gradle-based, or if you need a hosted compliance service rather than generated metadata checked into your repository. Before wiring it in, verify which plugin id matches your build (com.mikepenz.aboutlibraries.plugin versus the .android variant), confirm the generated aboutlibraries.json actually contains the entries you expect, and read MIGRATION.md if you are coming from an older major version, since the repository keeps a separate migration guide for exactly that reason.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mikepenz/AboutLibraries on GitHub
3. Project website
4. README
5. Releases