GoogleSignIn license in my app's licenses list view

Question

I made an app for iOS and before publication I have to make view, where I list all used 3rd party libraries licenses. Unfortunately, I cannot find license for GoogleSignIn SDK for iOS. This package is made by Google, but I can't find any informations about license of even license file in installed pod.

On it's pod www site field "License" is filled with value "Custom", but after clicking it I'm redirected to implementation tutorial. Pod description also says to check this link for "integration instructions, documentation, support information, and terms of service." but I don't see any informations about license. What should I do with this package? Should I list it in licenses view without any license details?

Answer 1

IMO (and admittedly IANAL/IANYL) it's all a mess. The podspec file, hosted on github, says that

"license": {
 "text": "Copyright 2019 Google",
 "type": "Copyright"
},

which is remarkably unhelpful, and gives you no rights at all. It also points me to the source tarball; when I download and unpack that, I find no occurrences of the word license, but a lot of this sort of thing in the header files:

* Copyright 2012 Google Inc.
*
* Use of this SDK is subject to the Google APIs Terms of Service:
* https://developers.google.com/terms/

On reading those terms, I find nothing about copyright licensing - they're all concerned with constraining how you use the Google-hosted API that the code is designed to interface with.

How I read this is that Google doesn't care what you do with the code. Unless you're willing to build an entirely new internet authentication infrastructure yourself, all you can do with it is interface with their service, and all they care about is how you do that. But using this code is a gamble; nothing stops them turning round later and cease-and-desist'ing you.

If you're willing to take that gamble, I don't think you have any acknowledgment or notification obligations at all. If you're not willing to take that gamble, then avoiding centralised sign-in services in favour of federated ones (like the much under-used OpenID) seems to me a much better way to go.