Google modules integration

Google modules integration

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hi folks,

I recently wrote a couple of module, namely `google-maps' and
`google-weather', which retrieve various information from the Google
API.

Using this 2 modules, I wrote 2 extensions for Org mode, one adding
weather forecasts in the Org agenda, and another one adding the
possibility to show a Google Map for the location of an event from your
agenda.

This two modules have a small webpage describing them at:

     http://julien.danjou.info/google-maps-el.html

     http://julien.danjou.info/google-weather-el.html


Today, Carsten Dominik asked me to merge the Org parts of the above
extension into Org mode, something I'd be glad to see happen.

But to do the things correctly, that would mean the merge of the
`google-maps.el' and `google-weather.el' modules into Emacs core
packages. We do not want Org to rely on external sources and would like
to have this in the core functionalities of Org mode.

The question is, therefore, is there a chance that we could merge these
two extension into Emacs?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Google modules integration

[Stefan Monnier]

> But to do the things correctly, that would mean the merge of the
> `google-maps.el' and `google-weather.el' modules into Emacs core
[...]
> The question is, therefore, is there a chance that we could merge these
> two extension into Emacs?

Without having thought much about it, my reaction is rather negative,
since we do not want to install packages dedicated to supporting
proprietary software.


        Stefan

Re: Google modules integration

[Lennart Borgman]

On Fri, Sep 10, 2010 at 12:25 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> But to do the things correctly, that would mean the merge of the
>> `google-maps.el' and `google-weather.el' modules into Emacs core
> [...]
>> The question is, therefore, is there a chance that we could merge these
>> two extension into Emacs?
>
> Without having thought much about it, my reaction is rather negative,
> since we do not want to install packages dedicated to supporting
> proprietary software.

What about elpa? Could this perhaps be more relaxed regarding
supporting proprietary software? Or should there be a special elpa
repository for it? (Is that possible with the current elpa version?)

Re: Google modules integration

[Sebastian Rose]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> But to do the things correctly, that would mean the merge of the
>> `google-maps.el' and `google-weather.el' modules into Emacs core
> [...]
>> The question is, therefore, is there a chance that we could merge these
>> two extension into Emacs?
>
> Without having thought much about it, my reaction is rather negative,
> since we do not want to install packages dedicated to supporting
> proprietary software.


Not sure, what we need a map API is in Emacs' core for but...


The code could be used with openstreetmap.org maps, too.  This is, what
I play with currently to create images from tracks I run (I use my own
simple code on http://github.com/SebastianRose/org-osm).

OSM maps offer much more detail in lots of places (cycle paths,
footpahts, stores, phone booths...).

Both, OSM and google, use Mercator maps and 256x256 tiles.  OSM maps
start at the date border, just like google maps.  The only difference is
in the URL for a map tile.


OSM is "Creative Commons Attribution-ShareAlike 2.0" licensed. See
http://www.openstreetmap.org/copyright




   Sebastian

Re: Google modules integration

[Ted Zlatanov]

On Fri, 10 Sep 2010 00:56:09 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> On Fri, Sep 10, 2010 at 12:25 AM, Stefan Monnier
LB> <monnier@iro.umontreal.ca> wrote:
>>> But to do the things correctly, that would mean the merge of the
>>> `google-maps.el' and `google-weather.el' modules into Emacs core
>> [...]
>>> The question is, therefore, is there a chance that we could merge these
>>> two extension into Emacs?
>> 
>> Without having thought much about it, my reaction is rather negative,
>> since we do not want to install packages dedicated to supporting
>> proprietary software.

LB> What about elpa? Could this perhaps be more relaxed regarding
LB> supporting proprietary software? Or should there be a special elpa
LB> repository for it? (Is that possible with the current elpa version?)

You can set up your own ELPA repo, sure.

I think it's better for org-mode to support a generic maps and weather
plugin so users can write Google-specific ones (and put them on their
own ELPA repos) but don't have to.

I was in a similar situation with Google Reader and planned to write an
interface to it until the much better gwene.org came along (thanks to
Lars) to let me read RSS feeds in a sensible way.

Ted

Re: Google modules integration

[Jambunathan K]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Fri, Sep 10, 2010 at 12:25 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> But to do the things correctly, that would mean the merge of the
>>> `google-maps.el' and `google-weather.el' modules into Emacs core
>> [...]
>>> The question is, therefore, is there a chance that we could merge these
>>> two extension into Emacs?
>>
>> Without having thought much about it, my reaction is rather negative,
>> since we do not want to install packages dedicated to supporting
>> proprietary software.
>
> What about elpa? Could this perhaps be more relaxed regarding
> supporting proprietary software? Or should there be a special elpa
> repository for it? (Is that possible with the current elpa version?)

I think the crucial question would be what is the nature of the
underlying protocol that is used for retrieving the data.

It is easier to think in terms of below scenario:

For example, I can use gnus to post and retrieve my email through gmail
servers. This is perfectly ok because the underlying data access
protocol - IMAP/POP - is open. Since the underlying infrastructure is
open gnus need not treat gmail servers in a special way.

A quick look at google-weather.el suggests that it prepares a url and
does some xml parsing on the reply. Gnus also does something similar
stuff when I create an ephemeral group based on a web search (gmane or
google groups)

That said, I know nothing whatsoever about Google APIs or GoogleCL.

Jambunathan K.

Re: Google modules integration

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Fri, Sep 10 2010, Stefan Monnier wrote:

> Without having thought much about it, my reaction is rather negative,
> since we do not want to install packages dedicated to supporting
> proprietary software.

This is not support supporting proprietary software.

This is doing HTTP requests and doing some json or XML parsing on the
replies.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Google modules integration

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Fri, Sep 10 2010, Lennart Borgman wrote:

> What about elpa? Could this perhaps be more relaxed regarding
> supporting proprietary software? Or should there be a special elpa
> repository for it? (Is that possible with the current elpa version?)

That could be a solution, but ultimately, if Carsten wants the
org-google features to work out-of-the-box, I think he will merge the
google-* modules into Org directly.

Then, they would end-up merged in Emacs with Org. So they will be
distributed as core functionalities.

The only down side I see, is that they would be sub-parts of Org,
whereas the google-* modules have nothing to do with Org. They're just
bricks to build org-google-* modules.

So it makes much more sense to integrate them directly into Emacs. I'm
only asking their integration, on behalf of Carsten, to try to do things
correctly.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Google modules integration

[Glenn Morris]

Jambunathan K wrote:

> A quick look at google-weather.el suggests that it prepares a url and
> does some xml parsing on the reply. Gnus also does something similar
> stuff when I create an ephemeral group based on a web search (gmane or
> google groups)
>
> That said, I know nothing whatsoever about Google APIs or GoogleCL.

Me neither, but here are the maps API terms and conditions:

http://code.google.com/apis/maps/terms.html
Google Maps/Google Earth APIs Terms of Service

Various things of interest, eg

  10.8 [you must not] use the Static Maps API other than in an
  implementation in a web browser

You can browse the web from Emacs, but it's not really a web browser, is it?
I dunno...

Re: Google modules integration

[Glenn Morris]

Julien Danjou wrote:

> That could be a solution, but ultimately, if Carsten wants the
> org-google features to work out-of-the-box, I think he will merge the
> google-* modules into Org directly.
>
> Then, they would end-up merged in Emacs with Org. So they will be
> distributed as core functionalities.

Whether or not they end up in Org, if the Emacs developers do not want
them in Emacs, they will not get merged into the Emacs repository.

Re: Google modules integration

[Andy Wingo]

On Thu 09 Sep 2010 22:23, Julien Danjou <julien@danjou.info> writes:

> I recently wrote a couple of module, namely `google-maps' and
> `google-weather', which retrieve various information from the Google
> API.

Why not use openstreetmaps? Also, is there a Free source of weather
information?

Free software people have to hang together :)

