Closed Bug 269460 Opened 20 years ago Closed 19 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: 19 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: 19 years ago → 19 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: