Closed Bug 269460 Opened 21 years ago Closed 20 years ago

make browser use no trademarked names when not called with --enable-official-branding

Categories

(Firefox :: General, defect, P2)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox1.5

People

(Reporter: blakesley, Assigned: benjamin)

References

Details

Attachments

(2 files)

Add --with-branding=path/in/tree
27.31 KB, patch
chase
: review+
shaver
: approval1.8b4+
Details | Diff | Splinter Review
Warn instead of Error
541 bytes, patch
benjamin
: review-
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: This is a request that executable binaries of Firefox compiled entirely from CVS (with no proprietary components) be available from the FTP server for MacOS X, GNU/Linux & MSW. Reproducible: Always Steps to Reproduce:
This is a Chase issue, not a staging problem
Assignee: zach → cmp
Component: FTP: Staging → Bookmarks
Product: mozilla.org → Firefox
Version: other → 1.0 Branch
This is a Chase issue, not a staging problem
Component: Bookmarks → Build Config
This is not a build issue primarily, it's a code issue. "Firefox" strings are being built even without --enable-official-branding.
Blocks: 286149
Resummarize this bug as the code issue requiring changes in Firefox. Reassign to Ben.
Assignee: chase → beng
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: RFE: free/open-source binaries of Firefox on FTP server → make browser use no trademarked names when not called with --enable-official-branding
QA Contact: myk → cbeard
Move this over to General.
Component: Build Config → General
Whoa, there. RMS says: "It is ok for a free program to be called by a trademarked name, and carry a requirement not to call any modified version by that name, provided it comes with clear instructions for how to remove it so as to comply with the requirement, and that doing so is easy and simple." The Mozilla Foundation has no plans I know of to make builds which are not called "Firefox". We do want to make it easy to change the name (as RMS suggests) - see http://weblogs.mozillazine.org/gerv/archives/007644.html . We also do want to do free binary builds (which involves removing Talkback and changing the EULA). But we have no plans to make builds of "Iceweasel". So this, bug, as currently summarised, is a DONTNEEDTOFIX. Gerv
As now summarised, this is a WONTFIX. As originally summarised in comment 0, it's a duplicate of bug 286149. Gerv
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Actually, I'm not sure I agree with Gerv here. I understand that RMS agrees that free software can have a trademark associated with it. But there is also an advantage to having a codebase which is governed only by the open source licenses -- MPL, GPL, etc. Once we put the "firefox" name (or other trademarked aspects) into the mix then we need to figure out new policies, apply them to the open source codebase and think about the enforcement aspects required by trademark law. In the long run I think that keeping trademark requirements separate from the code will make everyone happier. Someone pulling and building from CVS may very well not want to ever have to think about trademark law. Including "Firefox" strings in the executable makes this difficult or impossible. So I'm inclined to support removing the Firefox strings from the execuables. Mitchell
OK :-) I'm in discussions with chase and bsmedberg about how best to achieve this. Gerv
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: beng → benjamin
Severity: major → normal
Status: REOPENED → NEW
Version: 1.0 Branch → Trunk
This adds a flag --with-branding=other-licenses/branding/firefox which can be used to build with an arbitrary in-tree branding directory. I hope, as a second step, to add a directory for community branding (i.e. --with-branding=other-licenses/branding/firefox-ce).
Attachment #180408 - Flags: review?(chase)
If my original bug was too wide, please make it into a meta-bug. It seems to have been `hijacked' by the name issue (which, as has been said, isn't really a problem as long as it can be easily changed--which probably should be a bug). I was talking more about the proprietary (wrt copyright--not trademarks) artwork and software (e.g.: Talkback, installer) included in the binaries and whatever else may be lurking in there (or even in the CVS)*. [* No one is sure as MoFo claim it is all "free software" and "open source software" even though it is not--which I should point out violates consumer laws--maybe I should file seperately on removing false statements from the WWW site/press releases/&c.]
*** Bug 289968 has been marked as a duplicate of this bug. ***
*** Bug 252361 has been marked as a duplicate of this bug. ***
Note that bug 252361 was about a slightly different issue... It was about making it easy to substitute a string of the builder's choice for all places where Firefox appears, not about just replacing the string Firefox with some other string of Mozilla.org's choice. That is, it was about _re_branding, not _de_branding. I'm not sure I see why that bug is a duplicate of this one, given that this one seems to be pretty focused on debranding.
bz, the patch here allows you to substitute your own branding directory for the "official" one, so that you can use any combination of app name and branding graphics. So, when BenB (or whoever) wants to rebrand the app, they should just configure with --enable-branding=BenB/branding.
Ok... Should I file separate bugs on each item in bug 252361 comment 0, then? None of those seem to be addressed by this patch (though it does provide the mechanism to address them, in general).
Separate bugs are probably overkill; a few well-targeted bugs are welcome, as long as somebody is actually going to fix them.
So, can I reopen bug 252361 for that?
Yes; please retitle the bug when you reopen it.
Attachment #180408 - Flags: review?(chase) → review+
Comment on attachment 180408 [details] [diff] [review] Add --with-branding=path/in/tree Maybe some bitrot here with recent generic/Deer Park branding changes.
Chase, do you want this for 1.8 or shall I bump it to early 1.9?
Priority: -- → P2
We should try for 1.8 if possible.
Attachment #180408 - Flags: approval1.8b4?
Comment on attachment 180408 [details] [diff] [review] Add --with-branding=path/in/tree a=shaver
Attachment #180408 - Flags: approval1.8b4? → approval1.8b4+
This bug (i.e. the ability to select a branding directory at configure time) is checked in on trunk for 1.8b4. Actually putting all the references to "firefox" into this directory is going to take more work, in bug 252361 or elsewhere.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
I think this bug broke Thunderbird. See Bug 302153 for details. We are no longer getting any branding entity files in our builds.
Depends on: 302153
This patch didn't deal with updater.ini, so does that mean it is still fixed? And, what about the installer on Windows?
Sorry for the spam: What about the UA string? nsBrowserApp.cpp still hardcodes the string Firefox AFAICT. Is that a bug?
Yeah, all the individual cases where we hardcode "firefox" instead of using a shell-script-substitution-something should be done in other bugs... this is just the build infrastructure necessary to make it work at all.
Benjamin, I was able to fix the problem with no branding property files showing up in non official builds. But now today's nightly (with official branding) is getting the generic branding. Welcome to Mail/News! Instead of Welcome to Thunderbird
(In reply to comment #29) > Benjamin, I was able to fix the problem with no branding property files showing > up in non official builds. But now today's nightly (with official branding) is > getting the generic branding. I just checked in a supplementary fix to mail/locales/Makefile.in, which had been using the wrong makefile variable.
Hmm, I don't see any reason to Error on use of --enable-branding, for builds other than FF or TB, I have been running with --enable-branding for a while with Suite. To save me time in the chance that Suite drivers (SeaMonkey Council) choose to use SeaMonkey as a trademark name, and distinguish official and unofficial branding steps, liken to FF and TB.
Attachment #190886 - Flags: review?(benjamin)
Yes, that bite me yesterday, too. I don't want to hold hands with my computer just because the build system doesn't like options it's ignoring anyway...
Comment on attachment 190886 [details] [diff] [review] Warn instead of Error The --enable-official-branding flag is a legacy flag, I don't want to perpetuate its use. If suite wants multiple brandings, use --enable-branding=directory
Attachment #190886 - Flags: review?(benjamin) → review-
Blocks: 307299
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: