No, this post is not about certificates :-))

We want to make Mozilla as open a project as possible, which means that ideally there would be no parts of what we do which were closed to input from particular sections of the community. Question: how does Mozilla acquire sufficient trust in a potential community member that we could let them work in sensitive areas? Sensitive areas might include ones where they were working with confidential data belonging to users or employees, or working with partners under NDA, either temporary or permanent. We would not want someone untrustworthy in such a position.

Here is a (probably incomplete) list of ways to establish trust between a truster and a trust-ee:

• A) Recommendation from 3rd party already trusted by truster
• B) Trust-ee putting something at risk (deposit)
• C) Legal contract with penalties
• D) Demonstration of bona fides (e.g. by being faithful in small things)
• E) Gut instinct
• F) Trust-ee revealing verified identity information
• G) Default to trust; remove trust if trust broken

When Mozilla employs someone, we have sufficient trust in them because of B) (their job is the thing at risk if they violate trust), C), F) and perhaps a little of A). How do we go about establishing similar trust with someone we don’t employ?

Here are some comments on each:

• A) doesn’t scale well to a globally-distributed organization, where we regularly get new people who know no Mozillians in real life.
• B) This is a difficult thing to ask of new community members. What options are there? Money? Something else?
• C) IT went for this one, but it might be too heavyweight for some. (Of course, it might be required by law in some cases.)
• D) This is how things work normally; we are looking for a way to speed this process up.
• E) This works right up until it doesn’t…
• F) We could investigate this; obtaining such identity proof might involve a time and/or money cost for the contributor.
• G) Possible in some circumstances, but not the difficult ones. Perhaps involves an overly-rosy view of human nature.

Thoughts and further comments?

Gerv

I had two emails about this yesterday, so I thought I’d stick a post on Planet to clarify.

The short version: GPLed code may not be included in software that Mozilla ships.

The long version:

Three major goals of the Mozilla licensing policy are:

1. legal simplicity for downstream users;
2. the ability for as many people as possible to use our code in their products; and
3. striking a balance between maintaining copyleft for our code, and the right of those downstream users to combine our code with proprietary code.

The practical result of this is that we act to preserve the right of anyone taking all or part of a codebase from us to use it under the terms of the MPL (currently mostly version 1.1, soon to be version 2), or in projects under the LGPL or the GPL, at their option. That means that all the constituent parts have to be under either the MPL 1.1 tri-license, or the MPL 2 without the incompatibility clause, or a simpler subset of those terms, such as Apache, BSD or MIT.

If any part was solely under the GPL, then people wanting to use MPL terms for the entire application could not do so – only GPL terms would be available, unless the GPL-only part was removed. It would also no longer be possible to release binary versions of e.g. Firefox under the MPL, as Mozilla does today.

If any part was solely under the LGPL, then people would not be able to use MPL terms for that part. This is possibly less of a problem, particularly if the software is a clearly-defined and self-contained library. There is some talk of changing the policy to permit LGPLed libraries to be included, but it’s at an early stage and no decision has been made yet. We would need to do some legal work to find out what the additional compliance requirements were on us and on users of our code, and whether it was possible to clearly identify what was part of the LGPLed library and what was not (both in general and in any particular case).

If an author of some code has placed it under the GPL, then that means that they want it to be used only in GPLed projects (and Mozilla projects are not GPLed projects). We need to respect that licensing decision that the author has made. There is a load of code out there which is unavailable for use by us at Mozilla. The fact that you can read the source, or use it in other projects doesn’t change that.

The release of the new MPL 2 does not change any of this.

So, if you want to use some code which is under the GPL in a Mozilla project codebase, you have a few options:

• You can ask the licensing team to contact the author or authors of the code and ask them to make it available under the MPL or another licence which fits with
  our licensing policy. Software authors are often receptive to polite requests of this type. We have done this before for large pieces of code, e.g. cairo.

• You can find another library implementing the same functionality. For many standard libraries, there is a GPL version and a BSD version.
• You can rewrite the code (just as you would have had to do if you hadn’t found the library or if it had been proprietary or otherwise not open source).

Note also that I talk about “code that Mozilla ships”. We have a small number of internal tools, such as build tools, which were sourced from elsewhere and are GPLed. So finding GPLed code in a Mozilla repo is not necessarily a violation of this policy. However, “software that we ship” includes anything we create ourselves as an open source project, even if it’s primarily for our own internal use (e.g. the AMO codebase). And this policy applies to all code being created under the auspices of the Mozilla project, whether the code is stored in a Mozilla-hosted repo or somewhere else, like GitHub.

Today, any software ecosystem, whether it’s software for an OS, addons for a browser, or apps for a phone, has to consider the possibility of malware.

If one wants to deal with the problem of malware, I see the following solutions:

1. Have a single point of software distribution for your platform that you control, e.g. the Apple App Store for iOS. This does not entirely eliminate the possibility of malware, but does make it less likely, and does enable you to take quick action when it’s discovered. Depending on the policies and entry requirements of such a distribution point, of course, this may lead to unacceptable restrictions on user or developer freedom.
2. Have software which attempts to detect and stop malware, e.g. virus scanners. This puts you into an arms race with the malware authors, who come up with amazing things like self-modifying polymorphic code. And they will write code to disable or work around your code. There are a lot more of them than you, and they can make a lot of money if they succeed.
3. Have a reputation system, e.g. by requiring all code to be signed by the developer or a reviewer, and have a blacklist of “bad developers” or bad/stolen signing keys. This gives developers a key management problem, and also potentially the expense and hassle of obtaining a identifying certificate.
4. Rely on your users to be smart, and hope that people don’t fall for the enticements to download the malware. This approach is the one taken by Ubuntu – even though anyone could make a .deb of malware and start to promote it via spam or compromised websites, it’s very rare. I suggest that this is due to the smaller and better-informed market which uses Linux, and perhaps a diversity of processors meaning that compiled code doesn’t run everywhere.

Unless I’ve missed one (tell me :-), any other solution will be a hybrid of components of the above. For example, on Android, there is by default a single point of software distribution for a given Android device (the Android Market or another vendor’s market), but you can check a preference to allow the installation of non-Market applications and, when you do, it’s up to you to avoid installing something malicious. (Let’s leave CarrierIQ out of the discussion for now!) So that’s a hybrid of 1 and 4.

Question for discussion: which solution is best for Firefox add-ons?

Currently, although there is a website for downloading addons, we allow non-AMO addons with just an “are you sure” prompt to prevent nagware. We do have the capability for code signing, but no-one uses it, and no-one notices whether anyone is using it, because there are no significant penalties for not using it. So it seems to me like we are effectively using solution 4.