367562 - Trademark Issues with Gmail.RDF

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Carsten Book [:Tomcat]]

With Bug 359900 a Gmail.RDF is now included into the Account Manager and the Label is Gmail and the Accountname name @gmail.com

The Problem i see, is that Google had to rename the Email services to @Googlemail or something else because the name "gmail" is already protected by other trademarks.

DE (Germany): Google has changed name to @googlemail.com ...see http://news.com.com/Behind+Googles+German+courtroom+battle/2100-1032_3-6115056.html

and en-GB, same here:
http://mail.google.com/mail/help/intl/en-GB/googlemail.html

And so to avoid any trouble with possible trademark owners we should take care that we use the correct "gmail" name.

Comment 1

[Scott MacGregor]

we don't need to set both flags.

I'm not sure what you mean. So in certain countries it has a different name?

Comment 2

[Carsten Book [:Tomcat]]

(In reply to comment #1)
> we don't need to set both flags.
> 
> I'm not sure what you mean. So in certain countries it has a different name?
> 

yep, the name "gmail" is protected/already registered in some countries and so gmail has renamed this service there. As Example in Germany you can`t register a @gmail.com Adress anymore and you get a @googlemail.com Adress instead.

Comment 3

[Carsten Book [:Tomcat]]

from http://mail.google.com/mail/help/intl/en-GB/googlemail.html :

Why the name change then?
 
We have been involved in a dispute regarding the Gmail trademark in the UK. Another company has claimed rights to the Gmail name. We have tried to resolve this dispute through negotiations, but our efforts have failed.

We are still working with the courts and trademark office to protect our ability to use the Gmail name, but in the meantime, we want you to have an email address you can rely on. 

Comment 4

[Gervase Markham [:gerv]]

We can use the name "gmail" for internal identifiers and files but yes, we should call it "googlemail" in the UI for the DE and UK builds. :-|

Gerv

Comment 5

[Scott MacGregor]

Wow, what makes this even more complicated is that it sounds like some en-GB users have @gmail.com addresses, and accounts created after a certain date or @googlemail.com and there's no way to know which one we should use.

I'm starting to think we should just not include this rdf file for en-GB and german builds.

Comment 6

[David :Bienvenu]

Or, added a separate google mail one for en-GB and german builds. So we'd have both, which is ugly, but might be better than not having either. Or, just have the google mail one, so that people who sign up for google mail going forward have an easier time with TB.

Comment 7

[Axel Hecht [:Pike]]

This really sounds to me like we should request advice from Google itself.

CCing Mic, too, for the general "Let's hook up a brand name in our product" part of this.

Comment 8

[Gervase Markham [:gerv]]

Scott: I believe that GMail users in the UK and DE can log in with either "[e-mail]" or "[e-mail]". I can certainly do both - and the UI displays me as "@gmail.com" both times (I have a pre-trademark-dispute account).

So I think a reasonable solution is for the gmail.rdf in UK and DE localisations to call it Google Mail in the UI and use "googlemail.com" for new signups and as a label. That covers us from a trademark perspective, and we shouldn't have any problems with a technical perspective. At least, insofar as I understand how this feature works.

Gerv

Comment 9

[Scott MacGregor]

Attachment: gmail.rdf file for en-GB and de

Here's the gmail.rdf file we want to be using for both en-GB and de. I was able to successfully retrieve and send e-mail using this information with my original gmail.com account (i.e. [e-mail] and [e-mail] both work).

Now we need to figure out the l10n build logic.

Comment 10

[Scott MacGregor]

Now the hard part, figuring out the build requirements. We want to allow localizations to ship with their own .rdf files. de and en-GB would ship with this gmail.rdf file for instance. When re-packaging the l10n builds, we want to export any RDF files found in /<locale>/mailnews/base/isp into dist\isp.

Ideally, this would work a bit like dictionary files. The en-us dictionary lives in mozilla\extensions\spellcheck\locales\en-US\myspell\en-US.dic. During l10n repackaging, we run the Makefile in mozilla\extensions\spellcheck\locales which exports any dictionary file it finds in <locale>\extensions\spellcheck\myspell\ into dist\dictionaries.

So something like:

* l10n specific RDF files would be added to the l10n repository here: /en-GB/mailnews/base/isp/
* the l10n packaging foo in mail/locales/Makefile.in should have a line similar to what we do for dictionaries: http://lxr.mozilla.org/mozilla/source/mail/locales/Makefile.in#96 but for mailnews/base/isp
* We need a Makefile for mailnews\base\isp that looks similar to http://lxr.mozilla.org/mozilla/source/extensions/spellcheck/locales/Makefile.in

Comment 11

[Stephanie Daugherty [:sdaugherty]]

And the problem just expanded to all of Europe or at least all EU countries apparently.
http://arstechnica.com/news.ars/post/20070131-8741.html

Comment 12

[Markus S.]

God, why that complicated?
Just let the user enter his e-mail address and pick the correct RDF file automatically as I suggested in Bug 367499.

Comment 13

[Scott MacGregor]

Benjamin's been helping me understand the build changes I'm going to need to make which involve moving the rdf and sfd files into each locale directory. I'm working on that right now.

But if someone else has time to put together the list of locales listed here that are effected by this decision, that would be helpful. I'll make sure those locales get the googlemail configuration file. 

http://lxr.mozilla.org/l10n-mozilla1.8/source/

On the surface, it sounds like every country in the EU is effected or is it ever country in Europe, and are the two equivalent :)

Comment 14

[Scott MacGregor]

Attachment: work in progress

The first step is to move all of our .rdf and .sfd file into mail\locales\en-US\isp. Then add logic to mail\locales\Makefile.in to export these files.

Comment 15

[Scott MacGregor]

Attachment: build & en-US changes

Benjamin/Axel, if either of you have a few cycles this weekend, can you give this patch a once over? We're hoping to get this sorted out in time for the thunderbird 2 final code freeze Monday night. Thanks!

This patch does the following:
*Moves .sfd and .rdf files into a locale specific directory, mail\locales\en-US\isp from
* Changes to packages-static to treat bin\isp\* as a locale package
* mail\locales\Makefile.in - export the isp related files for the given locale

I've tested against en-GB where I've made corresponding changes to verify that this works. Both the repackaged en-GB zip and installer builds had the files I expected to see in <path to exe>\isp.

Comment 16

[Scott MacGregor]

Attachment: locale specific changes for en-GB

And here's the corresponding locale changes to en-GB. I would be repeating this particular patch for each locale in the source tree (although not all of them would get googlemail.rdf of course).

Comment 17

[Benjamin Smedberg]

Comment on attachment 257143 [details] [diff] [review]
build & en-US changes

>Index: mail/locales/Makefile.in

> 	$(RM) -r $(STAGEDIST)/searchplugins \
> 	  $(STAGEDIST)/dictionaries \
>+	$(STAGEDIST)/isp \
> 	  $(STAGEDIST)/chrome/en-US

indentation should be tab-space-space

Comment 18

[Scott MacGregor]

I'm using googlemail.rdf instead of gmail.rdf for the following countries:

bg
ca
cs
da
de
el
en-GB
es-es
eu
fi
fr
fy-NL
ga-IE
hu
it
lt
mk
nl
pl
pt-pt
ro
sk
sl
sv-se
tr

That was based on the a list of countries that belong or are official candidates to become part of the EU based on wikipedia. 

Comment 19

[Scott MacGregor]

Attachment: patch for all of the locales

Here's the patch that moves our rdf and sfd files into each locale.

Comment 20

[Scott MacGregor]

I was planning on checking this in for our code freeze tonight, but I don't have the guts to check this change in without getting a general sign off from Axel on what I'm doing so I'd rather wait even if it means slipping the freeze until tomorrow. :)

Comment 21

[Marek Stępień [:marcoos, inactive]]

(In reply to comment #18)
> I'm using googlemail.rdf instead of gmail.rdf for the following countries:
> That was based on the a list of countries that belong or are official
> candidates to become part of the EU based on wikipedia. 

I don't think it's right. GMail is GMail in the Polish, Czech and French versions.

Also, I don't think that comment 11 and Ars article is right at all, that guys g-mail trademark is only registered in a few German-speaking countries, not across all EU.

I think we should first consult Google here.

Comment 22

[Gervase Markham [:gerv]]

I called a contact at Google this morning. He did a little phoning around and searching. He couldn't get anyone to give me a definitive answer, but said that having reviewed the internal material, he was pretty convinced that it was just the UK and Germany which are affected at the moment.

Yes,
http://arstechnica.com/news.ars/post/20070131-8741.html
claims it's now a problem in all of Europe. But then so did 
http://business.timesonline.co.uk/tol/business/industry_sectors/technology/article580354.ece
back in 2005. Even the Ars Technica article admits the legal process is not finished.

To see what Google is actually doing for a particular country, visit:
http://mail.google.com/mail/help/intl/fr/whatsnew.html
substituting the country code ("fr") for the one you are interested in. I just did this for almost everything on mscott's list, and en-GB and de were the only ones to use the GoogleMail branding. (I couldn't see Help for es-es, fy-NL, ga-IE, mk or pt-pt using this method).

So let's go with what is current now, and what Google uses on its web properties, and stick with just doing it for en-GB and de.

Gerv

Comment 23

[Scott MacGregor]

Gerv, thanks so much for doing that research! I'll make the adjustment for just en-GB and de.

Comment 24

[Scott MacGregor]

Attachment: a much better solution

Axel and I came up with a *much* better way to do this. I'm glad I was chicken last night :).

This patch contains: build, en-US and en-GB changes demonstrating the new solution.

Thunderbird can read these ISP files from both bin\isp and bin\isp\AB-CD. Put the files that aren't changing on a per locale basis in bin\isp (which is what we already do today so no change there). Put the locale specific files (gmail/googlemail) in bin\isp\AB-CD.

This is done by:

Add googlemail.rdf to mailnews\base\ispdata. Each locale has an isps.txt file much like we have for browser search plugins:
http://lxr.mozilla.org/mozilla1.8/source/browser/locales/en-US/searchplugins/list.txt

and use a similar build foo to package up the selected files into bin\isp\AB-CD.  isps.txt is where we list either gmail or googlemail. 

When packaging up builds, everything in bin\isp is associated with the [mail] package in packages-static. Everything in bin\isp\AB-CD\ gets associated with [@AB_CD@].

This reduces duplicating all of these shared files everywhere, while still supporting locale specific RDF files. 

With this patch for en-US builds all of the shared rdf and isp files end up in 
bin\isp. gmail.rdf is placed in bin\isp\en-US. 

For en-GB, all of the shared files end up in bin\isp. googlemail.rdf is placed in bin\isp\en-GB.

I've verified this works for en-GB in both the installer and the ZIP builds.

Comment 25

[Axel Hecht [:Pike]]

Comment on attachment 257613 [details] [diff] [review]
a much better solution

Yes, this looks good to me.

I take it that you'll land an l10n/$(AB_CD)/mail/isp/isps.txt for all locales?

Sending this over to Benjamin to check his build foo, too.

Comment 26

[Benjamin Smedberg]

Comment on attachment 257613 [details] [diff] [review]
a much better solution

I'm not sure why we're shipping them to isp/<locale>/ now... what problem does that solve? Seems to me this should be like searchplugins, which go directly to searchplugins/, not searchplugins/<locale>/

Comment 27

[Axel Hecht [:Pike]]

Doing it in <locale> might get us closer to the expected behaviour for locale-changing sidegrades. Sadly, we don't have Firefox:UpgradePolicy finished or public, it's intranet only right now and not set in stone.

Comment 28

[Scott MacGregor]

In addition to Axel's answer, pushing the locale specific isp files into isp/locale helps with:
* it makes it easier for the zip repackaging to remove isp/en-US/* when packaging up another string. If the locale specific files are grouped with the shared isp files for all locales, in isp that gets harder.
* It makes the packaging in packages-static easier in that isp\* gets grouped with [mail] and isp\AB_CD\* is part of the [AB_CD] package. That makes it easier for the install repackaging step for locales keeping them from picking up locale specific isp files for the en-US build.

Comment 29

[Benjamin Smedberg]

Comment on attachment 257613 [details] [diff] [review]
a much better solution

So, the code doesn't have special logic to look in isp/<locale> ?

It just looks in isp/ recursively? I guess that's ok.

Though if you really wanted to support locale-changing sidegrades, you'd have to do something like removing all of isp/ in removed-files.in

Comment 30

[Scott MacGregor]

(In reply to comment #29)
> (From update of attachment 257613 [details] [diff] [review])
> So, the code doesn't have special logic to look in isp/<locale> ?
> 
> It just looks in isp/ recursively? I guess that's ok.

Actually the mail backend specifically looks for files in isp, isp/AB_CD and any enabled extension that has an isp or an isp/AB_CD directory. It does not recurisvely search through every sub directory in isp.

Comment 31

[Scott MacGregor]

Attachment: changes for all of the locales

For historical purposes, here's the patch for each locale that I'll be landing as well. Note the en-GB and de have googlemail listed in their isps.txt file. Everyone else has gmail.

Comment 32

[Scott MacGregor]

I've landed this on the trunk and the branch so it should be in tomorrow's builds.

QA: to test:

1) verify that en-GB and de both show googlemail instead of gmail in the account wizard. Bonus points to verify that you are able to access your gmail account.
2) Verify that en-US and other locales show gmail in the account wizard and for one of these locales, verify that you are able to access your gmail account.
3) Try installing say an en-GB build on top of an en-GB beta 2 build. Verify that you no longer see gmail in the account wizard. This helps test that we properly removed the old gmail.rdf file for en-GB and de.
4) Make sure on the mac that dotmac still shows up
5) Make sure on unix that movemail still shows up
4) Bonus points, look in the installation directory for a locale after installing and verify that: <path to exe>\isps\AB_CD contains either gmail.rdf or googlemail.rdf.

Comment 33

[Scott MacGregor]

I tested en-GB on Windows and Mac today and both of them were doing the right thing.

Comment 34

[Carsten Book [:Tomcat]]

(In reply to comment #32)

Hi Scott

> 
> 1) verify that en-GB and de both show googlemail instead of gmail in the
> account wizard. Bonus points to verify that you are able to access your gmail
> account.

Verified fixed for 1.8.1.3 with 
Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803
and 
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803

and also for Linux:

Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803 - Fedora FC6

The Account Wizzard and Account Manager shows now Google Mail and no longer Gmail. 

Also passed tests to access a Google Mail Mailbox, using one of my gmail testaccounts.

> 2) Verify that en-US and other locales show gmail in the account wizard and for
> one of these locales, verify that you are able to access your gmail account.

Also verified with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803

Account Manager/Wizzard shows Gmail. 
Also PASS..access to gmail Account. Sending and receive of Emails is working fine. 

> 3) Try installing say an en-GB build on top of an en-GB beta 2 build. Verify
> that you no longer see gmail in the account wizard. This helps test that we
> properly removed the old gmail.rdf file for en-GB and de.

Tests PASS, using Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803
and 
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803

on top of the "old" Thunderbird 2 Beta 2 Installations.

Installation Manager show Google Mail instead of Gmail. 


> 4) Make sure on the mac that dotmac still shows up

maybe someone with a mac need to confirm this, since i don`t have a mac

> 5) Make sure on unix that movemail still shows up

