Re: Google modules integration

[Thomas Lord]

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.