Mozilla is both a principled organization and a pragmatic one.
Mozilla products run on proprietary operating systems, and on proprietary hardware. We are in the mobile OS business, and no-one, not even the mighty Google, has yet been able to make a 100% open source phone available in commercial quantities. So proprietary software is part of Mozilla’s life. But I think most people in our community would be rightly upset if Mozilla decided, for example, to take advantage of the provision in the MPL which would allow us to ship proprietary builds of Firefox on the desktop.
So, the question arises: where’s the line? Where in the big picture is it OK for proprietary software to be, and where is it not OK?
“You don’t have to make a case for open. You have to make a case for not open.” — Johnathan Nightingale
Over time, this question has been arising in a number of different contexts. And I think the answers we might give at the Mozilla project would be different to those you might hear from the FSF, or the Apache project, or the Android project, to name but three points on a wide spectrum of opinion. So I think it would be a productive conversation to try and work out some principles in this area – or, at least, to gauge the range of opinion. As johnath says, if we are using or distributing closed software, we need to make an active case for why we are doing it.
This post is therefore a discussion starter, and outlines where I currently think the line is – i.e. where a reasonable case can be made for closed, and where it cannot. It could be in the future, a case can be made for additions to, removals from or modifications of this list. But having a defined list at least helps to make it more clear what is a new situation where a case needs to be made, what is another example of something we’ve done before.
Note that this post represents my opinion only, and is not official Mozilla policy. Although it speaks of things that currently are, as well as things that currently are not, for ease of reading, I will write directly rather than using conditional language (i.e. “will” rather than “should”).
- The basic rule is that software written by Mozilla will be open source. Mozilla is a public benefit organization; we do not use money given to us to write proprietary software.
Rationale: Manifesto Principle 7.
- Mozilla may distribute proprietary software written by others with its own software under the following circumstances:
- If it’s a missing important piece of functionality provided by an OS vendor for a proprietary operating system on which our software runs;
- If the software is required to make use of the hardware on which the product runs, and there is no open source alternative driver of sufficient quality.
Example of A): the Direct3D DLL, included under the Binary Components policy. Example of B): hardware drivers for Firefox OS.
These situations are seen as sub-optimal and we look for opportunities to eliminate them, as opportunity and market power permit. They are not seen as precedent-setting. This is a negotiating point in discussions with hardware manufacturers, particularly for reference devices.
In the past, we shipped the “Talkback” crash-reporting software, which did not fall under either of these exceptions. We now use the open source Breakpad. This replacement took seven long years to arrive. Now that Talkback is gone, we should not go back there.
Rationale: without such exceptions, we can’t ship competitive products (or, in the case of B, any products at all). But we need to define them tightly.
- Mozilla’s products will execute proprietary code in web content.
Rationale: without this, our products would effectively not browse the web at all.
- Mozilla may permit its partners to distribute proprietary software in a product using a Mozilla brand under the circumstances above. Mozilla’s partners may also ship proprietary apps in their versions of Firefox OS. Such apps must be uninstallable. Additions to the platform not falling under one of the exceptions above must be open source.
Rationale: same as above, plus requiring that all default partner apps be free software means many popular apps could not be bundled, making our offering much less compelling. If we allow users to install proprietary apps, there is not significant additional harm in bundling (uninstallable) ones. Requiring arbitrary platform additions to be open source is necessary to allow users to build updated versions of the software for their phones. (Binary driver blobs use a known API and, while it’s sub-optimal, can be copied from official builds into user ones.)
- Mozilla will only allow Mozilla brands to be used for software on phones which are bootloader-unlockable.
Rationale: Mozilla stands up for user freedom, including the freedom to hack one’s phone, and update the OS even when the vendor has ceased support.
- Mozilla’s products may sometimes automatically download and install deterministically-built binary builds of other open source software where we would prefer not to distribute it ourselves, e.g. for patent license reasons. However, there may be additional requirements we would want to be met before we solved a problem using this solution.
Example: Cisco’s H.264 binary builds made from OpenH264. (Note: the exact user experience in this case has not yet been determined. I am just saying that I think it would be OK if Firefox downloaded and installed this software automatically.)
Rationale: Software patents suck. Because Cisco have made H.264 free-as-in-price at the point of use for everyone, we managed to get a draw in this particular round of the codec wars. (The other options were much worse.) But fighting patents is done at the standards and industry level, not at the “make every user click a button” level. If the source is open and the binaries are deterministically built, then users are using binaries of free software which is bit-for-bit identical to that we could build for them ourselves, and so requiring a user confirmation here gains us nothing.
- Mozilla will allow proprietary software in the app stores and addons stores that it runs. Mozilla will make sure the license terms for software are clearly marked, and are searchable as a metadata field.
Example: Firefox OS Marketplace, addons.mozilla.org. (Unfortunately, license metadata is not currently collected or available for searching.)
Rationale: some people, including members of our community and vocal Mozilla supporters, wish to avoid using proprietary software; we should help them make choices in line with their ethics.
- Mozilla’s products may give the user the UI option of downloading, installing and running binary builds of proprietary software (e.g. an addon or plugin) but will not get to the point of executing such software without getting explicit or implicit user consent somewhere along the way. “Implicit consent” means that the user has taken some action (e.g. installing the Flash plugin themselves) which was not mediated by Firefox but which we know must have happened.
Example: Mozilla allows users to download proprietary Firefox add-ons through the Add-On Manager UI. The Plugin Finder Service will point users at downloads of proprietary plugins such as Flash. But all require at least one explicit confirming click to install.
Rationale: some people, including members of our community and vocal Mozilla supporters, wish to avoid executing proprietary software; we should not sneakily run it on their systems. However, even offering it is enough for Firefox to not be in the FSF’s directory of free software. :-|
- Mozilla prefers to use open source software for end-user network services it builds into its products. However, we are willing to partner with companies who use proprietary software and/or data. Such proprietary services must be able to be disabled by the user, and the API endpoint must be configurable by the user or 3rd party software such as an extension (e.g. an about:config setting in Desktop Firefox).
Examples: Safe Browsing, geolocation.
Rationale: Mozilla is starting efforts in geolocation, speech recognition and translation to either replace or avoid depending on proprietary services in these areas. But building e.g. a replacement for Google Safe Browsing, which protects many, many Firefox users from malware and phishing every day, would be a mammoth undertaking. And removing it would put our users at significant risk. Endpoint URL configurability allows people to reverse-engineer service APIs and implement alternatives which Firefox can then easily use.
- Mozilla’s products will run on proprietary operating systems, and therefore may require proprietary software, such as a compiler or SDK, as part of the build process for such systems. Mozilla’s products will not require proprietary tools to build on free operating systems.
Example: Release builds of Firefox on Windows are built using Microsoft Visual Studio, and most developers on Windows use it for their builds too.
Rationale: if one is using a proprietary OS, there seems no additional harm in using proprietary build tools.
- Mozilla strongly prefers to use open source software for network services it stands up for use by the Mozilla developer community, but may use proprietary software if no open source software of equivalent functionality is available. In such cases, Mozilla provides some resources (money or people) to help rectify that situation.
Example: Mozilla uses Vidyo, and so Mozillians who want to use it have to use the proprietary Vidyo client, or Flash. But we are developing WebRTC in the browser, and hope that thereby solutions will emerge where people can participate in multi-party video using only open source software. We are also trying to get the SIP gateway working (that bug is restricted to the ‘infra’ group so you may not be able to see it) so people can video-call in using free software.
Rationale: we should not compromise our effectiveness by using significantly sub-standard tools; but as a member of the wider open source community and as a public benefit organization, we have a responsibility to grow the commons in areas where we have an interest.
- Mozilla community members are free to use proprietary desktop software if they wish. Mozilla may therefore pay for licenses for particular bits of proprietary software for the use of Mozilla employees, contractors or interns. Mozilla will not implement systems which require non-employees to use proprietary desktop software to be part of the community.
Example: Windows, Office, internal payroll or HR systems. (Vidyo doesn’t quite break that last rule, as someone can still dial in to any meeting by phone.)
Rationale: there are no effective substitutes for some of this software. However, we should not lock free software advocates out of full participation in our community.
0) I appreciate the effort to set up public rules for all that!
1) In most places, I think those reflect current reality nicely, but in a few, I’d see those rules as a welcome upgrade to what’s going on right now! :)
2) Should we also have a rule in there that for any proprietary software used internally, we should have a good statement visible at least to all users of the product explaining why FLOSS solutions are not adequate for our use at this time (I’m thinking stuff like Tableau, which we are using for a number of metrics visualizations, and there’s probably other things floating around). I personally believe if we are not able to put up a convincing statement of that manner, we instead should have a clear transition plan to a FLOSS product. :)
“Mozilla will not implement systems which require non-employees to use proprietary desktop software to be part of the community.”
Is it sufficient that there are other parts of the community that don’t require proprietary software while some do? Or are you suggesting that no part of the community may require proprietary desktop software?
1) While Talkback did not fall under any of the exceptions mentioned, it was inherited from Netscape (IIRC), so it was not really a choice Mozilla made.
2) This item is somewhat odd in this list since most of what Mozilla products are used to display/render/execute is “proprietary media” (text/images/fonts/video/js) in that it is copyrighted and not under an open license. So it seems a bit odd to single out code. But I think the rationale for this item is much larger (to the point of making it self-evident), in that users should be free to use Mozilla products for whatever they want. There is no “shall be used for Good, not Evil” clause in there and Mozilla don’t what to be the arbiter nor responsible for users (informed) actions.
3) If the “partner” had just taken the code, they could have done whatever they wanted with it (as I understand it — similar to the rationale for 2, although this item also has distribution). So I think it should be clarified that this item is about trademarks and the rationale changed to be about why Mozilla would its trademarks to be used on such devices (similarly to how 4 is worded).
8) “Web-search” is a much more visible example. Some might argue that most dns and http services accessed with the products are proprietary.
9) I think it is important, that even though the tool-chain may not be “free as in speech”, it is at least “free as in beer” (although that might be another debate). Also importantly, it is not just possible to build it using free tools (speech or beer) on all platforms, it is the preferred tool-chain (used for most development and releases). However, the rationale given for this, I assume, controversial item seems quite vague (e.g. why is MinGW or Cygwin not used for windows builds?).
I think you have left out the category, where people are free to use Mozilla products (e.g. NSS and xulrunner) as part of proprietary (non-Mozilla-branded) software and this is seen as a good thing.
Perhaps you could also mention that Mozilla try to work with proprietary vendors e.g. in standards forums.
How does this (unofficial) policy apply to essential parts of the user experience that rely on web services? Point 8 doesn’t quite seem to cover this.
In particular I’m thinking of everything.me, Firefox OS’s online search tool. Mozilla is heavily promoting this as the core of the FxOS experience (“the adaptive phone”). I haven’t been able to locate its source code so I assume the server-side parts are not AGPL’d. (Corrections are welcome.)
Ubuntu’s Dash search (“Smart Scopes”) is another example of this: the client-side code is open source, but the magic is all in proprietary server-side code.
0) Let’s not get ahead of ourselves; I’m not promising I’ll be able to make something like this official Mozilla policy :-)
1) That might be a reasonable consequence of the “making the case for closed” principle…
I am suggesting that it would be ideal if no part of the community required it. Do you know of parts which currently do?
In some cases, this point may be more about file formats. For example, if Mozilla had a “Presentations Preparation Group”, then they would need to not share their work in progress between each other as Keynote files, as there is no free software which reads them.
1) Yes, but we definitely made an explicit choice to continue using it. Mozilla had to get various licenses from Talkback to keep their back end servers running (which was actually where a lot of the pain was).
3) This is indeed a point about trademark use; perhaps that could be more clear.
8) Web search is sort of an example, although that kind of blends into “use of a website” in a way that SafeBrowsing, for example, does not. Perhaps getting instant search results in the URL bar is an example, yes.
9) I think that may be another debate. Say there was a new popular proprietary OS (unlikely, but bear with me ;-) and the vendor charged $50 for the developer kit. Would we refuse to port to that OS for that reason?
Yes, people are free to take our code and use it in proprietary software, although that’s not really “in our community” any more. I’ll ponder adding a note about this.
Let’s be careful about calling it a policy of any kind :-)
Point 8) is intended to cover network services. Why do you think it doesn’t cover everything.me? (You are right that their server-side is closed source.) I agree that everything.me is more crucial to the FirefoxOS experience than would be ideal for a proprietary network service, at least in my mind… it would be awesome if that was an open system. But as the client is open source, you can at least look and see what it’s doing, and make sure it’s not violating your privacy and so on.
So basically Air Mozilla break rule 11. We still can’t view a live broadcast without the use of proprietary software: Flash. Which basically goes to 10.
As for suggesting “dial in” to replace Vidyo in rule 10. AHEM. Only if screen sharing is banned and all cameras are muted. Non withstanding the cost of dial-in.
8) Web search do take up a large part of the chrome (and the start page that is styled to appear to be part of the chrome), so I don’t think you can disown it.
9) Good point. The example I was thinking about was that Intels compiler is not used even though it might (especially previously) produce better code.
Hub: I agree the Air Mozilla situation is less than ideal, although replay of archived content does not require Flash, so it’s still possible to watch things. For those in Asia, that’s probably how they watch most AirMo content anyway :-) Richard Milewski is working on removing the Flash requirement, but it’s tough.
If you dial in, you can take pretty good part in most conversations. And it doesn’t have to cost anything – we have a SIP gateway which can now, I believe, access any voice or Vidyo conference room. I agree it’s not the same, but it’s not like people are totally excluded. And hopefully greater use of WebRTC will alleviate this problem. Vidyo may even be working on a WebRTC gateway.
A working WebRTC gateway into Vidyo would do it… but….
When I joined Mozilla, even the recorded sessions was Flash only, so it actually got better.
Also I was afraid to mention our last Firefox Flicks… that required Flash since it was hosted on Vimeo…. (or a browser supporting MPEG-4)
Pingback: Mozilla and the Future | Hacking for Christ
so air mozilla may not use flash for recorded videos, but can it stop using the weird iframe thing too? also why is it hard to not use flash for live stuff, I freely admitt to not knowing much about streaming video on the web, but I’d expect its a fairly well solve problem by now…
Sadly not a well-solved problem for the <video> element, AIUI :-| Richard Milewski would know more. It could be that we need various media extensions in JS to be working, and then a JS implementation of DASH.