Verified fixed for 1.8.1.3 using Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3pre) Gecko/20070308 Thunderbird/2.0pre ID:2007030803 on Fedora Core.

Unix Mailspool (movemail) is still displayed under linux.

> 4) Bonus points, look in the installation directory for a locale after
> installing and verify that: <path to exe>\isps\AB_CD contains either gmail.rdf
> or googlemail.rdf.
> 

also here verified fixed, the rdf on Thunderbird 2 l10n nightly de and en-GB contains googlemail.rdf

Comment 35

[walter sheets]

I'm getting segfaults in trunk because tb is trying to write a SpamAssassin temp file to a directory belonging to root:

#1  0xb71047df in CrudeFileCopy (in=0x8a43368 "/tmp/tmprules.dat", 
    out=0x8a4c148 "/usr/local/lib/thunderbird-3.0a1/isp//tmprules.dat")

My (perhaps flimsy) reason for posting this here is the name
of the target directory.  That's the tenuous connection to 
this bug fix.  (And my segfaults started about Mar 08.)

The code that is trying to do the write is found in
msMsgFilterService.cpp between lines 157-183.  The problem
seems to be that parentDir points to the wrong directory(?)

Comment 36

[walter sheets]

Aha!  I have important details.  I now have two directories 
named 'isp':