Andy
-- 
http://wingolog.org/

Re: Google modules integration

[Andreas Schwab]

Julien Danjou <julien@danjou.info> writes:

> This is not support supporting proprietary software.
>
> This is doing HTTP requests and doing some json or XML parsing on the
> replies.

You are still using proprietary data over a proprietary API, and as
Glenn has pointed out Emacs may not even be allowed to do that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Google modules integration

[Stefan Monnier]

>> Without having thought much about it, my reaction is rather negative,
>> since we do not want to install packages dedicated to supporting
>> proprietary software.

> This is not support supporting proprietary software.
> This is doing HTTP requests and doing some json or XML parsing on the
> replies.

The refusal to include packages dedicated to supporting proprietary
software is purely political, so the technical details you mention
don't matter: the protocol is proprietary (even if built above
standards like json, XML, TCP, ...) and the server software with which
you communicate is also proprietary (tho it probably also uses a lot of
Free Software internally).


        Stefan

Re: Google modules integration

[Thierry Volpiatto]

Andy Wingo <wingo@pobox.com> writes:

> On Thu 09 Sep 2010 22:23, Julien Danjou <julien@danjou.info> writes:
>
>> I recently wrote a couple of module, namely `google-maps' and
>> `google-weather', which retrieve various information from the Google
>> API.
>
> Why not use openstreetmaps? Also, is there a Free source of weather
> information?

I use xml-weather in emacs, but i have no idea what is the status of
these datas.(proprietary or not?)

See http://mercurial.intuxication.org/hg/xml-weather
and
http://www.weather.com/services/xmloap.html

> Free software people have to hang together :)
>
> Andy

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Google modules integration

[Richard Stallman]

    But to do the things correctly, that would mean the merge of the
    `google-maps.el' and `google-weather.el' modules into Emacs core
    packages. We do not want Org to rely on external sources and would like
    to have this in the core functionalities of Org mode.

I see no reason not to do this.  We have nothing against Google Maps
and Google Weather as services, so there's no reason we shouldn't
provide free software to access them.  And no reason it shouldn't
be in or associated with Emacs.

We reject packages whose functionality is support for proprietary
programs.  However, a service is not a program.  The issues about a
service are totally different.  For instance, we disapprove of SaaS
(see gnu.org/philosophy/who-does-that-server-really-serve.html).  But
these services are not SaaS.  As far as I know, they just provide
information.

We should recommend that people not give Google Maps specific
addresses.

Can these programs work via TOR?

Open Street Map is a good thing, and we should encourage people
to use that by preference.

Re: Google modules integration

[Thomas Lord]

RMS, 

About whether or not Google maps is "SaaS" or simply a "service",
you wrote:


> We reject packages whose functionality is support for proprietary
> programs.  However, a service is not a program.  The issues about a
> service are totally different.  For instance, we disapprove of SaaS
> (see gnu.org/philosophy/who-does-that-server-really-serve.html).  But
> these services [Google maps and weather] are not SaaS.  As far
> as I know, they just provide information.

You have defined SaaS this way:

