Re: Google modules integration

[Jambunathan K]

Richard Stallman <address@hidden> writes:

Glen> Me neither, but here are the maps API terms and conditions:
Glen> 
Glen> http://code.google.com/apis/maps/terms.html
Glen> Google Maps/Google Earth APIs Terms of Service
Glen> 
Glen> Various things of interest, eg
Glen> 
Glen>   10.8 [you must not] use the Static Maps API other than in an
Glen>   implementation in a web browser
Glen> 
Glen> You can browse the web from Emacs, but it's not really a web
Glen> browser, is it?  I dunno...

Hypothetically speaking, I think Google or any data provider might want
to impose certain restrictions on the end-user[1] of the data and tailor
such restrictions based on the agent that the end-user employs for
consumption. The reason could be that different agents have different
appetite for data and a data provider might feel threatened if there is
a super-human agent that could steal the data in matter of minutes.

So in essence there are multiple entities here - 

1. an end-user (me)
2. a user-agent (browser, emacs, wget, xmlrpc client etc)
3. data provider (google)
4. a solution provider (an entity that built the agent (Julien). He is a
   specialized end-user of data who consumes the data not for personal
   consumption but for building and stabilizing the product.
5. an entity that sells/distributes the agent (GNU?)

The question now:

1. Does the data provider know the agent (or the class of agent) that is
   consuming the data. ie., Can Google tell that I am using emacs and
   not firefox.

   The most naive way for a provider to tell the agent is to look at the
   User Agent cookie (if any) posted by the client agent.

2. What is Google's notion of agent categories?

   Firefox or Chromium could be classfied as a human-powered browser and
   Emacs could be classfied as a super-human evil bot.

3. Does Google try to track, meter or cap the data provided to the agent
   by expecting the agent to return a pre-configured cookie distributed
   from their servers. 

   This could be done by having different cookies for solution developer
   and solution user.

Glen>     If you are writing code to use someone's APIs to access their
Glen>     database, it does not seem an unreasonable expectation that
Glen>     you should first check what terms those APIs and the data are
Glen>     made available under.
Glen> 
Glen> I don't understand the question very well.
Glen> Why should we have any expectations about that question?
Glen> And why does it matter whether we do or not?

Let me try to interpret what possibly could be meant here ... It is
easier explained and understood in terms of a scenario.

A commercial Organization O is building a product P using API A provided
by another Organization G. O has some employees that are testers whose
role is to test the product and report bugs. It is common practice that
G gives O an one-off license (API-usage license or End User-license or
specialized license) on liberal terms. Naturally so, because in some
sense O and G are partnering organizations.

Key thing to note here is that testers of the API are required to have
taken prior consent and token from API vendor even for testing and there
are managerial controls to make sure that this happens.

In specific case of GNU software, the distinction between users and
testers practically blurs. Furthermore Emacs is not coming from a
Commercial enterprise and it's ownership is really with the community
with FSF or a few entities taking a 'very predominant share' in it.

So the question is are we really testing the module that Julien built (
if yes, do we do it on behalf of Emacs or in individual capacities) or
are we merely using it (in which case really there is no issue).

I believe the modules under discussion are not overly complex and some
of the considerations above could be largely ignored. What if the "API"
is complex and "Emacs" is actually some other 'complex product' that is
coming from the GNU's stables.

Let me not be misunderstood. I am not making an argument in favor of
inclusion of Google modules. In fact I would like to see it not included
within official packages. My intention here truly is to understand the
underlying subtleties of the above consideration.

Thanks for being with me. Would appreciate if someone enlightens me even
off this list.

Jambunathan K.