I’m no lawyer, but this is a massive improvement. Thanks for listening.
The first of the two layout ideas is my preference and I would *really* also prefer if you, or the Ultimate Distributor, could ship with the Website Services disabled by default. So this “contract” is then only required if the user turns them on…
I love what you have done here, with both presentation and content; that said, an end-user agreement still exists with respect to the non-free services.
(From my perspective, I think Iām happy with this arrangement. The end-user agreement is clearly limited to use of the services – and I can either agree, and use them, or else disable them.)
Regarding the non-free services bundled (compiled?) with Firefox (I am still quite new to FOSS, so please forgive any ignorance):
Isnāt Firefox itself released under an open-source license (the ātri-licenseā)? Confusing as the ātri-licenseā may be, isnāt it still the same, with respect to the prohibition of encumbering the end user with use restrictions?
If true, doesnāt the inclusion of non-free services in the Firefox build contradict the ātri-licenseā under which Firefox is released? I donāt know if the right term is ācontradictā, āinvalidateā, ācontaminateā, or whatever – the point is, how are the free and non-free components compatible?
Wouldnāt it be better to package these non-free services as an add-on for the free Firefox?
Then, the Windows/Mac builds could have the add-on installed/enabled by default, with the EULA presented upon install – and the Linux builds could have the add-on either not installed, or else installed, but not enabled (and users presented with the EULA when the add-on is enabled).
Else, could the Linux distros be permitted to build Firefox with the services disabled by default – without facing branding-rights revocation? If the non-free services canāt be pulled out into an add-on, perhaps this solution would satisfy all?
1) Ubuntu – the user does not download FireFox. Why are you thanking them
2) The reason for this page – most all is covered else where, hence why repeat – Is the inclusion of the encumbered services inside of a floss program. You then bury that. This again is because you are shipping the services as ON. If you ship them off (or better as add-on) and helped the user understand the need and restrictions.
[…] the Mozilla Foundation announced that here will be no EULA screen on Linux. Take a look at this post for details. It seams that our protest helped to convince them to remove that idea from the table. […]
The issue is moving in the right direction. Thank you for listening.
The trademark issue won’t go away unless you make it go away, though. Distros (and anybody else) need to be able to fix bugs in your code, without ripping all the trademarks out of it. It’s incomprehensible that you *want* your trademark to be associated with buggy code. Much bigger, more complex, more respected software like Linux and GCC get along without being trademark nazis. Almost nobody ships either Linux or GCC in the stock configuration from its originator. Yet their reputations survive and thrive. Ponder how that situation could exist for decades — then revisit your trademark policy.
The privacy issues of your “web services” also need addressing. By default, the browser feeds search keystrokes to Google, accepts Google’s permanent cookie, and feeds every URL to Google for malware checking. One might even be led to think that Google was paying the bills over at Mozilla, given the way that Firefox’s defaults all feed reams of private information to Google without notifying the user.
(And the way to turn off “Search suggestions” is hidden in a very odd place — nowhere near the privacy settings.)
In a previous comment I suggested that the people responsible for the EULA idea be fired. You took offense at that, and upon reflection, you are right.
A friend who used to work at Mozilla mentioned that most of the Moz Fdn employees really are not from the free software culture, and have little understanding of it. They’re doing marketing, or finance, or nonprofit administration, or whatever; not free software. This was a revelation that made it more obvious how the EULA error could have occurred.
At my last company, Cygnus Support, we hired many marketing people (mostly VPs of marketing). Each of them had to be carefully watched over for a year or two, because invariably their natural reflex was shaped by a lifetime in proprietary software companies. They would automatically assume that the answer to any issue was to close down, lock out, deny, stonewall, license. The founders had to gradually teach them that the way we got customers was to have them feel really free to just download and use the software anytime they wanted, share it with all their friends, talk it up on the net, hack on it, report bugs publicly, read bug reports. Eventually the users’ company would discover that it was depending on our software, and it might want our paid services in supporting it, or improving it to fit their company’s desires even more tightly. With such a policy, we were bringing in $20M in revenues per year, before we were acquired by Red Hat. Closing the product would have cut into that revenue. After their first few years in the company, we had the marketing people and the managers and executives better trained, and we could be less watchful.
So, I’m sure that this brouhaha has been a very salutary training session for the Moz Fdn people involved. It would be a shame to fire all that fresh expertise, and replace it with someone else whose reflexes will still be wrong, and who will not have seen WHY their reflexes are wrong for this community.
(Cygnus was lucky to have Dan Appelman as our lawyer. Years of service to the USENIX Association and the Unix community had already knocked off any proprietary reflexes he might have had, so he never caused us this sort of trouble.)
Mitchell Baker is Chair of the Mozilla Foundation, a non-profit organization dedicated to promoting openness, innovation and opportunity on the Internet.
Pingback from Firefox e l’EULA: Mozilla non farĆ piĆ¹ la preziosa. Forse. Ā« pollycoke :)
Pingback from No Firefox EULA screen on Linux | Robert Penz Blog
Pingback from Aktualizacja w sprawie EULI at stream of bytes
Pingback from An update on the Firefox EULA issue « I’m Just an Avatar