Gervase Markham: Mozilla and Proprietary Software |
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”).
Rationale: Manifesto Principle 7.
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.
Example: most JavaScript on the web today.
Rationale: without this, our products would effectively not browse the web at all.
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.)
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.
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.
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.
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. :-|
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.
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.
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.
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.
http://feedproxy.google.com/~r/HackingForChrist/~3/4KvvwVvXJ-w/
Комментировать | « Пред. запись — К дневнику — След. запись » | Страницы: [1] [Новые] |