On Mon, Aug 31, 2020 at 5:44 PM Ken Hornstein <kenh@pobox.com> wrote:
- 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