"Software as a Service (SaaS) means that someone sets up a network
server that does certain computing tasks—running spreadsheets, word
processing, translating text into another language, etc.—then invites
users to do their computing on that server. Users send their data to the
server, which does their computing on the data thus provided, then sends
the results back or acts on them directly."

Google Maps (for example) fits your definition of SaaS, even the limited
set of features supported by that emacs package.

Google's primary proprietary "hook" there is, of course, its
proprietary databases.  Given that raw data, rather than simply
and affordably sell copies and let people write their own programs
to use the maps, Google hords the data in order to gain a 
monopoly over what programs may be used to process it.

For example (this example taken from the google-maps.el homepage),
suppose that you want to see a map of Paris -- but you want a 
customized map.  You would like it centered upon 
a particular cemetary of historic significance, you would like to 
highlight some famous landscapes, and you would like to 
compute and highlight a route of travel that hits a customized 
list of landscapes.

Of course, to specify all of that, you will write out 
locations like "Tour Eiffel, Paris" rather than giving 
latitude and longitude.

Two elements are  involved in producing your map:  a lot of 
data - a huge database - plus some programs that take your
input, do some computations on them, and give you back results.

That, per your definition is SaaS and Google Maps is an example.

It is alarming that you say Google Maps is not SaaS in part 
because Google Maps is a very fine example of a set of programs
that Google alone controls and which are fantastically
great for nasty and unwelcome surveillance of users.   In other 
words, Google Maps exemplifies *quite well* the sort of evil 
that can result from proprietary software whether that software
is horded via copyright or via the SaaS mechanism.

>From a broader perspective, I'm not sure that your definition
of SaaS actually excludes many network services at all.  I 
think you've framed the issues awkwardly there.   The report
I owe you (coming up soonish) will suggest a better framing
of the issues.

-t

Re: Google modules integration

[Chad Brown]

On Sep 10, 2010, at 10:47 AM, Thomas Lord wrote:
> About whether or not Google maps is "SaaS" or simply a "service",
> you wrote:

Without digging too deeply into the definitions, I will add that it is 
possible (and relatively common) for unaffiliated third parties to use 
both the software and the database of Google Maps.  Some examples
that I have used myself in the past:

	http://housingmaps.com/ 
	http://mapwow.com/

One uses the map+api to add real estate data to existing Google Maps,
the other uses custom (game-specific) maps in the Google Maps API.

Hope that helps (rather than muddles),
*Chad

Re: Google modules integration

[Thomas Lord]

On Fri, 2010-09-10 at 11:03 -0700, Chad Brown wrote:
> 
> One uses the map+api to add real estate data to existing Google Maps,
> the other uses custom (game-specific) maps in the Google Maps API.
> 
> Hope that helps (rather than muddles),
> *Chad 

It helps to point out something that RMS
should think about:  that Google Maps is 
designed in part to be a proprietary SaaS
"module", to be integrated into other proprietary
SaaS modules from third parties.


-t

Re: Google modules integration

[Sebastian Rose]

Chad Brown <yandros@MIT.EDU> writes:

> On Sep 10, 2010, at 10:47 AM, Thomas Lord wrote:
>> About whether or not Google maps is "SaaS" or simply a "service",
>> you wrote:
>
> Without digging too deeply into the definitions, I will add that it is 
> possible (and relatively common) for unaffiliated third parties to use 
> both the software and the database of Google Maps.  Some examples
> that I have used myself in the past:
>
> 	http://housingmaps.com/ 
> 	http://mapwow.com/


It's illegal to do so, without displaying googles copyright notice on
the map (if you do not buy a commercial license...).

That's the reason for the google icon on http://www.housingmaps.com/ and
ohters. 

It's simply illegal to use google-maps.el.

