ownCloud Android: a vendored AAR at the root and a license that is scheduled to change

A binary AAR is checked into the repository root

The top level of this repository contains gradlew, build.gradle, settings.gradle and proguard.cfg, and it also contains a file with a version number and an @aar suffix: androidx.databinding_viewbinding_7.4.2@aar.

That is a compiled Android library sitting next to the Gradle build files, not source. Every other build input here is fetched by the build system, so this one artifact is vendored into version control by hand, pinned to a single databinding viewbinding version.

Three other files in the tree relate to what ends up in the APK rather than to how it is written: dependencies.txt, THIRD_PARTY.txt, and an SBOM in two forms, sbom.json plus an sbom/ directory. So the repository carries both the artifact and the paperwork describing its contents.

That combination matters for anyone planning to add a dependency. The copyleft audit required before an Apache 2.0 migration has to look at GPL dependencies already in the tree, and a binary committed directly is the kind of entry that needs explaining in that audit rather than resolving itself.

Six Gradle projects split the app by layer

The code is not one module. The tree holds owncloudApp/, which is the application itself, alongside owncloudDomain/, owncloudData/, owncloudComLibrary/ and owncloudTestUtil/, plus a plugins/ directory. Alongside them sit config/, changelog/, doc/, docs_resources/ and user_manual/.

The split follows the usual shape for a client of this size. The domain module holds the model, data holds persistence, the com library holds shared communication code, and the test utility module exists so tests in the other modules can share fixtures without depending on the app. A plugins directory means some behaviour is added at runtime rather than compiled into the application module.

What the tree does not do is hide the release machinery. fastlane/ is checked in, so the store submission path is part of the repository rather than an external system, and check_code_script.sh sits at the root as a callable check. Anyone planning a change has to decide which of the six modules owns it, and a change that touches both domain and data needs the boundary respected rather than worked around.

Four workflows, and one of them checks your commit messages

The continuous integration configuration names four workflows: android-unit-tests.yml, android-instrumented-data-tests.yml, detekt.yml and conventional-commits.yml.

Three are ordinary. The unit test workflow runs the JVM tests, detekt is static analysis, and the instrumented data tests run against a device or emulator, which is the slow one and the reason it is separated from the unit tests.

The fourth is the interesting one. A workflow that validates commit messages means the history is checked, not only the code, and it pairs with the rebase workflow the contributing guide requires: pull requests are rebased on the target branch before review rather than merged with a merge commit. Together they make the log the primary artifact under review.

That has a practical effect on tooling. Anything that generates commits for you, including a bot or an assistant, has to produce conventional commit subjects and pass a signing requirement, or the check fails before anyone reviews a line of Kotlin.

One commit command has to satisfy two signature rules

The contributing guide requires every commit to be PGP or GPG signed, and separately requires a Signed-off-by line through the developer certificate. The example shows both in a single command.

git commit -s -S -m "your commit message"

-s adds the sign-off trailer, -S signs the commit, and the guide is explicit that both are mandatory rather than recommended. That means a working signing key has to exist on the machine before the first commit, not before the release, and the key has to be one Git recognises as belonging to you.

Dependency updates arrive separately. Dependabot manages automated dependency pull requests, and the guide asks reviewers to merge them promptly, which is the usual way to stop a dependency queue from growing during a busy release cycle. Combined with the rebase rule, a contributor ends up rebasing onto a target branch that Dependabot is also pushing to.

Workflows may only run actions from three sources

The action policy allows a workflow to use an action only if it is owned by the owncloud organisation, created by GitHub itself as actions/*, or verified in the GitHub Marketplace. Everything else is out, including a pinned commit of an unverified third-party action.

The rule exists because a workflow file runs with repository credentials. An action referenced by tag can change what it does after review, so the acceptable sources are the ones where either the vendor is the same organisation or the artifact has been through a verification process.

The repository also keeps check_code_script.sh at the root, which is where a local run of the same class of check belongs. Contributors running that script before opening a pull request are matching CI rather than discovering differences in it.

None of this is enforced by the build itself. It is a review rule stated in the contributing guide, so it shows up as a comment on a pull request that uses an unverified action, after the work is done.

Translations arrive from Transifex and nowhere else

Translation work has exactly one route. The guide points at the Transifex project and says plainly: submit translations there, do not open pull requests for translation changes.

The .tx/ directory in the repository root is the Transifex client configuration that makes the direction of travel work. Strings live in the code, Transifex holds the translations, and the platform writes them back, so a pull request editing a translated string is at risk of being overwritten by the next sync.

The same separation shows up in the app's own packaging. Resources are kept apart from the Kotlin source, and the user_manual/ directory in the tree is where end user documentation lives rather than in the README.

For a contributor this is a small but real distinction between kinds of pull request. Code changes are reviewed as code. A translation change proposed as a diff is not how this project accepts translations, and the same applies to the store listings maintained through fastlane.

GPL-2.0 is the current license, Apache 2.0 is the target

The README states plainly that this project is licensed under GPL-2.0, and then spends more space on the change that license is scheduled to undergo. The file at the root reflects the current status rather than the intended one, which is stated explicitly to avoid a reader assuming the relicensing has already happened.

The target is Apache License 2.0, chosen to follow the Apache Software Foundation's policy on what may be included in Apache licensed works. GPL-2.0 is classified in that policy as Category X, meaning it cannot be part of an Apache 2.0 work, so this is a full relicensing rather than a header change.

Four prerequisites are named: every past contributor must have signed something that permits relicensing, all GPL dependencies must be replaced or isolated, any code with KDE-era copyrights needs legal analysis, and the copyleft terms mean every file has to be relicensed rather than only the ones being touched. Individual repositories move as their audit completes.

The office driving this was launched on May 5, 2026 under the ownCloud brand, run by the company that acquired ownCloud in 2023, and the README itself is marked as generated by that office on April 16, 2026.

Editorial conclusion

Use the ownCloud Android app if you run either Infinite Scale or a Classic server and want the official client with sharing, Spaces and a passcode lock on a phone. Building it from source is straightforward once the environment is set, but the contribution rules are the real gate: signed commits, a sign-off line, a rebase workflow and a restricted action list decide whether a pull request gets reviewed at all. Check those before writing code, not after. On the licensing side, read GPL-2.0 as the current state rather than a settled future, because the LICENSE file is meant to change once the relicensing audit finishes, and dependencies you add now may be audited later. Translations are not yours to contribute in a pull request; that work goes through Transifex.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. owncloud/android on GitHub
4. README
5. Releases