Closed
Bug 443918
Opened 17 years ago
Closed 16 years ago
Open-Source CVS version of FF forces me to accept proprietary, non-Open-Source EULA (license)
Categories
(Firefox :: General, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: BenB, Assigned: BenB)
References
Details
(Keywords: verified1.9.0.2, verified1.9.0.4, verified1.9.1)
Attachments
(1 file, 1 obsolete file)
1.39 KB,
patch
|
Gavin
:
review+
mconnor
:
superreview+
beltzner
:
approval1.9.0.2+
|
Details | Diff | Splinter Review |
As some of you may remember from the dark old times, mozilla.org is an Open-Source project. Apart from Open Source values (like freedom, privacy, user-centric, fairness), it means at the very minimum to use Open Source licenses (or Free Software licensese, as defined by OSI or FSF).
Unfortunately, Mozilla Corporation derived from that, using a non-Open-Source, proprietary license for the *binary* distributions of Firefox. In that sense, it is no more free than Netscape 6 was, which used a very similar license and almost identical setup (almost completely Open Source source code, but proprietary licences for binaries, and trademark).
So far so bad.
At least the source code is free of that, I lied to myself.
No more. Now, when compiling and starting CVS trunk "browser", I get a EULA which forces me to accept the proprietary license. I am not willing to, preventing me from using the official Mozilla browser. I don't want proprietary software on my computer - that was one of the big reasons why I contributed to Mozilla.
This is an Open-Source project, nothing else. Proprietary licenses have no place here. The removal of this EULA is *mandatory*.
(BTW: The click-through licenses have no effect in Germany, one of Firefox biggest userbases, anyways, clicking "Accept" does not make the user legally accept the license.)
Assignee | ||
Comment 1•17 years ago
|
||
Code:
browser/components/nsBrowserGlue.js (invokation)
function _onProfileStartup
var mustDisplayEULA = true;
ww2.openWindow(null, "chrome://browser/content/EULA.xul",
browser/base/content/EULA.xul/js (window)
browser/base/content/EULA.xhtml (license text)
Quick fix:
1) Just set default pref("browser.EULA.override", true); in CVS browser/app/profile/firefox.js *and*
2) change the content of browser/base/content/EULA.xhtml.
Both are necessary.
2) is necessary, because the Firefox proprietary license has no place in Mozilla CVS, just as little as the Netscape EULA had.
1) is necessary, because click-through licenses do nothing but harass users. As said, they may not even have an effect, and in general, Open Source is for users instead of forcing users. The GPL very explicitly says that it does not have to be accepted by users, and the MPL does not target end-users either.
If you insist on showing this for official Firefox binary releases, you can change this back for the official branding when creating the binaries.
In any case, do not wait for undetermined build system changes to fix this bug. This bug makes the Mozilla browser unfree.
Assignee | ||
Updated•17 years ago
|
Summary: Open-Source, CVS version of FF forces me to access proprietry, non-Open-Source EULA → Open-Source CVS version of FF forces me to accept proprietary, non-Open-Source EULA (license)
Comment 2•17 years ago
|
||
Looks like a duplicate of bug 439604.
Comment 3•17 years ago
|
||
I agree that the EULA should only be displayed for official binaries. Our code licenses already include disclaimers of warranty; if the EULA is to protect our trademarks, then it only needs to be displayed on builds which contain those trademarks. Harvey, what do you think?
Ben: assuming Harvey agrees with me, then the correct fix here is to make the display of the EULA conditional on the official branding flag. Subject to confirmation from the build team, it also makes sense to me to move EULA.xhtml into the other-licenses/branding directory.
If you write a patch for that, I would hope it would get accepted.
Robert: It's not the same. Bug 439604 is about the official Firefox 3 binaries. This bug is about builds from CVS/Hg.
Gerv
Comment 4•17 years ago
|
||
Concur w/Gerv. The EULA should only be displayed for official binaries.
Assignee | ||
Comment 5•17 years ago
|
||
Anybody can tell me how to I can - based on a build flag -
- copy or modify a file, to change the default pref *or*
- access the flag from JS?
Comment 6•17 years ago
|
||
If it really is tied to the branding we could just move the prefs to the firefox-branding.js files ( http://lxr.mozilla.org/seamonkey/find?string=firefox-branding.js ) with appropriate default values in each.
Alternately we could use MOZILLA_OFFICIAL/BUILD_OFFICIAL (e.g. http://lxr.mozilla.org/seamonkey/search?string=OFFICIAL_BUILD ). I'm not sure offhand which is the better solution.
Assignee | ||
Comment 7•17 years ago
|
||
> firefox-branding.js
Perfect! I'm glad I asked. That's exactly what I thought of, but didn't think already exists.
Yes, I think it's fine to tie this to the branding.
Patch will be trivial default prefs change.
Assignee | ||
Comment 8•17 years ago
|
||
Change pref "browser.EULA.override" (which prevents the EULA, apparently use for automated test scripts - I changed those in the tree) to "browser.EULA.needed" (which shows the EULA), and set the latter only for official builds.
Asking gavin for review, as he commented and often hacks nsBrowserGlue.js.
Assignee | ||
Updated•17 years ago
|
Attachment #328781 -
Flags: review? → review?(gavin.sharp)
Comment 9•17 years ago
|
||
Please don't change the pref name, getting all the tinderbox configs updated is a nightmare (it's not as easy as just changing all the configs in CVS/Hg). I'd just set override to true in the non-official branding files and avoid touching the code altogether.
Assignee | ||
Comment 10•17 years ago
|
||
> I'd just set override to true in the non-official branding files
That's specifically what I don't want - the default must be to *not* show this.
I can keep using "browser.EULA.override", by changing the default variable value to false and set "browser.EULA.override" to false in the official branding. That has the same effect, is just very hard to understand. (The fact that "override" means "don't show" is not clear to start with.)
Comment 11•17 years ago
|
||
Comment on attachment 328781 [details] [diff] [review]
Fix, v1
I don't think it's that hard to understand - it it is, add a comment!
Attachment #328781 -
Flags: review?(gavin.sharp) → review-
Assignee | ||
Comment 12•17 years ago
|
||
Attachment #328809 -
Flags: review?(gavin.sharp)
Comment 13•17 years ago
|
||
Comment on attachment 328809 [details] [diff] [review]
Fix, v2, Keep existing pref
>Index: browser/components/nsBrowserGlue.js
> // Global override for tinderbox machines
Can you change this comment, and point out that we now default to not showing it?
Attachment #328809 -
Flags: superreview?(mconnor)
Attachment #328809 -
Flags: review?(gavin.sharp)
Attachment #328809 -
Flags: review+
Updated•17 years ago
|
Product: Firefox → Toolkit
Comment 14•16 years ago
|
||
Comment on attachment 328809 [details] [diff] [review]
Fix, v2, Keep existing pref
sr=me
Attachment #328809 -
Flags: superreview?(mconnor) → superreview+
Updated•16 years ago
|
Flags: blocking1.9.1?
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.2?
Updated•16 years ago
|
Attachment #328809 -
Flags: approval1.9.0.3?
Attachment #328809 -
Flags: approval1.9.0.2?
Updated•16 years ago
|
Assignee: ben.bucksch → nobody
Component: Startup and Profile System → General
Flags: blocking1.9.1?
Product: Toolkit → Firefox
QA Contact: startup → general
Version: 1.9.0 Branch → 3.0 Branch
Updated•16 years ago
|
Assignee: nobody → ben.bucksch
Flags: wanted1.9.0.x?
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?
Assignee | ||
Comment 16•16 years ago
|
||
Checked into trunk (FF 3.1). FIXED.
Waiting for 3.0.x approval.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•16 years ago
|
||
Comment 18•16 years ago
|
||
(In reply to comment #13)
> (From update of attachment 328809 [details] [diff] [review])
> >Index: browser/components/nsBrowserGlue.js
>
> > // Global override for tinderbox machines
>
> Can you change this comment, and point out that we now default to not showing
> it?
This didn't get done. Can you please do this?
Assignee | ||
Comment 19•16 years ago
|
||
Fixing comment, too, per gavin
http://hg.mozilla.org/mozilla-central/rev/6ef3bf360f6c
Comment 20•16 years ago
|
||
Setting flags:
- doesn't block 3.0.2 (though if we have to respin, we should take it)
- does block 3.0.3
- does block 3.1
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: wanted-firefox3.1?
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.3+
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.2-
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1+
Comment 21•16 years ago
|
||
Comment on attachment 328809 [details] [diff] [review]
Fix, v2, Keep existing pref
We're respinning 3.0.2, so we'll take this as a ride-along. Please land on trunk and GECKO190_20080827_RELBRANCH
Attachment #328809 -
Flags: approval1.9.0.3?
Attachment #328809 -
Flags: approval1.9.0.2?
Attachment #328809 -
Flags: approval1.9.0.2+
Comment 22•16 years ago
|
||
(In reply to comment #21)
> (From update of attachment 328809 [details] [diff] [review])
> We're respinning 3.0.2, so we'll take this as a ride-along. Please land on
> trunk and GECKO190_20080827_RELBRANCH
Done:
mozilla/browser/components/nsBrowserGlue.js 1.97.2.1
mozilla/other-licenses/branding/firefox/pref/firefox-branding.js 1.4.28.1
mozilla/browser/components/nsBrowserGlue.js 1.98
mozilla/other-licenses/branding/firefox/pref/firefox-branding.js 1.5
Keywords: fixed1.9.0.2,
fixed1.9.0.3
Comment 23•16 years ago
|
||
Verified fix.
Eula appears on branded Mozilla build 6: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2) Gecko/2008091618 Firefox/3.0.2
Eula is Removed from non-branded mozilla build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3pre) Gecko/2008091804 GranParadiso/3.0.3pre
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Attachment #328781 -
Attachment is obsolete: true
Updated•16 years ago
|
Keywords: fixed1.9.1
Updated•16 years ago
|
Keywords: verified1.9.1
Updated•16 years ago
|
Keywords: fixed1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•