From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Google modules integration Date: Mon, 13 Sep 2010 12:07:02 -0700 Message-ID: <1284404822.3329.135.camel@dell-desktop.example.com> References: <878w3a1x9s.fsf@keller.adm.naquadah.org> <1284140876.2505.23.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284404837 766 80.91.229.12 (13 Sep 2010 19:07:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Sep 2010 19:07:17 +0000 (UTC) Cc: julien@danjou.info, dave@lab6.com, emacs-devel@gnu.org, carsten.dominik@gmail.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 13 21:07:15 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEN1-0007iK-0j for ged-emacs-devel@m.gmane.org; Mon, 13 Sep 2010 21:07:15 +0200 Original-Received: from localhost ([127.0.0.1]:37507 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvEN0-0004vP-AP for ged-emacs-devel@m.gmane.org; Mon, 13 Sep 2010 15:07:14 -0400 Original-Received: from [140.186.70.92] (port=57836 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvEMs-0004uS-0z for emacs-devel@gnu.org; Mon, 13 Sep 2010 15:07:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvEMq-00051O-G9 for emacs-devel@gnu.org; Mon, 13 Sep 2010 15:07:05 -0400 Original-Received: from smtp201.dfw.emailsrvr.com ([67.192.241.201]:35103) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEMq-00050w-Af for emacs-devel@gnu.org; Mon, 13 Sep 2010 15:07:04 -0400 Original-Received: from relay20.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 6410721281E7; Mon, 13 Sep 2010 15:07:03 -0400 (EDT) Original-Received: by relay20.relay.dfw.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id BF22E2128160; Mon, 13 Sep 2010 15:07:02 -0400 (EDT) In-Reply-To: X-Mailer: Evolution 2.28.3 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130084 Archived-At: RMS, The Google Maps question brought up the SaaS vs. "ordinary service" question. You argued that Google Maps is not SaaS because the protocol merely provides a way for people to retrieve Google's data. The distinction you're drawing makes some intuitive sense, but I think it ultimately leads to trouble, including in the specific case of Google maps. I'll point out what I think the problem is and suggest a better way to frame the issue: You put it this way: > The user's "input" is simply a specification > of which part of their data the user wants to see. > The point of SaaS is that the site does > nontrivial computing that, by nature, is your > computing. In these cases, it is trivial. > So I think you are treating insignificant > amounts of "your own computing" as > significant. With that interpretsation, all > web servers appear to be SaaS. Even in a purely > static web site, the user provides some input > -- a URL -- and gets a result depending on the input. > So that is the wrong criterion. In the case of Google Maps, you are already going down a slippery slope. The simple fact of the matter is that the user's input to the Google Maps static map API is rather more than just what part of the data the user wants to see. Yes, the user must provide enough data to retrieve the map information - but then users also provide a specification of how to transform that data into a customized presentation. For example, if I want a map with a pointer to my house, the block I live on highlighted, and, say, a route marked to the nearest park, all of those graphical transformations of the map data are done by Google. Technologically, they could as well have sent me the raw data for the area I requested and let me use my own program for those transformations -- but they did not. Perhaps you think that is trivial but one consequence of this is that for every single user who looks at the map I specified, Google attempts to keep track of and remember that that user looked at that map (the one with my house, block, and route to the park highlighted). Google admits to attempting to collect and preserve that information for at least 24 hours - building a daily record of which maps, with which highlights each user views. (One reason Google collects this data is to enforce a quota - a limit on the number of static maps a user may retrieve in a single day.) Also, as a term of service associated with the processing Google Maps offers, they require that client programs reveal whether the user's location has been obtained from a GPS device: in other words, though they share their map data publicly, they reserve the right to reject requests from client programs that don't help Google spy on where users are physically located. (Such a term of service is particularly problematic for publicly available free software clients since they could not hide from Google the fact that they might be designed to fib about the GPS question.) So, I hope you begin to see the problem: Yes, even the log of a purely static web site can be used to spy on people. What has happened in the case of Maps is that (in your view) we don't begrudge them doing a little bit of extra computation for us -- an "insignificant amount of processing", as you put it -- and they then leverage that rather insidiously. As a thought experiment: what features would they have to add to the Google Maps API before you would say "Ok, that's too far. The line has been crossed and now its SaaS."? It's one of those "know when you see it" lines that make some sense, but that reasonable people can disagree about wildly. I think that by framing the issue that way, you've opened up a door to saying "Well, the right of software freedom is often trumped by the right to hold large data sets as private property -- at least to some extent." ------------------------------------------- What's better (both logically and practically)? How about this: If the functionality of a service provided by some other party is such that it *can* be replaced by a free software alternative which operates in a distributed and decentralized way -- in other words if user's *can* perform that computation for themselves -- then the service *should* be done using free software in a distributed decentralized way. Any service which can be replaced by a solution that affords users greater software freedom but whose operators take steps to prevent this, is a service which actively attacks software freedom. Here is an example: Suppose I put a digital thermometer outside my window. I have a web service that you can use to get the latest reading. As a technological matter, there is no practical alternative there. If you want the very latest reading, you have to query might web site. My service also keeps historical records and, as a convenience, you can send queries that look up chunks of history, pass them through GNU graph, and send you back a picture. That *is*, in the view I'm proposing, SaaS. What makes this OK is that anyone can just take copies of my historical records, and draw graphs for themselves. Nobody is forced to use only my programs to view the temperature history. What of Google's static map API? It would be quite feasible, technologically, for a distributed and decentralized network to cache the raw map data, and let people use software they control to query the cache and render maps. Google is not likely anxious to agree to that, of course. As nearly as I can tell, they regard their non-photographic map images (which are the output of programs) as copyrighted images. They specifically decline to give out much raw data. They regard the underlying aggregate of scientific facts as a copyrighted aggregate work, some portions of which are distributed by Google's map API. In other words, although it would be possible to give users greater software freedom with respect to Google's maps ... Google's current practice suggests that Google will not cooperate with such an effort. They would rather leverage their raw data to attack software freedom as pertains to maps (much as they attack software freedom as pertains to search). The free software movement should therefore assert that, indeed, publicly licensed (along GPL or GDPL lines) or public domain map data collections are socially valuable, and software freedom will be improved by replacing Google maps with a distributed, decentralized free software alternative. A similar argument applies to Google search. While the GNU project may not itself be in an immediate position to take on those challenges, nevertheless, doing the very opposite by building Google Map support into GNU Emacs, seems a step backwards for software freedom.