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:09:38 -0700 Message-ID: <1284404978.3329.136.camel@dell-desktop.example.com> References: <878w3a1x9s.fsf@keller.adm.naquadah.org> <1284140876.2505.23.camel@dell-desktop.example.com> <1284404822.3329.135.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 1284404998 1638 80.91.229.12 (13 Sep 2010 19:09:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Sep 2010 19:09:58 +0000 (UTC) Cc: julien@danjou.info, emacs-devel@gnu.org, carsten.dominik@gmail.com, dave@lab6.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 13 21:09:54 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 1OvEPW-0000NR-UE for ged-emacs-devel@m.gmane.org; Mon, 13 Sep 2010 21:09:51 +0200 Original-Received: from localhost ([127.0.0.1]:58925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvEPW-0006Mi-5k for ged-emacs-devel@m.gmane.org; Mon, 13 Sep 2010 15:09:50 -0400 Original-Received: from [140.186.70.92] (port=58664 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvEPN-0006Kh-Tz for emacs-devel@gnu.org; Mon, 13 Sep 2010 15:09:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvEPM-0005Sr-I5 for emacs-devel@gnu.org; Mon, 13 Sep 2010 15:09:41 -0400 Original-Received: from smtp181.iad.emailsrvr.com ([207.97.245.181]:60932) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvEPM-0005Sg-Ci for emacs-devel@gnu.org; Mon, 13 Sep 2010 15:09:40 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp48.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 3750016825A; Mon, 13 Sep 2010 15:09:40 -0400 (EDT) X-Virus-Scanned: OK Original-Received: by smtp48.relay.iad1a.emailsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 3AC4D168239; Mon, 13 Sep 2010 15:09:39 -0400 (EDT) In-Reply-To: <1284404822.3329.135.camel@dell-desktop.example.com> 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:130086 Archived-At: Also: is there some reason to not, instead, add Open Street Map support to GNU Emacs? -t On Mon, 2010-09-13 at 12:07 -0700, Thomas Lord wrote: > 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. > > > > > >