My understanding is that the original reason for "free software" builds was that the release versions of Firefox 1 and 2 used Talkback -- which is neither free software nor open source -- for crash feedback/reporting. Releasing a build without Talkback gave people an option to download an official build that did not include closed, non-free software. Firefox 3 no longer uses Talkback; Brakepad has replaced it and is free software. So, that's not an issue for Firefox 3. What remains is the somewhat contentious issue regarding the copyright/trademarks of the official branding artwork. I believe that's a orthogonal issue, and incorrectly implies that the normal (branded) Firefox 3 releases are somehow not free software. Based on the above, I would either: A) Mark this bug as invalid, no further action needed (per argument above). or B) Release official unbranded builds, but just call them "unbranded" (instead of "free-software"). I don't think (B) is a productive use of resources, but I don't oppose it in principle. [Also, see bug 385783, concerning automating the "free-software" build process.]
I don't think we ever really should have been doing the FS builds, but I certainly don't think we need to do them now that we've removed talkback.
11 years ago
Status: NEW → ASSIGNED
Priority: -- → P2
11 years ago
Assignee: nobody → joduinn
Status: ASSIGNED → NEW
This is WONTFIX in it's current state, see c1 and c2. Do we need to ship "unbranded" builds? I'd like to know who wants them and why, we can probably come up with something better for them.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
Sorry joduinn, I thought this was unowned for some reason.. are you working on this or should be leave it closed for now?
Reopened, as I'm still working on this. Sorry, I should have updated this before now. From asking around, it seems the main reason for "free software" builds was to do with avoiding including branding, as well as proprietary talkback code in the 1.8 branch. For trunk/1.9, we dont have talkback included, so its just an unbranded build, which anyone can do with source tarball or cvs access. I need to post to newsgroups, forums, blogs to make sure I'm not missing something. With the info I've received so far, I will be marking this bug as WONTFIX, unless some new info comes to light.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
10 years ago
Priority: P2 → P3
10 years ago
Summary: Firefox 3.0 Beta 2 — create unbranded, “free software” builds → Do we need unbranded "free software" builds for Firefox 3.0?
Well, for my personal use, I would like to see free software builds. For those who don't want to accept the Firefox EULA. Another possibility would be of course to open source the artwork, so Firefox would be Open Source again. And of course keep the actual policy about the trademark. But I don't think trademark protection needs Firefox to be non free software (as it is the case actually).
(In reply to comment #6) > Well, for my personal use, I would like to see free software builds. For those > who don't want to accept the Firefox EULA. You really just want bug 435588, right?
The lack of non-free logos could be useful for making free screenshots, like for Wikimedia Commons — particularly, screenshots of dialogs, and screenshots where Firefox is not a very important part of the screenshot (so the screenshot can stay, and the Firefox bits in it can stay). Fair use is not allowed on Commons. I don’t list the complete screenshots of Firefox above, because in the default configuration, both Firefox, IceCat, Iceweasel etc have non-free icons on their toolbars.
We (that is, harvey and I at the moment) are currently considering the future of and use cases for these builds. There are potential uses for an unbranded but otherwise-identical Firefox (which is basically the same thing as a Free Software build now that the talkback question is resolved). But we have to figure out whether making them useful would be too much effort (e.g. another 150 versions of Firefox!) In the mean time, please keep doing them for Firefox 2, but you don't need to start for Firefox 3 yet. Gerv
Putting back in the pool until Gerv/Harvey get to the bottom of this.
Assignee: joduinn → nobody
Status: REOPENED → NEW
Component: Release Engineering → Release Engineering: Future
QA Contact: build → release
Gerv/Harvey: any update on this?
The update is that with the recent changes related to the EULA, and the accompanying release of the Firefox logos under the appropriate free software copyright licences, our position is that people should have no further objection to the copyright Freeness of the standard Firefox builds. So there is no need for a separate set of builds. Note that the Mozilla Foundation still reserves trademark rights in the Firefox name and logo, but we assert that this is compatible with the software being free. I'm sure anyone who disagrees with us about this will let us know :-) Gerv
Status: NEW → RESOLVED
Last Resolved: 11 years ago → 10 years ago
Resolution: --- → WONTFIX
(In reply to comment #12) > accompanying release of the Firefox logos under the appropriate free software > copyright licences Um, what? The license of the Firefox logos hasn't changed, at least as far as I know! I don't disagree with WONTFIX here, but I don't think the logo license has anything to do with it.
Gavin: the new EULA is MPL-based. All of the code which makes up a release Firefox binary is under the MPL, and that includes the Firefox images. (Again, I reiterate that this doesn't affect the trademark status of the logo depicted.) Because that's so, there is no code, data or binary in a standard Firefox distribution which could be considered non-free. We therefore assert that special free builds of Firefox are no longer necessary as they once where when e.g. we shipped Talkback and non-free logo files. Gerv
(In reply to comment #14) > Gavin: the new EULA is MPL-based. All of the code which makes up a release > Firefox binary is under the MPL, and that includes the Firefox images. (Again, > I reiterate that this doesn't affect the trademark status of the logo > depicted.) No, the new EULA does not grant additional rights to the Firefox logos. That's explicitly mentioned in the new text, seen in attachment 345447 [details].
(Firefox logos also aren't MPL licensed - they live in other-licenses/ in the tree.)
Isn't gerv saying that they *are* now GPL-licensed, by fiat from the foundation?
In which case, we should probably make that clear here: http://mxr.mozilla.org/mozilla-central/source/other-licenses/branding/firefox/LICENSE
Gavin: it doesn't grant additional rights over and above those granted under the MPL. bsmedberg: yes, that's what I'm saying. The position in the tree is because until recently they _were_ under another license. Yes, we should change that file :-) Gerv
That's a pretty strange interpretation of the text. It explicitly says "does not grant you any rights". I am not a lawyer, but as far as I know MPL licensing the Firefox logo image file would make it nearly impossible for the Foundation to protect the trademark.
I'm not a lawyer either, but that sounds about right to me...
Was "the accompanying release of the Firefox logos under the appropriate free software copyright licences" like... *published* anywhere? Or are you talking about something which may or may not happen at some time in the future?
Trademark law and copyright law are not the same thing. One can offer copyright rights and not trademark rights, or vice versa. If I draw a version of the Coke logo, I own the copyright, but that doesn't give me the right to use it to label cans of dark brown fizzy stuff. Similarly, people may have MPL rights to the file containing the Firefox logo, but that doesn't give them the right to use it to label their browser. Gerv
The rights granted by the MPL conflict with the rights restricted by trademark law. It doesn't matter what laws define them - it doesn't make sense for them to be in conflict. Anyways, I don't want to get into a legal debate among non-lawyers. Someone who actually knows what the status of the logos is should clear things up, ideally. I don't really know who that is. Mitchell? Harvey?
This is the result of what I agreed with Harvey today (unless I've misunderstood him). So I've asked him to come and comment here. Gerv
Hope this clarifies: Both positions are correct in some respects. There is an apparent conflict on its face regarding TM and copyright law in the context of open source licenses. Arguably the MPL grants copyright rights under the MPL for the logo files; however, what is granted under copyright is not enough to use those logos (files) as a trademark. In this context, use as a TM is when you use the mark as a source identifier (the "label" referred to by Gerv). To use those files in a trademark capacity requires an additional grant that's not provided under open source licenses. An analogy is that sometimes you need both a passport and a visa to gain entry to a country. The MPL doesn't provide TM rights, and in our branded builds we expressly state that those rights are not provided. So TM and copyright law are different, and don't necessarily overlap. Similarly, one can grant copyright rights, but not grant patent rights. In general, this intersection of the two legal domains with open source is not well developed, nor is there really much caselaw on this. To adopt another (contrary) construction however would result in exactly what Gavin described in Comment 20, which is not the intent, nor the result that is generally accepted. Consequently, using the MPL for the unbranded builds (which may include the logo and TM files) does not provide TM rights. A separate question: It was my understanding that in the non-branded builds, the actual logo and TM files were not included? Is this true?
(In reply to comment #26) > A separate question: > It was my understanding that in the non-branded builds, the actual logo and TM > files were not included? Is this true? That's correct.
(In reply to comment #19) > bsmedberg: yes, that's what I'm saying. The position in the tree is because > until recently they _were_ under another license. Yes, we should change that > file :-) Uhm. MoFo *G*PL'd the logo files ...? Citation needed.
(In reply to comment #27) > (In reply to comment #26) > > A separate question: > > It was my understanding that in the non-branded builds, the actual logo and TM > > files were not included? Is this true? > > That's correct. Indeed, and as to the original point of this bug, the nightly builds are now essentially free software builds as they contain only freely licensed code and graphics (ie: no trademarked logos).
(In reply to comment #29) > (In reply to comment #27) > > (In reply to comment #26) > > > A separate question: > > > It was my understanding that in the non-branded builds, the actual logo and TM > > > files were not included? Is this true? > > > > That's correct. > > Indeed, and as to the original point of this bug, the nightly builds are now > essentially free software builds as they contain only freely licensed code and > graphics (ie: no trademarked logos). Thanks for the clarification.
And just to be sure we're clarifying what we want to clarify, there are no current unbranded release builds except for the almost end-of-life 2.0.0.x: that's what this bug was about. "the non-branded builds" are only available as nightly builds with the Minefield (free? not? dunno) branding for the trunk/current release, one of which (which one? the one before, that maybe didn't get a last-second security fix? the one after, that got a post-release regression landing?) will approximately but not exactly correspond to the next release, and with the whatever it was, GranpaRadisio?, branding and the explicitly free art for 3.0.x. Since we do all we can to avoid saying that people should use nightlies, I think we need to not think about those, and if we don't want to provide builds with non-trademarked art and names, then just flat out say "we *will not* provide release builds with non-trademarked art and names."
(In reply to comment #31) > then just flat out say "we *will not* > provide release builds with non-trademarked art and names." Yes, we should do this.
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.