53937 - [TRADEMARK] PSM in mozilla.org tree has Netscape brands

Status: VERIFIED FIXED

(Core :: Security: PSM, defect, P3)

Description

[Ben Bucksch (:BenB)]

Reproduce:
1. Build PSM from vanilla mozilla.org tree following build instructions on
www.mozilla.org
2. Install the resulting xpi
3. Tools|Privacy....|Security Manager

Actual result:
The upcoming window states "Netscape Personal Security Manager"

Expected result:
No trademark infrigements

Comment 1

[Ben Bucksch (:BenB)]

See also <http://lxr.mozilla.org/mozilla/source/security/nss/trademarks.txt>.

I have a patch, covering most of the problems. Taking bug for now.
I changed
- "Netscape Personal Security Manager" to just "Personal Security Manager"
- "Netscape <modulename>" to "PSM <modulename>"
- "Netscape 6 [PR3]" to "Mozilla"
- "Communicator" to "Netscape Communicator 4.x" (the Mozilla suite is also
called Communicator)
- Feedback links to <[e-mail]>
- Manufacturer to mozilla.org, copyright to "Contributors ...", licence to
MPL/NPL
- N-logos (completely removed them)
- Some other things I might have missed

There is an (XXX) in the release notes where I'm not sure about the path name.

The patch also (still) contains links to my site. I left them in, because the
alternative - links to iPlanet only - currently provides only binaries with a
proprietary licence, and mozilla.org doesn't provide PSM binaries / release
notes at all. I leave it up to you, what to do with that, as long as mozilla.org
doesn't provide these binaries.

Please review. What are the checkin rules for NSS/PSM?

Remaining work:
- Netscape has to set up some diffs in its propietary tree or however it manages
the diffs between Mozilla and Netscape 6, to keep its branding for its own
distribution.
- Remove references to iPlanet products from release notes (move them to a
"third-party tools" link on mozilla.org or similar).
- Check source more carefully.

Bug 53961 is related.

Comment 2

[Ben Bucksch (:BenB)]

Attachment: Fix, Step 1, Version 1

Comment 3

[Ben Bucksch (:BenB)]

Oh, it's the Daemon, not client lib. Sorry for the spam. Bob, see above.

Comment 4

[John Unruh]

Changing QA contact to nitinp

Comment 5

[Javier Delgadillo]

Most of these changes convert Netscape->PSM.

I'm not so sure that's the right thing since alot of these are for NSS libraries 
which will be used by server products.  Perhaps it should be changed from 
Netscape->NSS.

Adding members of NSS team for comments.

Comment 6

[Ben Bucksch (:BenB)]

Yes, you're right. Changing PSM->NSS is a not an issue, I think. Howver, note
that many end-users see these NSS strings in the UI and might be confuses about
what NSS is ("Personal Security Manager" stands large on the top, so "PSM" is
not so much a problem).

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I concur that in the NSS files, the string should be NSS, not PSM.
PSM is documented to be built on NSS.  PSM users should not be 
surprised to see the NSS string.  OTOH, our server customers do not
expect to ever see PSM in any of the NSS stuff they use.

Comment 8

[Ben Bucksch (:BenB)]

> PSM is documented to be built on NSS.  PSM users should not be 
> surprised to see the NSS string.

Is this really documented for PSM *end-users*? Where?

(I will make the change, we just need to figure out how not to confuse users.)

Comment 9

[Ben Bucksch (:BenB)]

Attachment: Fix, version 2

Comment 10

[Ben Bucksch (:BenB)]

I did the proposed change (Use "NSS", not "Netscape" or "PSM", in NSS).

Patch also contains a small Makefile change which is required to amke things
work for me.

Comment 11

[Ben Bucksch (:BenB)]

Can somebody please review? Nelson, javi, could one of you please review the NSS
changes? Who is responsible for PSM?

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Since mozilla is not a company, I'd say it is incorrect to list 
mozilla.org in places where the name of a real legal entity is 
obviously intended, such as in PKCS#11 manufacturer name, and
elsewhere.

Otherwise the NSS portion of this looks OK to me.
I haven't reviewed all the PSM parts.

Comment 13

[Ben Bucksch (:BenB)]

Nelson, mozilla.org is the provider of the source. Yes, it is no legal entity,
but is that *required*? What would you use otherwise? You cannot use "Netscape",
otherwise Netscape might sue me for using its trademarks for my distribution.

Comment 14

[Ben Bucksch (:BenB)]

> You cannot use "Netscape",

Not to mention the fact taht it would  be simply wrong, because as soon as my
patch is applied, it is a combined work of Netscape and myself, with other, much
more significant contributions by others to come, hopefully. So, the correct
term would be "Contributors to the Mozilla codebase" (compare <about:> in
Mozilla Communicator), but I perfer the shorter mozilla.org, personally.

The onyl alternative I see would be to make the name configurable. However,
forcing distributors to change each of the many instances is not acceptable - we
would have to provide a central place where to set this and then use this value
everywhere. But this is a much larger change than I am willing to do, currently.
(Partly because some instances have to have a certain, fixed string-length, see
above.)

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

In the case of the PKCS#11 soft token, whatever legal entity is 
building and distributing the token is its manufacturer and needs
to identify itself.  If some "set top box" mfr puts this code in 
their box, they're the mfr of the token, not mozilla, not netscape.

Comment 16

[Ben Bucksch (:BenB)]

What instance are you concerned about, specifically? Because the only instance
of "mozilla.org" in NSS is in
mozilla/security/nss/cmd/modutil/specification.html (a documentation file for an
commandline tool), in an example output.