To use the google maps, you (each and every site) need to register with
google and use an API-key (valid for just one domain, not one legal
person) they send to you (and show the copyright holder's icon...).


   Sebastian

Re: Google modules integration

[Richard Stallman]

We should have the same rules for ELPA as Emacs.  The idea is that
anything in ELPA should be ready for integration into Emacs if we want
to do so.

Re: Google modules integration

[Richard Stallman]

I doubt Google's terms of service have a legal validity
if one doesn't agree to them.

Re: Google modules integration

[Richard Stallman]

Our definition of "free" and "proprietary" is applicable to copies of
programs.  It does not apply to protocols or to services.  They raise
different issues.

    the protocol is proprietary (even if built above
    standards like json, XML, TCP, ...)

We sometimes call a protocol proprietary if we are blocked from
supporting it in free software.  Protocols cause problems when they
are secret, but this one evidently isn't secret.  Patented protocols
also cause trouble, but when the public needs to use them, we try to
implement them in free software nonetheless.

It looks like there is no obstacle to implementing this protocol in free
software, since we're talking about an implementation of it.

					and the server software with which
    you communicate is also proprietary (tho it probably also uses a lot of
    Free Software internally).

Whether a service runs on nonfree software is not a question that
directly affects the people that use the service.  We don't know -- we
can't tell as users -- whether there is any proprietary software on
the server.  If there is, we are sorry for Google's misfortune and
encourage them to replace it soon, but that is no reason to refuse to
deal with them in the mean time.

Re: Google modules integration

[Stephen J. Turnbull]

Richard Stallman writes:

 > We should recommend that people not give Google Maps specific
 > addresses.

Huh?  That's very close to recommending not to use the service!  For
example, in Japan, a difference of even 100 meters frequently means a
completely different route because "you can't get there from here"
(without going back to where you started).  The same is true if
traveling by car where there are many one-way streets, etc.

If you really want to encourage people to use these services in a way
that is compatible with freedom, you need to be more specific about
what the dangers are, and provide recommendations that give users as
much of what they want as possible.  Anything less is grandstanding,
and harmful to freedom.

E.g., if the addresses are public knowledge anyway (eg, the location
of the FSF offices), what's the harm?  Perhaps "not give personal
addresses" is what you mean.

 > Open Street Map is a good thing, and we should encourage people to
 > use that by preference.

This is grandstanding again.  Sure, the choir will use it, but we came
to call the sick, not the healthy, right?

There is a big difference between free software and free information
of this kind.  Free software can, does, and has worked because
proprietary software makes money by *prohibiting* a large part of the
network externality available to software -- ie, the "many eyes"
effect.  Free software can take advantage of the many eyes, and in
this way leverage network externalities.

The map data, on the other hand, doesn't have this aspect anywhere
near as strongly, since the calculations involved are "hard" (not
really susceptible to tuning by J Random Hacker).  Another problem is
that each query is (close to) unique for a given user -- once they
have the information, they don't need to get it again.  They don't
benefit much from "hacking on the information" (whatever that might
mean ;-).  So a proprietary service can capture most of the network
externality and return part of that as a benefit to its users
*without* risking its proprietary advantage.

The bottom line is that unless one believes that free software is more
important than anything else in one's life, one will use the higher
quality service.  And when the faction of "one" that uses Google
vs. OSM is 90% or so, the network externalities are going to work very
much in favor of Google.

So you're going to need more than such a recommendation ... unless you
want to invite another "open source movement" debacle.  The ideas that
led to "open source" apply even more strongly here, and you know how
effective they were in splitting the free software movement.  Please
don't allow that to happen again.

Open-source-advocate-for-the-free-software-movement-ly y'rs,

Re: Google modules integration

[Stefan Monnier]

> We should have the same rules for ELPA as Emacs.  The idea is that
> anything in ELPA should be ready for integration into Emacs if we want
> to do so.

Agreed except in terms of integration and code quality.


        Stefan

Re: Google modules integration

[Richard Stallman]

      Some examples
    > that I have used myself in the past:
    >
    > 	http://housingmaps.com/ 
    > 	http://mapwow.com/

    It's illegal to do so, without displaying googles copyright notice on
    the map (if you do not buy a commercial license...).

It is plausible Google can use copyright to make this requirement on
sites that show the map data to others.  However, getting and viewing
the data yourself is a different issue entirely.

    It's simply illegal to use google-maps.el.

I don't believe it.  I doubt Google either would or could enforce
copyright to stop individual users from looking at the maps.

Re: Google modules integration

[Richard Stallman]

    It helps to point out something that RMS
    should think about:  that Google Maps is 
    designed in part to be a proprietary SaaS
    "module", to be integrated into other proprietary
    SaaS modules from third parties.

I don't think that is a relevant consideration in
deciding whether to make direct use of Google Maps.

Re: Google modules integration

[Richard Stallman]

    Google's primary proprietary "hook" there is, of course, its
    proprietary databases.  Given that raw data, rather than simply
    and affordably sell copies and let people write their own programs
    to use the maps, Google hords the data in order to gain a 
    monopoly over what programs may be used to process it.

This is a lot like the Google search engine: What the service does is
let you look through their data.  That is not SaaS.

      You would like it centered upon 
    a particular cemetary of historic significance, you would like to 
    highlight some famous landscapes, and you would like to 
    compute and highlight a route of travel that hits a customized 
    list of landscapes.

That is still looking at their data
rather than doing your own computing.

    Two elements are  involved in producing your map:  a lot of 
    data - a huge database - plus some programs that take your
    input, do some computations on them, and give you back results.

    That, per your definition is SaaS and Google Maps is an example.

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.

Re: Google modules integration

[Sebastian Rose]

Richard Stallman <rms@gnu.org> writes:
>       Some examples
>     > that I have used myself in the past:
>     >
>     > 	http://housingmaps.com/ 
>     > 	http://mapwow.com/
>
>     It's illegal to do so, without displaying googles copyright notice on
>     the map (if you do not buy a commercial license...).
>
> It is plausible Google can use copyright to make this requirement on
> sites that show the map data to others.  However, getting and viewing
> the data yourself is a different issue entirely.
>
>     It's simply illegal to use google-maps.el.
>
> I don't believe it.  I doubt Google either would or could enforce
> copyright to stop individual users from looking at the maps.

You might be right.  I think I misinterpreted this text here:


http://www.google.com/intl/en_us/help/terms_maps_earth.html
states:

 --8<---------------cut here---------------start------------->8--
 2. Restrictions on Use. Unless you have received prior written
 authorization from Google (or, as applicable, from the provider of
 particular Content), you must not:
(a) access or use the Products or any Content through any technology or
 means other than those provided in the Products, or through other
 explicitly authorized means Google may designate (such as through the
 Google Maps/Google Earth APIs);
(b) copy, translate, modify, or make derivative works of the Content or
 any part thereof;
(c) redistribute, sublicense, rent, publish, sell, assign, lease,
 market, transfer, or otherwise make the Products or Content available
 to third parties;
 ....
 --8<---------------cut here---------------end--------------->8--



Many third party software uses google maps, but I'm not sure, what
applies here and what steps they have to take to use the maps.  If you
want to use google maps on a web site (i.e. provide them for public
use), you need a valid API key which is valid per site, not per person.


A native speaker could start here to find out more:

http://www.google.com/intl/en-us/help/legalnotices_maps.html 


  Sebastian

Re: Google modules integration

[Glenn Morris]

Richard Stallman wrote:

> I doubt Google's terms of service have a legal validity
> if one doesn't agree to them.

Pfft, they thought of that.  ;)

    2.1 [...] In order to use the Maps APIs you must agree to the Terms.
    You can accept the Terms by:
    [...]
    (b) using the Maps APIs. In this case, you understand and agree that
    Google will treat your use of the Maps APIs as acceptance of the Terms
    from that point onwards.

