>- Paragraph 4.b.1, which states that "You will keep your credentials
>> confidential and make reasonable efforts to prevent and discourage other
>> API Clients from using your credentials. Developer credentials may not be
>> embedded in open source projects." prohibits the use of OAuth credentials
>> in free software projects. As I wrote above (and earlier), Google
>> tolerates (at the moment) that this specific point of their TOS is
>> violated. But that doesn't mean that violating them is without legal
>> risk.
Oof, fair enough. It does seem unfortunate that the official rules don't
permit OSS projects; I wish there was a way for a user to create their
own custom API key and they could just add that to their account. Honestly,
I am fine with doing what KMail did (since that's what we did before).
According to emacs-devel, there _is_ a way for users to create their own API key, although it's supposedly pretty involved, and includes an unbounded (in time) review step. There is apparently a python-based package that smooths the process, but it seems to be designed to intentionally avoid automation. Regardless, it isn't a good conceptual fit for GNU because it's pretty user-unfriendly, and it requires running a bunch of "unfree _javascript_", so they don't want to officially recommend it.
FWIW, there are apparently some other clauses that make it clear that they don't want you to automate the API key process (and a suggesting that they'll invalidate keys and break the automated paths), as well as some language that prevents adapting the KMail code into a server for other programs. The core Gnus folks have roughly said "Google has made their intentions clear, so it's not worth _our_ effort to try to sidestep them", and there are in theory conversations underway to see if a KMail-style arrangement can be reached that doesn't trip up the lawyers. No telling how that will turn out, but it seems pretty clear to me (still from the back bleachers) that part of GMail wants to stop supporting clients like Gnus, even if other parts are open to an informal arrangement. GNU has a talent for invoke/provoking formality, though.
~Chad