The *module* calls itself "NSS Internal PKCS #11 Module", which, I argue, is OK,
given that the distributor of NSS probably identifies itself somewhere else
(e.g. in a README file or similar) anyway. If you disagree, please explain *why*
it is a requirement for the vendor to identify itself in this place.

The only other places where "mozilla.org" appears in the patch as vendor are in
psm/ui/psm_text.properties.in and mozilla/security/psm/server/psm.rc. That's IMO
correct, because mozilla.org *is* the distributor.


Generally:

IMO, it should be possible to compile source from mozilla.org and distribute it,
without any changes other than a README for the whole package where the
distributor identifies itself and tells which licence applies and the user where
to get the source.
It must not be that Netscape can sue a naive distributor, just because it forgot
to check, if there is any inappropriate left-over from Netscape in the
mozilla.org sources.
So, the source from mozilla.org should ship with "neutral" names. "mozilla.org"
is IMO the obvious choice for a field "CompanyName".
If I'm wrong or you have a better idea, please correct me.

In addition to that, branding *should* be very easy and convient, too.
Preferable, there is only one place in the whole source tree (for all of Mozilla
Communicator, PSM and NSS) where to set the names, URLs etc.. But this is much
more work and would be a new additional bug.

BTW: Filed bug 58170 and bug 58168 about the fixed-size strings.

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Neither should it be possible to sue Netscape/AOL (the legal entity
behind mozilla.org) just because some manufacturer forgot.

The checked out code should build and run.
That is different from saying it should be legally ready for 
shipment by anyone anywhere any time.

Comment 18

[Ben Bucksch (:BenB)]

IMO, the code should be ready to ship.

Why should somebody sue mozilla.org? "NO WARRANTIES". However, "Netscape" is a
trademark, which "mozilla.org" is not.

Mitchell Baker, what do you think?

Comment 19

[Ben Bucksch (:BenB)]

Filed bug 61051 about NSS.
This bug is now only about PSM.

Comment 20

[John Unruh]

Mass reassigning nitinp's bugs to me.

Comment 21

[Ben Bucksch (:BenB)]

We need to resolve this now. wtc?

Comment 22

[Ben Bucksch (:BenB)]

FYI: NSS team OKed the NSS part of the current patch.

Comment 23

[Gervase Markham [:gerv]]

mitchell: ping on this bug :-)

Gerv

Comment 24

[Mitchell Baker]

This looks like a combination of trademark issues and crypto related specifics.
 I don't know if mozilla.org can be the "manufacturer."  I assume this word has
some meaning for it to be included.  

This will have to go to the legal department.  I don't do this sort of stuff
anymore.  No longer have the relevant current info.  Sorry I can't provide an
answer.

can someone provide details of why the "manufacturer" is named?  And it sounds
like the name needs to be changed for each entity distributing a product, even
if this is awkward.

I agree with Ben that the code should be easy to distribute.  But crypto rules
might make this difficult.

Comment 25

[Ben Bucksch (:BenB)]

General note: Every single line that has to be changed for distribution is a
major problem. (I'm not talking about Beonex here, rather smaller distributions
like customized browsers or similar.) So, if you *require* *each* distributor to
modify that line, but sure a have a good, hard, unambiguous reason, not some
fuzzy one (like "People need to take credit for the stuff they distribute").

Comment 26

[Ben Bucksch (:BenB)]

BTW: Since the NSS team already OKed, and NSS contains most of the crypto stuff,
I don't see the cryptography (and related US laws) being the problem.

Comment 27

[Gervase Markham [:gerv]]

nelson: are you able to answer mitchell's questions?

mitchell: has this gone to legal yet, or are you waiting on some answers?

Gerv

Comment 28

[Frank Hecker]

Brendan asked me to comment on this. I gather that the main remaining issue is 
regarding identifying the "manufacturer" of the internal PKCS#11 module. IANAL, 
but I do not believe that the value of this string is legally relevant. It is 
true that there is a "manufacturer" field in the notice that has to be submitted 
to the US Bureau of Export Administration for release of open source code; see 
<http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html>. However 
IMO that is a different issue. The PKCS#11 internal module != the code affected 
by export control, but IMO is only a subset of what would be considered 
"encryption code" in terms of the regulations. Also, with regard to that larger 
set of code, presumably Netscape has already identified itself as the 
"manufacturer" (in the BXA sense) on whatever notice it submitted to BXA. I 
don't see why the BXA would care what the value of the "manufacturer" string is 
for the PKCS#11 internal module; as far as I'm aware this string is simply for 
display to the user and is not relevant to export control.

As to sueing the "manufacturer" I also don't believe that this string is 
relevant to the question of who (if anybody) might have legal liability for the 
PKCS#11 internal module code. IMO that's more a function of which legal entities 
are the copyright holders for the source code (e.g., as noted in the 
copyright notices) and which legal entity is the distributor of the end user 
product (as noted in the other documentation provided in the delivered product).

In summary, I am inclined to agree with Ben Bucksch that there is no harm in 
changing the internal PKCS#11 module "manufacturer" string to be "mozilla.org" 
rather than "Netscape", at least in the mozilla.org code base. (Netscape/AOL is 
of course free to change the string in its own versions of PSM/NSS delivered to 
end users.)

Comment 29

[Bob Lord]

Target -> 2.0

Comment 30

[David P. Drinan]

Fixed in PSM 2.0

Comment 31

[Ben Bucksch (:BenB)]

I can't find any "Netscape" in PSM 2.0 UI. Thanks for keeping this bug in mind
while creating PSM2.

VRFY. Will reopen, if I overlooked something.