#find /usr/local/lib/thunderbird-3.0a1 -name isp
/usr/local/lib/thunderbird-3.0a1/defaults/isp
/usr/local/lib/thunderbird-3.0a1/isp

When I move SpamAssassin.sfd from 'isp' back to its original 
location in 'defaults/isp' my segfaults disappear.

Comment 37

[Scott MacGregor]

Walter, do you see this crash on the branch too? I can't think of a reason why we'd be writing a file called tmprules.dat into your isp directory, I find that alarming. 

Comment 38

[Peter Lairo]

What if someone speaking one language (e.g., an American) is living in another country (e.g., Germany) and downloads/uses only English software. Will that person get @gmail,com or @googlemail.com?

Is the RDF file selected based on which locale the download has (not good), which "Location" (WinXP) is set in the OS (better)?

PS. It would be great if Thunderbird offered the top n pre-configured ISPs for each country (e.g., Germany: web.de, gmx.de, freenet.de, t-online.de, aol.de, etc.). That would mean that the ISP-selection would need to move to *after* the "New Account Setup" dialog.

Comment 39

[Axel Hecht [:Pike]]

All we can do here is a reasonable compromise, as we can't really geolocate our users. Like, what happens if someone travels with his US-based laptop into Germany?

In addition, I don't see us doing regional ISP setups anytime soon, as that'd require business development resources.

Comment 40

[walter sheets]

(In reply to comment #37)
> Walter, do you see this crash on the branch too?...

BTW, I'm running my own nightly builds from CVS because the
nightly linux builds on mozilla.org are out of date.  I must
confess I've never known what 'the branch' refers to.  If you're trying to narrow down the source of my segfaults I can now say for certain that your check-in of 3-07 at 22:38 is it.  (Verified by using MOZ_CO_DATE multiple times.)

I'd like to know where the SpamAssassin temp files are *supposed* to be stored -- do you remember?

Comment 41

[Scott MacGregor]

(In reply to comment #40)
> (In reply to comment #37)
> > Walter, do you see this crash on the branch too?...
> 
> BTW, I'm running my own nightly builds from CVS because the
> nightly linux builds on mozilla.org are out of date.  I must
> confess I've never known what 'the branch' refers to. 

Branch builds can be found here: 

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/

> 
> I'd like to know where the SpamAssassin temp files are *supposed* to be stored
> -- do you remember?

This file should never get written back out to disk by Thunderbird. Let's get this spun out into a new bug, can you file it on me? Thanks!