From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Fri, 21 Aug 2020 17:16:46 +0000 Message-ID: References: <87bljki71n.fsf@mat.ucm.es> <87364wxlec.fsf@gnus.org> <87imdsgmlw.fsf@mat.ucm.es> <871rkfhkhc.fsf@mat.ucm.es> <875z9p5hnc.fsf@mat.ucm.es> <87364pbkn0.fsf@gnus.org> <87lfihe0zf.fsf@mat.ucm.es> <874kp55l8t.fsf@gnus.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14230"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.21 (NEB 202 2017-01-01) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 21 19:17:37 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9AfZ-0003a2-94 for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Aug 2020 19:17:37 +0200 Original-Received: from localhost ([::1]:47494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9AfY-00084r-3K for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Aug 2020 13:17:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9Af2-0007bl-N9 for emacs-devel@gnu.org; Fri, 21 Aug 2020 13:17:04 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:59993) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9Af0-0007pp-GM; Fri, 21 Aug 2020 13:17:04 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 07LHGnkc009947 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 21 Aug 2020 17:16:50 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 07LHGn4J023960; Fri, 21 Aug 2020 17:16:49 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/21 13:16:53 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254078 Archived-At: > >> Yes, if they agree to take the legal responsibility of the use of these >> credentials, and if they pay if Google wants to have the code of the >> program reviewed by security experts. > > I am completely lost here. What legal responsibility is involved? > This is an answer that developers cannot give you. It's a question that only a lawyer can answer. But I at least would not agree to personally take the risk of being sued by Google for having knowingly violated their terms of service, even if Google tolerates (at the moment at least) that free software projects violate these TOS. I observe that this is what happened in similar projets, e.g. Kmail: it's not an individual who has submitted the app for verification by Google, but a legal person, KDE e.V. Violating these TOS by making the OAuth credentials public (which is what happens in a free software project) can have consequences, for example if a malicious person uses them in their own app to fraudulently gain access to Google accounts. > > I've asked for someone to please tell me, in brief terms, the concrete > reqwuirements for issuing an app key to something like GNUS, but I have > not seen a reply stating them. > Google's terms of service for OAuth services are available at https://developers.google.com/terms . Only a lawyer can tell you in brief terms what the concrete requirements are. I've just read them again, and it seems to me that: - Paragraph 4.a.1, which states that "you will not create an API Client that functions substantially the same as the APIs and offer it for use by third parties", expressly prohibits your idea of creating a "modif[ied] Kmail so that it does the necessary low-level access, and nothing else". - 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. - Paragraph 9.c list the legal risks: "Unless prohibited by applicable law, if you are a business, you will defend and indemnify Google, and its affiliates, directors, officers, employees, and users, against all liabilities, damages, losses, costs, fees (including legal fees), and expenses relating to any allegation or third-party legal proceeding to the extent arising from: - your misuse or your end user's misuse of the APIs; - your violation or your end user's violation of the Terms; or - any content or data routed into or used with the APIs by you, those acting on your behalf, or your end users." Of course an individual person is not a business, but nobody is completely independent, and I'd guess that Google would seek redress against that person's employer for example. What I wrote above is nothing but my understanding. Again, only a lawyer can tell you what these TOS concretely imply. Gregory