Support for third_party_licenses files from Google Play Services libraries

[arekolek]

About this issue

Can this plugin also include libraries depended upon by the Google Play services libraries, like the Google oss-licenses-plugin does?

The list of licenses also includes the full license text of any library that is depended upon by the transitive closure of Google Play services libraries used by the app. This means that the list includes any open source libraries that are used to create the Google Play services libraries that are compiled into your app. https://developers.google.com/android/guides/opensource#how-licenses-are-determined

In my case, compared to AboutLibraries, oss-licenses-plugin included additional 17 libraries because of Google Play services, and I'd prefer not to have to maintain it semi-manually and have to keep using oss-licenses-plugin to extract these licenses.

From what I was able to find out, .aar files for Google libraries include third_party_licenses.json and third_party_licenses.txt files that are parsed to extract these libraries and their licenses. Unfortunately in this case there is no "artifact ID" that would correspond to the uniqueId from AboutLibraries, only the name.

As an example of how this looks in the .aar file: https://stackoverflow.com/a/74617118/1916449

Details

• [x] Used library version: 10.5.2
• [ ] Used support library version
• [ ] Used gradle build tools version
• [ ] Used tooling / Android Studio version
• [ ] Other used libraries, potential conflicting libraries

Checklist

• [x] Searched for similar issues
• [ ] Checked out the sample application
• [x] Read the README
• [x] Checked out the CHANGELOG
• [x] Read the MIGRATION GUIDE

[mikepenz]

@arekolek thank you for the report.

I've had a look into the format they use in the past, and we may not benefit from the complexity of supporting it.

It is possibly worth to identify which additional libraries were found, and why the oss-plugin found them. E.g. was it in the pom or do they some manual process which can't be generically covered?

[arekolek]

Thanks for the reply

I'm pretty sure of the 17 libraries I mentioned, none was in the pom, although I have checked only two of my Google dependencies that had included 7 such libraries.

According to https://github.com/google/play-services-plugins/issues/217#issuecomment-1047885621 they look only at pom in general and third_party_licenses.(json|txt) files in case of Google libs.

I linked above to the part of their plugin code where they handle the latter: https://github.com/google/play-services-plugins/blob/45ec9c690672f0ff6f86e6221ef64e204b10a228/oss-licenses-plugin/src/main/groovy/com/google/android/gms/oss/licenses/plugin/LicensesTask.groovy#L168

The good thing is that it seems that they follow the same convention in all their libraries, so there shouldn't be a need to handle each Google library separately.

[arekolek]

I've had a look into the format they use in the past, and we may not benefit from the complexity of supporting it.

Also to make it clear: I wouldn't want to include the third_party_licenses and third_party_licenses_metadata their plugin generates. I would like the AboutLibraries to:

1. Open the .aar file like they do https://github.com/google/play-services-plugins/blob/f2944253ea767292f7e2f1e1131ddbc4111bdbe4/oss-licenses-plugin/src/main/groovy/com/google/android/gms/oss/licenses/plugin/DependencyUtil.groovy#L97
2. Extract the library names and licenses from it (like in comment above)
3. Add them to aboutlibraries.json like the rest of dependencies

[mikepenz]

Thank you for the additional references. I will need to spend some more time to get a better overview of what the effort may be to add support to handle this.

Currently I can't give a clear answer if this is something we'll be able to offer or when we may be able to offer it.

Given your research on the matter already, possibly this is something you'd like to contribute?

[arekolek]

I started working on something that would let me add these as described in https://github.com/mikepenz/AboutLibraries#libraries just so I don't lose these licenses (for the most part it was a rewrite of part of the oss-license-plugin in Kotlin, because it seemed easier than having both Kotlin and Groovy in buildSrc)

Later I might be able to check out how this plugin works and try to integrate that into it, I'll post here if I do

I see two issues already:

• how to avoid duplicates, since there is no module group, name or version for those dependencies, only some "human readable" name
• how to determine license name, because there is only the full license text

[koral--]

I've noticed the similar issue some time ago. Namely, okhttp depends on the Public Suffix List, which itself is licensed under MPL but is not listed in POM. It is even not a jvm library. The license is distributed by including the txt file (by default it is present in the the root dir inside APK/AAB). I've ended up with creating the POM-only "library" https://github.com/DroidsOnRoids/public-suffix-mpl/blob/master/build.gradle.kts#L16 About Libraries recognizes the license just like normal ones.

More info: https://github.com/mikepenz/AboutLibraries/issues/502 (and resources linked there).

[mikepenz]

To follow up on this ticket. Did you end up writing a new plugin for the oss handling?

IS there something to look at which we may be able to integrate back in?

Thanks a lot

[arekolek]

I have this gradle plugin in my buildSrc that is based on oss-license-plugin and outputs json files for aboutlibraries.

I hoped to just create a PR to this repo, but didn't have the opportunity to look more into how it works. So I'll ask if I can just share my current plugin with you so you can have a look

[mikepenz]

Yes please @arekolek, can't promise anything. However I'd like to have a look and see what I can do.

[arekolek]

@mikepenz you can see the code here https://github.com/arekolek/third-party-licenses

Note there's also a separate branch, with a proof-of-concept for detecting license names

[mikepenz]

Thank you very much. It will probably take me a bit to get to it. Really appreciate it!