Closed Bug 53937 Opened 20 years ago Closed 19 years ago

[TRADEMARK] PSM in tree has Netscape brands


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

1.0 Branch





(Reporter: BenB, Assigned: BenB)




(2 files)

1. Build PSM from vanilla tree following build instructions on
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
See also <>.

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 <>
- Manufacturer to, copyright to "Contributors ...", licence to
- 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 doesn't provide PSM binaries / release
notes at all. I leave it up to you, what to do with that, as long as
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
- Remove references to iPlanet products from release notes (move them to a
"third-party tools" link on or similar).
- Check source more carefully.

Bug 53961 is related.
Assignee: ddrinan → mozilla
Keywords: review
Component: Client Library → Daemon
Oh, it's the Daemon, not client lib. Sorry for the spam. Bob, see above.
QA Contact: junruh → lord
Blocks: 14532
Changing QA contact to nitinp
QA Contact: lord → nitinp
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 

Adding members of NSS team for comments.
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).
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.
> 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.)
Attached patch Fix, version 2Splinter Review
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.
Can somebody please review? Nelson, javi, could one of you please review the NSS
changes? Who is responsible for PSM?
Since mozilla is not a company, I'd say it is incorrect to list in places where the name of a real legal entity is 
obviously intended, such as in PKCS#11 manufacturer name, and

Otherwise the NSS portion of this looks OK to me.
I haven't reviewed all the PSM parts.
Nelson, 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.
> 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, 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
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.
What instance are you concerned about, specifically? Because the only instance
of "" 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 "" appears in the patch as vendor are in
psm/ui/ and mozilla/security/psm/server/psm.rc. That's IMO
correct, because *is* the distributor.


IMO, it should be possible to compile source from 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 sources.
So, the source from should ship with "neutral" names. ""
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.
Neither should it be possible to sue Netscape/AOL (the legal entity
behind 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.
IMO, the code should be ready to ship.

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

Mitchell Baker, what do you think?
Filed bug 61051 about NSS.
This bug is now only about PSM.
Mass reassigning nitinp's bugs to me.
QA Contact: nitinp → junruh
We need to resolve this now. wtc?
FYI: NSS team OKed the NSS part of the current patch.
mitchell: ping on this bug :-)

This looks like a combination of trademark issues and crypto related specifics.
 I don't know if 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

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.
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").
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.
nelson: are you able to answer mitchell's questions?

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

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 
<>. 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 "" 
rather than "Netscape", at least in the code base. (Netscape/AOL is 
of course free to change the string in its own versions of PSM/NSS delivered to 
end users.)

Target -> 2.0
Target Milestone: --- → 2.0
Fixed in PSM 2.0
Closed: 19 years ago
Resolution: --- → FIXED
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.
Product: PSM → Core
Version: psm1.2 → 1.0 Branch
You need to log in before you can comment on or make changes to this bug.