Closed Bug 53937 Opened 20 years ago Closed 19 years ago
[TRADEMARK] PSM in mozilla
.org tree has Netscape brands
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
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 <firstname.lastname@example.org> - 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.
Assignee: ddrinan → mozilla
Oh, it's the Daemon, not client lib. Sorry for the spam. Bob, see above.
QA Contact: junruh → lord
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 Netscape->NSS. 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.)
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 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.
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.
> 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.)
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 "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.
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.
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?
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 :-) Gerv
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.
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? Gerv
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.)
Target -> 2.0
Target Milestone: --- → 2.0
Fixed in PSM 2.0
Status: ASSIGNED → RESOLVED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.