Keeping your licenses in check

A quick and easy way to check the third-party licenses for your Android app

This image, for instance, does not require any attribution. Source

A primer to software licenses

Licences are a tricky beast, but more often than not we tend to ignore them even though we really should not. The fact that a third-party library is open-source easily deceives us into thinking that we can do whatever we want with it, because why not? The code is there for everyone to see, we can copy or modify it, and there is no physical limitation that prevents us from doing so. But, as it turns out, licenses are extremely important from a legal perspective.

Let’s go through some examples, starting with Retrofit. It is released under the Apache license, version 2.0, but what does that mean, exactly? In a few words, it’s a very permissive license that allows you to use, copy, modify and distribute the code, for both private and commercial use (and more). In return, the Retrofit user is required to include a copy of the license and a list of the modifications, if any (again, there is more).

A completely different situation is presented with ffmpeg, the most famous library to manipulate audio and video. This library is released with the GNU Lesser General Public License 2.1, in short LGPL. Again, the gist of the license is that you can use, modify and distribute the code even for commercial purposes. However, your obligations as a user extend not only to include the original license, but to actually include or point to the original source code. Moreover, if ffmpeg is statically linked by your app, you must allow a potential third-party to modify it by releasing its source code; if dynamically linked, you must make the source for the library available. If all of that sounds complicated, this page will be very helpful.

As you can see, different types of of licenses come with different types of permissions and obligations. In order to regulate the use and distribution of source code, one should pick the license that better encompasses the desired usages of said code. This website can give you an overview of the different types of licenses you can use, and help you choose the most appropriate one.

We can summarize what we have learnt from these examples by saying that licenses are important from a legal perspective, that there are many different types, and that each type comes with permissions and obligations.

Licenses as an Android developer

As Android developers, we are blessed to be part of an incredibly active community that has released a ludicrous amount of libraries that everyone can use. We are so used to either just take them for granted, or to simply assume that there must be one for our current specific need.

At the very beginning, I used to completely ignore the licenses. I had a problem, the library could help me solve it, end of story. However, regardless of the fact that you work as an independent developer or for a company, you are legally liable for not obliging to a particular license. After you develop this awareness, you will be much more careful about the libraries that you use, and you will check what licenses they come with.

But what if you, or your company, already have an app with dozens of third-party libraries? How can you check the licenses for each one of them?

The most naive but completely valid approach would be manually going through each one of them and somehow check their license, either by looking into their archive or by looking them up online. This approach, even though effective, is very cumbersome and tedious. Moreover, “it doesn’t scale” over time and complexity: what if you add 10 more libraries? And how frequently do you have to check if a license has changed or not?

license-gradle-plugin to the rescue

I was tasked with tackling this particular problem after I joined Blinkist. We wanted a way to check what licenses we were depending on (by means of using third-party libraries), possibly grouped by license type. The license-gradle-plugin looked like the perfect tool for the task: among the different functionalities it provides, there is one that allows to scan the dependency tree, fetch all the licenses it can find and group them by license type. Sounds great 🎉

However, the plugin hasn’t seen any recent active development, and didn’t seem to be working with more recent versions of Gradle (particularly after Gradle 3.4, where the new api/implementation instructions were introduced). This PR seemed to have supposedly introduced compatibility for it, but it was never released. I decided to give it a try by checking out master and understanding if it worked.

Thanks to JitPack, this was a 2 minutes job. A couple of lines of code in our build.gradle files

allprojects {
  repositories {
    ...
      maven { url 'https://jitpack.io' }
    }
}
dependencies {
  implementation 'com.github.hierynomus:license-gradle-plugin:master-SNAPSHOT'
}
plugins {
  id "com.github.hierynomus.license-report" version "0.14.0"
}

and it was ready to go. As you can see, we’re using a SNAPSHOT version of master. The plugin is also modular, and what we’re interested in is exclusively the reporting part, hence license-report.

To use it, we first need to provide a configuration, a basic version of which looks like this

downloadLicenses {
  dependencyConfiguration [your_build_task_here]
  includeProjectDependencies true
}

The dependencyConfiguration parameter allows you to specify the Gradle task for which you will have dependencies to check: simply specify the task that you use to build your app. The includeProjectDependencies parameter allows you to include the transitive dependencies in the analysis.

To run the plugin, it suffices to invoke the respective Gradle task, like so

$ ./gradlew downloadLicenses

The plugin will then analyze the dependencies, fetch all the LICENSE files it finds, and group them both by dependency and by license. We can find the results of the analysis by looking at the build/reports directory, where there will be two HTML files (other formats available): dependency-license.html, which maps each dependency to its license, and license-dependency.html, which groups dependencies by license. They look something like this

Dependency > license

License > dependencies

It looks great! Now we have an easy way to keep the licenses of the current libraries we use in check. 🤓

Conclusion

This solution fitted our needs perfectly, but that doesn’t mean that it can’t be refined. The gradle-license-plugin works by analyzing the POM metadata, but not every third-party library comes with one, so the list of licenses you will obtain might not be exhaustive (thanks Sebastiano Poggi for pointing that out). Moreover, it would be great to extend the plugin so that it emits a warning/error whenever a new license that has not yet been whitelisted is introduced.

Google has also released OSS Licenses Gradle Plugin, which is very similar to the one used in this article and can be paired with a library that displays the licenses in an Activity. But, to be fairly honest with you, it’s not the prettiest.

I’m sure there are more structured solutions out there, and I’d be curious to see if/how you solved this issue. Feel free to hit me on Twitter or to reply to this article. In the meantime, I hope this helps!

Appendix

Or, you know, you can avoid all of this and just go with WTFPL (a lovely acronym that stands for “[Do] What The F**k You Want to Public License”), as my lovely colleague Thiago “Fred” Porciúncula pointed out 😂