Re: Google modules integration

[Juanma Barranquero]

On Sun, Sep 12, 2010 at 02:36, Glenn Morris <rgm@gnu.org> wrote:

>    (b) using the Maps APIs. In this case, you understand and agree that
>    Google will treat your use of the Maps APIs as acceptance of the Terms
>    from that point onwards.

IANAL, but it seems quite fishy. Assume you argue that you used the
APIs without reading that. Yeah, I know, ignorantia juris non excusat,
but that's not the law, that's a license agreement. So, what would be
your crime, "using an API without reading the license"? :-)

(What I mean is, has someone really tried to defend that kind of
license on a tribunal? Did it work?)

    Juanma

Re: Google modules integration

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

[snip]

> (What I mean is, has someone really tried to defend that kind of
> license on a tribunal? Did it work?)

Not exactly the same issue, but this is scary:

http://www.osnews.com/story/23794/US_Court_Upholds_EULAs_Criminalises_Pretty_Much_All_of_Us

Re: Google modules integration

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Sep 12, 2010 at 02:36, Glenn Morris <rgm@gnu.org> wrote:
>
>>    (b) using the Maps APIs. In this case, you understand and agree that
>>    Google will treat your use of the Maps APIs as acceptance of the Terms
>>    from that point onwards.
>
> IANAL, but it seems quite fishy. Assume you argue that you used the
> APIs without reading that. Yeah, I know, ignorantia juris non excusat,
> but that's not the law, that's a license agreement. So, what would be
> your crime, "using an API without reading the license"? :-)
>
> (What I mean is, has someone really tried to defend that kind of
> license on a tribunal? Did it work?)

I agree that it is infeasible or futile for a big corporation to run
behind individuals (possibly of no 'consequence'). That doesn't preclude
the possibility that it wouldn't or couldn't happen as a practical
deterrent or what the limits of liability would be. (If I can pay more
damages, will they claim more damages? Don't know ...)

I believe there are two things that came up in this thread worth making
a note:

1. Using anonymous proxies so that Google couldn't nail the individual
   user [1].

2. Google using the users to beef up it's database and there being no
   explicit policy on whether these databases would continue to remain
   publicly accessible [2].

That said, plugins under discussion are tools. When these tools are so
simple as to be built with limited effort, withholding of the
availability of the tool within the GNU's official distribution is
unlikely to cause these tools to be hacked or easily available
elsewhere.

Let me also add that, as a small-time Emacs user, it is my moral
obligation that I live without these tools from within the official
distribution or package servers. I am willing to suffer some
inconvenience for locating the package, building it myself or paying for
it as a token of appreciation to how much value I have derived from
software that comes from GNU's stable.

There goes my 2 cents to the donation box :-).

Jambunathan K.

Re: Google modules integration

[Jeff Clough]

