Partnering/Open Source Distributions

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Overview

Our goal with this policy is to formalize and clarify the process for distribution of modified, officially branded Firefox versions as a part of open source OS distributions.

This policy and the included guidelines only apply to distributions that modify Firefox in any substantial or user-visible manner. If you are building and distributing a stock version of Firefox (standard build configurations, no code changes) no action is required, but we still recommend that you follow the minimum standard outlined in the Best Practices section.

If you are making only minimal code changes that do not impact user experience or security, such as portability fixes, this is generally acceptable. If it's not clear, please contact partner-support@mozilla.org so we can help you assess whether written approval is required for these changes.

Getting Started

If you do not already have an existing contact or written agreement with Mozilla, please file a bug using the Trademark Request form. In the description, please copy this template below and answer all questions to the best of your ability. Depending on what changes you intend to make, a formal distribution agreement may or may not be required. Either way, a Mozilla contact will work with you to review your proposed modifications.

Requesting Approval for Modifications

For each significant change you wish to make to Firefox, we ask that you provide the following information in the Bugzilla report (or a followup bug, for any additional changes after initial approval):

• A copy of the patch to be applied (as an attachment)
• The rationale for and expected results of the proposed patch
• Where the required change is an issue in core Firefox, a link to the bug report where this issue is reported, and the fix proposed.

Mozilla will engage with engineering and product management teams as needed to understand and evaluate each change. If the change is deemed acceptable, we will grant permission to include the change in the modified distribution.

Handling Revenue-impacting changes

Mozilla's activities are primarily funded through partnerships, primarily from search providers. If your proposed changes involve any change to a feature with a revenue component, this will require the completion of a formal distribution agreement. This agreement will outline the specific changes to be made and any revenue sharing agreements between the Mozilla and your organization. Without a formal agreement in place, no changes that impact monetization will be permitted under any circumstances.

For distributions interested in working in partnership with Mozilla to help support your projects, please contact partner-support@mozilla.org for more details.

The goal of these agreements is to protect all parties and ensure any financial impacts are well understood and managed, as well as to ensure that any legal requirements for each party are fully addressed.

Best Practices

At a minimum, all distributions should be clearly identified with the distribution name (by setting distribution.id). This will allow us to narrow down any per-distro issues we encounter.

Ideally, all distributions will also comply with the following model for making changes:

• All preference changes should be implemented within a distribution.ini file
• Any changes to search plugins should be implemented through the distribution framework as overrides to the default engines
• All patches not specific to a particular distribution should be pushed upstream as soon as possible, both to benefit other Firefox users and to minimize the differences between what we test and ship and what you ship.
• If possible, build systems should be configured to produce debug symbols, and the symbols uploaded to Mozilla's crash analysis service automatically. This is to allow us to identify and address stability issues within your specific builds.

In addition to the change model outlined above, there are a set of expectations that must be adhered to if you are distributing your own packages:

• Within reason, all updates must be provided on the same schedule as official Mozilla releases. This includes any required point releases, especially those required for security issues.
• If early access is granted for security issues, appropriate measures must be taken to protect against early disclosures of vulnerabilities.
• No action will be taken outside of the to block or interfere with any of the features, including any service pings tied to a Firefox feature.

Key Contacts

For any questions on this policy, please contact partner-support@mozilla.org with a complete explanation of your questions or concerns.

Bug Template

> Firefox Open Source Distribution Request Template

> Distribution Name

> Website

> Contact Name

> Contact Email

> Approximate number of users for this distribution (please provide region breakdowns if available)

> What type of users are targeted by this distribution? (consumers, enterprise, education, etc)

> Is the distribution a commercial product or under an open source license? Please be specific.

> Is Firefox the default browser for your distribution?

> Are other browsers installed by default or available from built-in sources? If so, which browsers?

> Do you have any existing commercial relationships that could apply to Firefox?

> Are you currently shipping any modifications to Firefox? If yes, have those modifications been approved in writing?

> Are you looking to make additional changes to Firefox as a part of this request?

> For each distinct change from stock Firefox, please attach a diff and describe the rationale behind that change. If there is a Mozilla bug on the issue, please provide the bug number with the rationale.