Re: Google modules integration

[Thomas Lord]

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.
> 
> 
> 
> 
> 
>