If the concern is that Google won't like Emacs talking to it's servers,
rather than theorizing, can someone at the FSF get Google's take on
this?  I know there are a lot of hardcore Emacs users over there, so
finding the way to someone who can give an official answer shouldn't be
too difficult.  I seem to recall Brad Fitzpatrick
(http://www.bradfitz.com/) mentioning that he still uses Emacs for all
of his development over there.  If he won't do, the odds are quite good
that someone on this list either is or knows a member of the Church of
Emacs working there that would be willing to help us get a real answer.

Jeff

P.S.  I think the real danger in all of this is org-mode becoming even
more useful.  I already can't tie my shoes without it.  If it gets to
the point that I can add an appointment to my planner and hit two
keystrokes to insert a link that gives me a map and directions...

-- 
web:  http://www.chaosphere.com
Author of Genesys, a Free Universal Paper and Pencil RPG.
http://www.chaosphere.com/genesys/

Re: Google modules integration

[Richard Stallman]

    > We should have the same rules for ELPA as Emacs.  The idea is that
    > anything in ELPA should be ready for integration into Emacs if we want
    > to do so.

    Agreed except in terms of integration and code quality.

Indeed.

Re: Google modules integration

[Richard Stallman]

	2.1 [...] In order to use the Maps APIs you must agree to the Terms.
	You can accept the Terms by:
	[...]
	(b) using the Maps APIs. In this case, you understand and agree that
	Google will treat your use of the Maps APIs as acceptance of the Terms
	from that point onwards.

I am skeptical that that this is legally binding,
if you don't see it and accept it before using the API.
But IANAL.

Re: Google modules integration

[Richard Stallman]

     > We should recommend that people not give Google Maps specific
     > addresses.

    Huh?  That's very close to recommending not to use the service!

I am surprised you say so, since I use Google Maps.  Instead of giving
an address, I request a town, then look around it and find where it is.

    E.g., if the addresses are public knowledge anyway (eg, the location
    of the FSF offices), what's the harm?  Perhaps "not give personal
    addresses" is what you mean.

I would rather not give any address unless I were going through TOR.

    This is grandstanding again.  Sure, the choir will use it, but we came
    to call the sick, not the healthy, right?

I don't enjoy being insulted.  If you make your point without insults,
I will read it.

Re: Google modules integration

[Stephen J. Turnbull]

Richard Stallman writes:
 >      > We should recommend that people not give Google Maps
 >      > specific addresses.
 > Huh?  That's very close to recommending not to use the service!
 > 
 > I am surprised you say so, since I use Google Maps.

You are not a typical user.

 > Instead of giving an address, I request a town, then look around it
 > and find where it is.

Maybe that works for you, but I assure it won't work for the majority
of people in Japan.  It's possible, but due to both idiosyncracies in
the addresses themselves and the dependence on public transit, with
extremely complex linkage of schedules, pricing, and even physical
connections, nobody with an appointment would do it that way.  It will
take too much time and effort to connect all the relevant information,
when Google Maps or Yahoo Maps will do it all for you, often in less
than one second, and at price zero.

 >     E.g., if the addresses are public knowledge anyway (eg, the
 >     location of the FSF offices), what's the harm?  Perhaps "not
 >     give personal addresses" is what you mean.

 > I would rather not give any address

Again, you are atypical.  You are extremely protective of your
personal freedom.  ISTR you have argued against such institutions as
(legal) marriage because the contract might bind you to a person you
don't feel like being obligated to any more.  You argue that the
purchase of a single proprietary program subjects one to a domination
akin to slavery.  I also suspect that you are more likely to attract
the attention of abusers of such information than most people because
you are a well-known activist.

However, most people are willing to accept that the benefits of
constraining others via such contractual relationships are worth
accepting similar constraints themselves.  Similarly, most people are
willing to accept a small chance that knowledge of the addresses
they're interested in might be abused.

 > unless I were going through TOR.

So go through TOR.  Assuming that, is there a problem with getting a
map to the FSF offices?

 >     This is grandstanding again.  Sure, the choir will use it, but
 >     we came to call the sick, not the healthy, right?

 > I don't enjoy being insulted.  If you make your point without
 > insults, I will read it.

I take issue with the word "insult".  I described your behavior, not
you.

However, I'm sorry it made you feel bad.  Let me rephrase: While
freedom is a universal value, not everyone values it as you do.  In
particular, many people see freedom as a multidimensional,
continuously variable attribute of society.  Many see freedom as a
relative value, which can be compared to and traded against other
values to a more or less limited degree (cf. marriage and purchases of
a single proprietary software program).

In the case of free software, this difference turned out not to
matter, because the open source movement was right: there were (and
are) sufficient economic advantages to free software to give it
momentum in some very strange places (eg, three of the companies most
active in the pursuit of the advantages of monopolized technology:
IBM, Sun, and Apple), as well as among ordinary hackers.  These
companies (well, two of them, anyway) continue to protect and extend
the domain of free software for those economic reasons today, although
they clearly do not hold software freedom as a principle as important
as, let alone more important than, profit.

However, you also were (and are) right.  Somebody has to talk about
freedom itelf, not just as an instrument of economic growth.  Freedom
is an essential value for human beings, and free software is an aspect
of that.  Unfortunately, as freedom-loving as you are, you
nevertheless found it necessary to build a wall between the free
software movement, and the open source movement, many of whose leaders
are just as dedicated to freedom in their own way, though without
making software freedom an absolute value, and who believed that it
was possible to promote software freedom in terms of its instrumental
values, rather than for its own sake.

What I fear is that you will once again draw a line between yourself
and those not as extreme as yourself, over the database-ization of
social networks, not just those which we call "social networks"
(F***B**k and friends), but also the implicit networks defined by
people traveling to meet friends or to eat dinner, making phone calls
to their mothers or their brokers, etc.  I fear we will once again
hear of "traitors to the movement" and "backsliders", and so on.  But
this time I think it matters a lot more to the success of the
movement, for the reasons set forth in my previous post.

To summarize those reasons, the economics of software are basically
the economics of programming behavior combined with network economies,
and this promotes growth of free software in several ways which do not
depend on the degree to which users value software freedom (although
of course that is an additional promoting factor).  The economics of
"social databases" (for want of a better name, and I don't think
that's a good one, although it's better than "Web 2.0" :-) is a
combination of network economics (as with software) and those of trade
secrets, which is not going to work strongly for "free social
databases" in the way that it did (and does) for free software.  It is
going to be important that all lovers of freedom work together.  We
will need (IMO) to avoid ostracizing those who find reasons to support
"free social databases" other than the pure value of freedom.

To misquote another great lover of freedom, in this case I fear that
if we don't hang together, we'll all hang separately.

Re: Google modules integration

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Sun, Sep 12, 2010 at 02:36, Glenn Morris <rgm@gnu.org> wrote:
 > 
 > >    (b) using the Maps APIs. In this case, you understand and
 > > agree that    Google will treat your use of the Maps APIs as
 > > acceptance of the Terms    from that point onwards.
 > IANAL, but it seems quite fishy. Assume you argue that you used the
 > APIs without reading that.

You really don't want to go down that road without a lawyer's advice.
An argument of exactly the same form applies to the GPL.

N.B.  It's possible that the GPL's "distribution constitutes
acceptance" is valid while Google's "use of APIs constitutes
acceptance" is invalid.  My point is that this depends on the details
of the laws that the FSF and Google respectively cite in support of
their licensing, thus the need for a lawyer.

Re: Google modules integration

[Glenn Morris]

Richard Stallman wrote:

> But IANAL.

Me neither, but I thought that these were terms imposed on the
_developer_ writing an application that makes use of the APIs, not on
the people who might use that application. Ie, on Julien. (The
responsibility would fall on the FSF were such code in Emacs, as
stated in section 2.3 of the terms.)

If you are writing code to use someone's APIs to access their
database, it does not seem an unreasonable expectation that you should
first check what terms those APIs and the data are made available
under.

OpenStreetMap has much simpler terms.
http://www.openstreetmap.org/copyright

Re: Google modules integration

[Richard Stallman]

    If the concern is that Google won't like Emacs talking to it's servers,
    rather than theorizing, can someone at the FSF get Google's take on
    this?

That could be asking for trouble.

If we need to check, I will do it by asking a lawyer.
We don't get our legal advice from Google.

Re: Google modules integration

[Richard Stallman]

     > IANAL, but it seems quite fishy. Assume you argue that you used the
     > APIs without reading that.

    You really don't want to go down that road without a lawyer's advice.
    An argument of exactly the same form applies to the GPL.

These two issues are totally different, in legal terms.  The GNU GPL
simply exercises copyright.  Those "terms of service" try to make
a contract.

Re: Google modules integration

[Richard Stallman]

    Me neither, but I thought that these were terms imposed on the
    _developer_ writing an application that makes use of the APIs, not on
    the people who might use that application.

I see no basis for Google to impose any requirements on the author or
distributor of a program merely because that program is capable
of communicating through the API.

    If you are writing code to use someone's APIs to access their
    database, it does not seem an unreasonable expectation that you should
    first check what terms those APIs and the data are made available
    under.

I don't understand the question very well.
Why should we have any expectations about that question?
And why does it matter whether we do or not?

Re: Google modules integration

[James Cloos]

>>>>> "AW" == Andy Wingo <wingo@pobox.com> writes:

AW> Also, is there a Free source of weather information?

The US NOAA provides substantial current and recent data.

I wrote this tiny script to grab any given station's current data in an
easy to read text format:

,----< metar >
| #!/bin/sh
| for s in "$@"; do
|  station=$(echo -n "$s"|tr a-z A-Z)
|  curl "http://weather.noaa.gov/pub/data/observations/metar/decoded/${station}.TXT"
|  echo
| done
`----

Try >metar nszp< for a dose of the cold.

http://weather.noaa.gov has a lot of other info, too.  Including
forcasts, radar maps, et cetera.

The station data covers the world; the forcast data may be limited to
the US.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Google modules integration

[Jambunathan K]

Richard Stallman <rms@gnu.org> 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.

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.

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

Re: Google modules integration

[Richard Stallman]

You've posed a very broad range of questions, which could only be
treated in the abstract.

For now, I can only say that giving server operators any power to
exclude the use of free software to communicate with the server
is a threat to computer users' freedom.

Re: Google modules integration

[Stephen J. Turnbull]

Thomas Lord writes:

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

I see no (necessary) attack on *software* freedom here.  They're
simply keeping the *data* secret.

"Simple" of course does not mean "good".  It just means that there is
nothing runnable here for the user to study, modify, or redistribute.
Google could quite possibly freely distribute all the software used,
and still maintain a profitable monopoly over the data.  (More likely,
they do have substantial proprietary software involved in the
databases and image generation -- but OTOH they probably want
everything in the Maps API to be free software.)

That's why I think it is a mistake to distinguish between software and
other information (as the Free Documentation License does, for
example).

Re: Google modules integration

[Richard Stallman]

    Also:  is there some reason to not, instead,
    add Open Street Map support to GNU Emacs?

It would be good to add support for talking with Open Street Map.  We
do not a priori have to choose between that and Google Maps unless we
are going to have one command that contacts one or the other site.

Re: Google modules integration

[Richard Stallman]

    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.

This transformation of the data starts to become SaaS, though I doubt
whether it amounts to a significant extent.  It also starts to give
Google more information about your interests.  That is why I don't
specify particular addresses when I use Google Maps, which is why I
did not think of that aspect when we started discussing this.  I just
thought in terms of browsing through maps.

It would be better for the user's client program to get the street data
for the relevant area, and to find specific places and routes locally.

Does Google Maps offer any way to do that?  I gather it does not.

Anyway, we could distinguish different ways of Google Maps: to browse
maps, to specify particular display, to find an address, and to
calculate a route.  We could support some of them and not others.  The
first three are not SaaS, but the last is mildly SaaS.

Re: Google modules integration

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]


Has a consensus been reached out or will this be ignored?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Google modules integration

[Richard Stallman]

    While
    freedom is a universal value, not everyone values it as you do.

People have all sorts of political views, and lots of people totally
disagree with the GNU Project's values.  We respect their right to
advocate their views; however, aside from that, their views are not
pertinent here.  Lots of people think proprietary software is fine,
but that is no reason for us to grant it legitimacy.  They may also
think that SaaS is fine.  That is no reason for us to grant it
legitimacy.

      Unfortunately, as freedom-loving as you are, you
    nevertheless found it necessary to build a wall between the free
    software movement,

It is not a wall, it is a clear distinction.  The distinction shows
the difference between two philosophies based on different values.
It does not restrict what anyone can think.

		       and the open source movement, many of whose leaders
    are just as dedicated to freedom in their own way,

It is true that many open source advocates contribute to programs that
are free.  But it is implausible that many open source leaders
agree with us.  A few say they do, but the rest disagree.

I believe that open source advocates in general say what they really
think, and that they really don't agree with us.  Most of them learned
their values from other open source advocates, who won't have directed
them towards seeing an issue of freedom in the manner of distribution
of software.

    but also the implicit networks defined by
    people traveling to meet friends or to eat dinner, making phone calls
    to their mothers or their brokers, etc.

If I ever envisage taking a stand against that, I will be sure to let
you know.

Re: Google modules integration

[Stephen J. Turnbull]

Richard Stallman writes:

 > Lots of people think proprietary software is fine, but that is no
 > reason for us to grant it legitimacy.

I said nothing about granting legitimacy to things you disagree with.
What makes you think that my point had anything to do with
legitimizing proprietary software or SaaS?  (Except inasmuch as I
believe ineffective advocacy of freedom has the effect of legitimizing
the opposite.)

 >     but also the implicit networks defined by people traveling to
 >     meet friends or to eat dinner, making phone calls to their
 >     mothers or their brokers, etc.

 > If I ever envisage taking a stand against that, I will be sure to
 > let you know.

If you would restore context and explain to me in context why you
understood my words that way, I'll try to do better in the future.

Re: Google modules integration

[Chong Yidong]

Julien Danjou <julien@danjou.info> writes:

> Has a consensus been reached out or will this be ignored?

I agree with RMS that there is nothing wrong in principle with Google
Maps and Google Weather as services, but I dislike the idea of adding
Google branding into Emacs, in the form of "google-maps.el", etc.

(Yes, "Java" and "Javascript" are also trademarks associated with
proprietary software companies, but those are programming languages and
their presence is mostly unavoidable if Emacs is to function as a
programmers' editor.)

Regarding the map package, I think we can include it provided
OpenStreetMaps is used by default, and the package name is changed into
something more generic (net-maps, maybe?), including function and
variable names.  Stefan, WDYT?

Analogous steps could be taken for the weather package (e.g. accepting
the NOAA feed instead of Google's API).

Re: Google modules integration

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Tue, Sep 21 2010, Chong Yidong wrote:

> Regarding the map package, I think we can include it provided
> OpenStreetMaps is used by default, and the package name is changed into
> something more generic (net-maps, maybe?), including function and
> variable names.  Stefan, WDYT?

This is another set of (totally) different function unrelated to what I
wrote so far. I really do not see the point, unless you are offering
your time to write such an alternative.

> Analogous steps could be taken for the weather package (e.g. accepting
> the NOAA feed instead of Google's API).

This does not provide forecast all around the world, so is useless to
the majority of people.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Google modules integration

[Chong Yidong]

Julien Danjou <julien@danjou.info> writes:

>> Regarding the map package, I think we can include it provided
>> OpenStreetMaps is used by default, and the package name is changed into
>> something more generic (net-maps, maybe?), including function and
>> variable names.  Stefan, WDYT?
>
> This is another set of (totally) different function unrelated to what I
> wrote so far. I really do not see the point, unless you are offering
> your time to write such an alternative.

I had the impression that the code could be used with OSM.  On
re-reading the thread, that seems that's not the case.  Too bad.

Re: Google modules integration

[Thierry Volpiatto]

Chong Yidong <cyd@stupidchicken.com> writes:

> Julien Danjou <julien@danjou.info> writes:
>
>>> Regarding the map package, I think we can include it provided
>>> OpenStreetMaps is used by default, and the package name is changed into
>>> something more generic (net-maps, maybe?), including function and
>>> variable names.  Stefan, WDYT?
>>
>> This is another set of (totally) different function unrelated to what I
>> wrote so far. I really do not see the point, unless you are offering
>> your time to write such an alternative.
>
> I had the impression that the code could be used with OSM.  On
> re-reading the thread, that seems that's not the case.  Too bad.

OSM do not have a data base for all the world (Too bad ;-)), the Julien
package is much better, i use it already in my addressbook to show where
my contacts live.Thanks Julien for it.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Google modules integration

[Sebastian Rose]

Julien Danjou <julien@danjou.info> writes:
> On Tue, Sep 21 2010, Chong Yidong wrote:
>
>> Regarding the map package, I think we can include it provided
>> OpenStreetMaps is used by default, and the package name is changed into
>> something more generic (net-maps, maybe?), including function and
>> variable names.  Stefan, WDYT?
>
> This is another set of (totally) different function unrelated to what I
> wrote so far.

???

No, it's not.  There are sites online, that offer both as different
views for the same data.

Actually, I can see no reason, why your google-map code cannot be the
actual net-maps API with very little changes.

In many cases, it's just a question of URLs to call.

The maps do not differ too much, do they?
Both use Mercartor projection,
the x and y tile-coords are the same etc. 
For both, name services are available,
for both a HTML/JavaScript map can easily be included in web pages.
Both use the same way to zoom in and out (shifting, naturally).



Look at these two URLs for a tile:

Google:

  http://khm.google.com/vt/lbw/lyrs=m&hl=de&x=34535&s=&y=21537&z=16&s=Galile

OSM:

  http://b.tile.openstreetmap.org/16/34535/21537.png


Note the better Details, especially the bar ;) In forests the difference
is _much_ bigger.  And in areas with lot's of bars :)



> I really do not see the point, unless you are offering
> your time to write such an alternative.


Maybe I could be of any help.  I'm sure I could learn something.


  Sebastian