diff --git a/bedrock/mozorg/templates/mozorg/base.html b/bedrock/mozorg/templates/mozorg/base.html new file mode 100644 index 00000000000..4a3da6310ee --- /dev/null +++ b/bedrock/mozorg/templates/mozorg/base.html @@ -0,0 +1,25 @@ +{# This Source Code Form is subject to the terms of the Mozilla Public + # License, v. 2.0. If a copy of the MPL was not distributed with this + # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} + +{% extends "base-article.html" %} + +{% block body_class %}mzp-t-mozilla{% endblock %} + +{% block email_form %} +
+ +
+{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/1.1/faq.html b/bedrock/mozorg/templates/mozorg/mpl/1.1/faq.html index c87ddae92c3..3178ec020da 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/1.1/faq.html +++ b/bedrock/mozorg/templates/mozorg/mpl/1.1/faq.html @@ -2,88 +2,81 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('MPL 1.1 FAQ- HISTORICAL USE ONLY') }}{% endblock %} {% block page_desc %}{{ _('MPL 1.1 FAQ- HISTORICAL USE ONLY') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

MPL 1.1 FAQ- HISTORICAL USE ONLY

+{% block article %} +

MPL 1.1 FAQ- HISTORICAL USE ONLY

-
-

Français (une version plus tôt)

-

This is an outdated FAQ, and is retained only for historical purposes. The FAQ for MPL 2.0 is here.

-

This is the Mozilla MPL FAQ. It aims to answer the most common questions people have about using and distributing code under the MPL. Note that because much of the Mozilla codebase is MPL/GPL/LGPL tri-licensed, it's also possible to use and distribute some Mozilla products under the LGPL or GPL; in that case, some of these questions would have different answers.

-

These explanations are not the license; if in doubt, consult a lawyer. If you see any errors in this FAQ, or have suggestions for further questions, please email licensing@mozilla.org.

-
-
I want to use software which is available under the MPL. What do I have to do?
-

Nothing. By definition, all free software/open source software is available for anyone (including companies) to use for any purpose. The licenses only affect you (to a greater or lesser extent) if you want to distribute the software, either in changed or unchanged form.

+
+

Français (une version plus tôt)

+

This is an outdated FAQ, and is retained only for historical purposes. The FAQ for MPL 2.0 is here.

+

This is the Mozilla MPL FAQ. It aims to answer the most common questions people have about using and distributing code under the MPL. Note that because much of the Mozilla codebase is MPL/GPL/LGPL tri-licensed, it's also possible to use and distribute some Mozilla products under the LGPL or GPL; in that case, some of these questions would have different answers.

+

These explanations are not the license; if in doubt, consult a lawyer. If you see any errors in this FAQ, or have suggestions for further questions, please email licensing@mozilla.org.

+
+
I want to use software which is available under the MPL. What do I have to do?
+

Nothing. By definition, all free software/open source software is available for anyone (including companies) to use for any purpose. The licenses only affect you (to a greater or lesser extent) if you want to distribute the software, either in changed or unchanged form.

-
I want to distribute software which is available under the MPL, either changed or unchanged, within my organization. What do I have to do?
-

Nothing. The right to private modification and distribution (and inside a company or organization counts as 'private') is another right guaranteed by software freedom. "You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist."

+
I want to distribute software which is available under the MPL, either changed or unchanged, within my organization. What do I have to do?
+

Nothing. The right to private modification and distribution (and inside a company or organization counts as 'private') is another right guaranteed by software freedom. "You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist."

-
I want to distribute (outside my organization) complete and unchanged binary packages provided by Mozilla. What do I have to do?
-
-

Nothing. The Mozilla-provided binary packages already meet the requirements of sections 3.1 to 3.5, and include the notices required by section 3.6. You may distribute them under the terms of the MPL.

-

If you are offering a warranty, you must make clear that it is offered by you alone [3.5]. Mozilla offers no warranties on our binaries.

-

You do not require a Mozilla Foundation trademark license.

-
+
I want to distribute (outside my organization) complete and unchanged binary packages provided by Mozilla. What do I have to do?
+
+

Nothing. The Mozilla-provided binary packages already meet the requirements of sections 3.1 to 3.5, and include the notices required by section 3.6. You may distribute them under the terms of the MPL.

+

If you are offering a warranty, you must make clear that it is offered by you alone [3.5]. Mozilla offers no warranties on our binaries.

+

You do not require a Mozilla Foundation trademark license.

+
-
I want to distribute (outside my organization) Firefox, or other MPL-covered code, that I have compiled myself but not changed. What do I have to do?
-
-

You must

-
    -
  • add a conspicuous notice stating where to find the exact source to the binary you are distributing [3.6]
    (Note: if you are compiling a Firefox-like package, this may be already included, e.g. in about:buildconfig.)
    • -
  • if your documentation has a section dealing with licensing or the recipient's rights to the code, put a copy of the MPL in it. [3.5]
    • -
-

You may distribute any binaries you create under a license of your choosing, as long as it doesn't interfere with the recipients'right to the source under the MPL [3.6].

-

You may require a Mozilla Foundation trademark license if you wish to use Mozilla Foundation trademarks (e.g. the Firefox name or logo).

-
+
I want to distribute (outside my organization) Firefox, or other MPL-covered code, that I have compiled myself but not changed. What do I have to do?
+
+

You must

+
    +
  • add a conspicuous notice stating where to find the exact source to the binary you are distributing [3.6]
    (Note: if you are compiling a Firefox-like package, this may be already included, e.g. in about:buildconfig.)
    • +
  • if your documentation has a section dealing with licensing or the recipient's rights to the code, put a copy of the MPL in it. [3.5]
    • +
+

You may distribute any binaries you create under a license of your choosing, as long as it doesn't interfere with the recipients'right to the source under the MPL [3.6].

+

You may require a Mozilla Foundation trademark license if you wish to use Mozilla Foundation trademarks (e.g. the Firefox name or logo).

+
-
I want to distribute (outside my organization) a modified version of Firefox, or other MPL-covered code. What do I have to do?
-
-

You must

-
    -
  • add a conspicuous notice stating where to find the Modifications used to make the binary you are distributing. [3.6] If you wish, you may point at mozilla.org for the base code and then ship diffs between our version and yours.
    • -
  • if your documentation has a section dealing with licensing or the recipient's rights to the code, put a copy of the MPL in it. 3.5]
    • -
-

In addition, there are several obligations relating to your Modifications. You must

-
    -
  • have the right to distribute your Modifications [3.4 (c)]
    • -
  • add a correctly-completed MPL header to any new files which are Modifications [3.5]
    • -
  • make your Modifications available in source code form, under the MPL [3.1]
    • -
  • make your Modifications available on the same media as the executable version, or on the Net as long as they are available for 12 months [3.2].
    • -
  • document what your Modifications are [3.6] (one way to meet this requirement is to ship them as diffs)
    • -
  • include a statement that your code is derived from the particular piece of MPLed code you started with (e.g. Firefox), and a list of the names of the Initial Developers of that code [3.3].
    • -
-

You may require a Mozilla Foundation trademark license if you wish to use Mozilla Foundation trademarks (e.g. the Firefox name or logo).

-
+
I want to distribute (outside my organization) a modified version of Firefox, or other MPL-covered code. What do I have to do?
+
+

You must

+
    +
  • add a conspicuous notice stating where to find the Modifications used to make the binary you are distributing. [3.6] If you wish, you may point at mozilla.org for the base code and then ship diffs between our version and yours.
    • +
  • if your documentation has a section dealing with licensing or the recipient's rights to the code, put a copy of the MPL in it. 3.5]
    • +
+

In addition, there are several obligations relating to your Modifications. You must

+
    +
  • have the right to distribute your Modifications [3.4 (c)]
    • +
  • add a correctly-completed MPL header to any new files which are Modifications [3.5]
    • +
  • make your Modifications available in source code form, under the MPL [3.1]
    • +
  • make your Modifications available on the same media as the executable version, or on the Net as long as they are available for 12 months [3.2].
    • +
  • document what your Modifications are [3.6] (one way to meet this requirement is to ship them as diffs)
    • +
  • include a statement that your code is derived from the particular piece of MPLed code you started with (e.g. Firefox), and a list of the names of the Initial Developers of that code [3.3].
    • +
+

You may require a Mozilla Foundation trademark license if you wish to use Mozilla Foundation trademarks (e.g. the Firefox name or logo).

+
-
How 'viral' is the MPL? If I use MPLed code in my proprietary application, will I have to give all the source code away?
-
-

The MPL has a limited amount of 'copyleft' - more copyleft than the BSD family of licenses, which have no copyleft at all, but less than the LGPL or the GPL. It is based around the definition of a 'Modification' in the license [1.9].

-

What is a Modification? Any changes to MPLed files, or new files into which MPLed code has been copied, are Modifications and so fall under the MPL. New files containing only your code are not Modifications, and not covered by the MPL.

-

Files which fall under the MPL because they are or contain Modifications must be made available as detailed in the license (or elsewhere in this FAQ.) Other files may be kept proprietary.

-

One well-known example of this is the Netscape-branded browser. It contains (and Netscape makes source code available for) many files from the Mozilla project, which are under the MPL. But it also contains proprietary code, for example to integrate with the AOL Instant Messenger service.

-
+
How 'viral' is the MPL? If I use MPLed code in my proprietary application, will I have to give all the source code away?
+
+

The MPL has a limited amount of 'copyleft' - more copyleft than the BSD family of licenses, which have no copyleft at all, but less than the LGPL or the GPL. It is based around the definition of a 'Modification' in the license [1.9].

+

What is a Modification? Any changes to MPLed files, or new files into which MPLed code has been copied, are Modifications and so fall under the MPL. New files containing only your code are not Modifications, and not covered by the MPL.

+

Files which fall under the MPL because they are or contain Modifications must be made available as detailed in the license (or elsewhere in this FAQ.) Other files may be kept proprietary.

+

One well-known example of this is the Netscape-branded browser. It contains (and Netscape makes source code available for) many files from the Mozilla project, which are under the MPL. But it also contains proprietary code, for example to integrate with the AOL Instant Messenger service.

+
-
May I combine MPLed code and BSD-licensed code in the same binary?
-
Yes. Mozilla does this - for example libvpx, which decodes WebM video, is under a BSD license.
+
May I combine MPLed code and BSD-licensed code in the same binary?
+
Yes. Mozilla does this - for example libvpx, which decodes WebM video, is under a BSD license.
-
May I combine MPLed code and GPL-licensed code in the same binary?
-
No, unless the MPLed code is also available under the GPL - for example using the Mozilla tri-license. This is because the MPL imposes additional restrictions over and above those imposed by the GPL, which makes it incompatible with section 6 of GPL version 2, and the corresponding section in any later versions.
+
May I combine MPLed code and GPL-licensed code in the same binary?
+
No, unless the MPLed code is also available under the GPL - for example using the Mozilla tri-license. This is because the MPL imposes additional restrictions over and above those imposed by the GPL, which makes it incompatible with section 6 of GPL version 2, and the corresponding section in any later versions.
-
Who has the right to publish new versions of the MPL [6.1]?
-
The Mozilla Foundation acquired this right from Netscape at the - time it was founded.
-
-
-
+
Who has the right to publish new versions of the MPL [6.1]?
+
The Mozilla Foundation acquired this right from Netscape at the + time it was founded.
+ + {% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/2.0/combining-mpl-and-gpl.html b/bedrock/mozorg/templates/mozorg/mpl/2.0/combining-mpl-and-gpl.html index 1d44651387a..09d2ced83b3 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/2.0/combining-mpl-and-gpl.html +++ b/bedrock/mozorg/templates/mozorg/mpl/2.0/combining-mpl-and-gpl.html @@ -2,20 +2,14 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('MPL-in-GPL Developer Guidelines') }}{% endblock %} {% block page_desc %}{{ _('Combining MPL-Licensed files with an (L)GPL-Licensed Project: Guidelines for Developers') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

Combining MPL-Licensed files with an (L)GPL-Licensed Project: Guidelines for Developers

+{% block article %} +

Combining MPL-Licensed files with an (L)GPL-Licensed Project: Guidelines for Developers

Introduction

@@ -33,7 +27,7 @@

Unmodified MPL-licensed Files - You can obtain one at http://mozilla.org/MPL/2.0/. Copyright (c) 20xx, MPL Contributor1 contrib1@example.net - +

This is the preferred mechanism, since it makes it easiest to reuse the file in other MPL-licensed projects, as intended by the original author, without prohibiting use in (L)GPL projects.

Unmodified MPL-licensed Files - Adding an (L)GPL notice

If a developer combines unmodified MPL-licensed files into a project with (L)GPL-licensed files, and is required by project policy to use an (L)GPL header, or otherwise wants to do so, the developer may add an (L)GPL notice prior to distribution. It is very important that the developer preserve all other copyright and permission notices as they appeared in the original code, as required by the MPL. In this case, the header should look like this:

@@ -59,9 +53,9 @@

Unmodified MPL-lice You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. - +

Note that:

-
    +

    • the MPL header has not been removed: Section 3.3 requires that the initial distribution of the MPL-licensed materials, in combination with the (L)GPL-licensed materials, be made under the terms of both licenses.

    • no new copyright statements ("Copyright (c) 20xx, The New Distributor") have been added, because no copyrightable changes have been made.

    • adding the additional header has no practical effect, because the file was already usable in combination with (L)GPL code whether or not the header was added.

      • @@ -104,7 +98,7 @@

      Adding Modifications Under the (L)G Copyright (c) 20XX, MPL Contributor1 contrib1@example.net Copyright (c) 20XX, MPL and (L)GPL Contributor2 contrib2@example.net - +

      It is very important that the developer preserve the copyright and permission notices as they appeared in the original code, as required by the MPL. We recommend making a clear separation and using indentation, as in the example above.

      This manner of organizing the notices in the file makes it convenient for developers to choose whether to contribute under the MPL and (L)GPL, or under the (L)GPL alone. If they wish to make their contributions available under the MPL and (L)GPL, they can add their copyright notices to the lower group. If they wish to contribute under the (L)GPL alone, they can add their copyright notices at the top.

      Note, however, that in a single source file it is typically very difficult, and often completely infeasible, to determine which parts of such a file are covered by permissive terms, so if possible, a project should attempt to maintain both licenses, as described in previous sections.

      @@ -116,5 +110,4 @@

      A Note On the LGPL

      Note that, while this article uses (L)GPL throughout, no special license changes are necessary when an MPL-licensed application links against an LGPL-licensed library. In the case of the LGPL, the licensing and notice requirements discussed above apply only when MPL-licensed files are to be included directly in the library itself.

      This work is based on "Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers", authored by the SFLC, to whom we are very grateful. Both that work and this work are available under CC-BY-SA.

-
{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/2.0/faq.html b/bedrock/mozorg/templates/mozorg/mpl/2.0/faq.html index 27ce3c16e69..c7d160a2c63 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/2.0/faq.html +++ b/bedrock/mozorg/templates/mozorg/mpl/2.0/faq.html @@ -2,135 +2,128 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('MPL 2.0 FAQ') }}{% endblock %} {% block page_desc %}{{ _('MPL 2.0 FAQ') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} +{% block article %} +

MPL 2.0 FAQ

+ +
+

About This FAQ

+

This is the Mozilla Public License (MPL) version 2.0 FAQ. It aims to answer the most common questions people have about using and distributing code under the MPL.

+

Please note that, while this FAQ is intended to be accurate and helpful, it is not the license, and may not cover important issues that affect you and your specific situation. As a result, reading the FAQ should not serve as a substitute for reading the license itself, or for seeking legal advice from a lawyer.

+

If you see any errors in this FAQ, or have suggestions for further questions, please email licensing@mozilla.org.

+

The MPL version 1.1 FAQ is still available here but should not be used except as a reference for that license.

+
+ +
+

About MPL

+

Q1: What is the Mozilla Public License?

+

The MPL is a simple copyleft license. The MPL's "file-level" copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions.

+

Q2: Why yet another open source license?

+

The MPL fills a useful space in the spectrum of free and open source software licenses, sitting between the Apache license, which does not require modifications to be shared, and the GNU family of licenses, which requires modifications to be shared under a much broader set of circumstances than the MPL.

+

Q3: Who maintains the MPL?

+

The MPL is maintained by the Mozilla project, a global non-profit community dedicated to building openness, interoperability and individual empowerment into the Internet. The Mozilla project operates under a system of distributed authority known a the Module Ownership System. Like other Mozilla modules, the MPL has a module owner and peers who are responsible for maintaining the license. The current owner and peers are listed at the Module Owners page.

+
+ +
+

Using and Distributing Software Under the License

+

Q4: I want to use the Mozilla Public License for software that I have written. What do I have to do?

+

To apply the Mozilla Public License to software that you have written, add the header from Exhibit A of the license to each source code file in your project. Sample headers for various commenting styles are available here. You may also add additional accurate notices of copyright ownership, such as the name of the copyright holder, but this is not necessary.

+

Q5: I want to use software which is available under the MPL. What do I have to do?

+

Nothing. Like all other free and open source software, software available under the MPL is available for anyone (including individuals and companies) to use for any purpose. The MPL only creates obligations for you if you want to distribute the software outside your organization.

+

Q6: I want to distribute software which is available under the MPL, either changed or unchanged, within my organization. What do I have to do?

+

Nothing. The right to private modification and distribution (and inside a company or organization counts as 'private') is another right guaranteed by free and open source software licenses, including the MPL.

+

Q7: I want to distribute (outside my organization) complete and unchanged executable programs built from MPL-licensed software by someone other than me. What do I have to do?

+

As long as the people who distributed the program to you have complied with the MPL, typically nothing. To check and see if the people who distributed the program to you have complied with the MPL, look for the notice that tells you where the software is available in Source Code form (i.e., check that it complies with Section 3.2(a)), and then check that the Source Code is available in that place, including a notice that informs you that the Source Code is available under the terms of the MPL (i.e., check that it complies with Section 3.1).

+

If you are only distributing libraries, or are only distributing some parts of the program as you received it, it could be that you need to take extra steps to make sure that users of your program are appropriately informed of their rights, as required by section 3.2(a).

+

In the case of Mozilla Firefox, the Mozilla-provided executable programs already meet the requirements of Section 3, including the notices required by Section 3.1 and 3.2.

+

If you want to add your own terms when you distribute the software, Section 3.2(b) requires that those terms must not restrict a recipient's rights under the MPL, and if you offer a warranty on the software, Section 3.5 requires you to make clear that it is offered by you alone.

+

Q8: I want to distribute (outside my organization) executable programs or libraries that I have compiled from someone else's unchanged MPL-licensed source code, either standalone or part of a larger work. What do I have to do?

+

You must inform the recipients where they can get the source for the MPLed code in the executable program or library you are distributing (i.e., you must comply with Section 3.2). You may distribute any executables you create under a license of your choosing, as long as that license does not interfere with the recipients' rights to the source under the terms of the MPL.

+

Q9: I want to distribute (outside my organization) MPL-licensed source code that I have modified. What do I have to do?

+

To see the complete set of requirements, read the license. However, generally:

+ +

Q10: I want to distribute (outside my organization) an executable program based on MPL-licensed source code that I have modified. What do I have to do?

+

You must make available the MPL-licensed portions of the source code as described in the previous question, and inform the recipients how they can obtain such source code (Section 3.2).

+
+ +
+

Other Common Questions

+ +

Q11: How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?

+

No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.

+ +

Q12: How does the scope of the MPL's copyleft compare with the LGPL and GPL's copyleft?

+

Broadly speaking, the scope of the MPL, LGPL, and GPL can be summarized this way:

+ +

However, we would recommend reading the licenses to better understand their scope, and in particular, to understand how the LGPL and GPL define "based on."

+ +

Q13: May I combine MPL-licensed code and BSD-licensed code in the same executable program? What about Apache?

+

Yes to both. Mozilla currently does this with BSD-licensed code. For example, libvpx, which is used in Firefox to decode WebM video, is under a BSD license.

+ +

Q14: May I combine MPL-licensed code and (L)GPL-licensed code in the same executable program?

+

Yes, by creating a "Larger Work" under the terms of Section 3.3. In particular, three requirements must be met:

+
    +

  1. The software must not be “Incompatible With Secondary Licenses.” Software can become “Incompatible With Secondary Licenses” in one of two ways: the original author marks it as such by adding the file header in Exhibit B, or the original author published the software under MPL 1.1 and did not dual- or tri-license the code with the (L)GPL.

    2. +

  2. The Larger Work must be "a combination of Covered Software with a work governed by one or more Secondary Licenses." So you can't just say "I really prefer (L)GPL" - you must have a need to combine with another, existing GPL work. (This is different from a traditional dual-license, which does not require you to combine, and instead allows you to simply say "I've decided to be GPL-only.")

    3. +

  3. You must "additionally distribute" under (L)GPL. In other words, you must make the MPL-licensed source code available to your recipients under both MPL and (L)GPL. Someone downstream from your recipients can then take under (L)GPL-only or MPL-only. This is different from a traditional dual-license, which never requires publication under both licenses, and so always gives you the option of releasing incompatibly-licensed code.

    4. +
+

No GPL-compatible license can perfectly preserve the original author's ability to reuse downstream derivatives, but the last two restrictions serve to increase the probability that such reuse can occur in the broadest possible set of circumstances.

+

We have written a document explaining how to do this in practical terms, i.e. what to do about license headers and so on.

+ +

Q15: Does Sec. 3.3's ability to mix with other licenses lead to more license proliferation?

+

Mozilla's experience with MPL 1.1, and the experience of some of our advisors, was that in practice license incompatibility is often resolved by the use of custom additional permissions or dual- and tri- licenses. Each combination of dual or tri-license, or custom additional permissions, further complicates license interaction and proliferation analysis. We feel that Sec. 3.3, by replacing these ad-hoc solutions with a single, standardized solution for the most common situation, should reduce, rather than increase, the practical risk of license proliferation.

+ +

Q16: Is "minified" JavaScript Source Code?

+

No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.

+

This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.

+

Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.

+ +

Q17: What does "distribute" mean?

+

The MPL uses "distribute" in the sense of delivery of a copy of the software to another person or entity. We do not use distribute to mean "make available" in the sense of "making functionality available over the web without delivery of a copy of the software." So e.g. in a web-based application, the code which runs on the server is not 'distributed' to the user, but the code which is sent to the client (e.g. HTML, CSS, JavaScript) does count as 'distributed'.

+ +

Q18: Should MPL be used for non-software works?

+

MPL was written with software in mind, and should generally only be used for software. However, for consistency and simplicity, it may be appropriate to use the MPL for non-software works (such as documentation, images, and sound files) that are written primarily for use in MPL-licensed software.

+ +

Q19: Can I remove or change notice statements which are displayed by a piece of software?

+

Section 3.4 prohibits most changes to license notices that are seen when looking at the source code. We do not encourage changing licensing and notice statements which are displayed when the software is executed. However, such changes are permitted by the license, so that source code can be reused between software with very different user interfaces.

+ +

Q20: I've downloaded a copy of some MPL software. Am I an "owner" of that software for purposes of Section 1.1?

+

No. Merely downloading the software does not make you an owner for the purposes of Section 1.1.

+ +

Q21: Does the MPL 2.0 give me permission to make my own license by changing the MPL?

+

Yes but, as with MPL 1.1, we strongly discourage you from doing so. It will almost certainly make your software much less popular and less widely used. Software developers and companies are already aware of and understand popular licenses like the MPL. If you create your own, they will have to perform a legal assessment of your changes - and may conclude it's not worth the effort to do so. Or, you may accidentally make your software incompatible with the Free Software Definition or the Open Source Definition, or with the other commonly-used free software licenses that MPL 2.0 is compatible with.

+ +

If you like the MPL 2.0, just use it as-is - it is a clear, modern, internationalized, generic license. There is nothing Mozilla-specific, or specific to a particular country or project, in its licensing terms.

For more information on the problems that creating your own license causes, see the Wikipedia article on license proliferation.

+ +

Q22: Does MPL 2.0 require that the MPL 2.0 license notice header be included in every file?

+

The license notice must be in some way "attached" to each file. (Sec. 1.4.) In cases where putting it in the file is impossible or impractical, that requirement can be fulfilled by putting the notice somewhere that a recipient "would be likely to look for such a notice," such as a LICENSE file in the same directory as the file. (Ex. A.) The license notice is as short as possible (3 lines) to make it easy to put in as many different types of files as possible.

+

While the license permits putting the header somewhere other than the file itself, individual files often end up being distributed on their own, without the rest of the software they were authored with. As a result, putting the license notice in the file is the surest way to ensure that recipients are always notified.

+

For your convenience, Mozilla has produced boilerplate headers formatted with several common 'comment' syntaxes, suitable for copying and pasting.

+ +

Q23: What does "used" mean in the definition of Contributor Version (Sec. 1.2)?

+

“Used” in Section 1.2 means an action taken in the process of creating a Contribution or Modification.

+ +

Q24: "Contributor" means one who creates "Covered Software", and "Covered Software" includes "the Executable Form" of MPL-licensed source code. Does this mean that compiling unmodified code to create an executable makes someone a Contributor?

+

No. We intend Contributors to be those who have created an addition or change to the program that adds new expression -- copyrightable material -- to pre-existing code. Mere compilation is not an act of authorship it does not create such an addition, and so does not make you a Contributor.

+ +

Q25: What happens if someone doesn't use the per-file boilerplate, and just ships a copy of the full MPL 2 with their code?

+

The code is licensed under the plain MPL 2. It is not considered Incompatible with Secondary Licenses. Making code Incompatible with Secondary Licenses requires an active choice on the part of the licensor; it is not the default. The notice in Exhibit B is not considered "attached" merely by being present as the Exhibit B of a copy of the full MPL 2.

+

The only exception is if the code used to be straight MPL 1.1 and was upgraded to MPL 2, in which case it would be Incompatible with Secondary Licenses (Sec. 1.5 b).

-{% block content %} - -
-

MPL 2.0 FAQ

- -
-

About This FAQ

-

This is the Mozilla Public License (MPL) version 2.0 FAQ. It aims to answer the most common questions people have about using and distributing code under the MPL.

-

Please note that, while this FAQ is intended to be accurate and helpful, it is not the license, and may not cover important issues that affect you and your specific situation. As a result, reading the FAQ should not serve as a substitute for reading the license itself, or for seeking legal advice from a lawyer.

-

If you see any errors in this FAQ, or have suggestions for further questions, please email licensing@mozilla.org.

-

The MPL version 1.1 FAQ is still available here but should not be used except as a reference for that license.

-
- -
-

About MPL

-

Q1: What is the Mozilla Public License?

-

The MPL is a simple copyleft license. The MPL's "file-level" copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions.

-

Q2: Why yet another open source license?

-

The MPL fills a useful space in the spectrum of free and open source software licenses, sitting between the Apache license, which does not require modifications to be shared, and the GNU family of licenses, which requires modifications to be shared under a much broader set of circumstances than the MPL.

-

Q3: Who maintains the MPL?

-

The MPL is maintained by the Mozilla project, a global non-profit community dedicated to building openness, interoperability and individual empowerment into the Internet. The Mozilla project operates under a system of distributed authority known a the Module Ownership System. Like other Mozilla modules, the MPL has a module owner and peers who are responsible for maintaining the license. The current owner and peers are listed at the Module Owners page.

-
- -
-

Using and Distributing Software Under the License

-

Q4: I want to use the Mozilla Public License for software that I have written. What do I have to do?

-

To apply the Mozilla Public License to software that you have written, add the header from Exhibit A of the license to each source code file in your project. Sample headers for various commenting styles are available here. You may also add additional accurate notices of copyright ownership, such as the name of the copyright holder, but this is not necessary.

-

Q5: I want to use software which is available under the MPL. What do I have to do?

-

Nothing. Like all other free and open source software, software available under the MPL is available for anyone (including individuals and companies) to use for any purpose. The MPL only creates obligations for you if you want to distribute the software outside your organization.

-

Q6: I want to distribute software which is available under the MPL, either changed or unchanged, within my organization. What do I have to do?

-

Nothing. The right to private modification and distribution (and inside a company or organization counts as 'private') is another right guaranteed by free and open source software licenses, including the MPL.

-

Q7: I want to distribute (outside my organization) complete and unchanged executable programs built from MPL-licensed software by someone other than me. What do I have to do?

-

As long as the people who distributed the program to you have complied with the MPL, typically nothing. To check and see if the people who distributed the program to you have complied with the MPL, look for the notice that tells you where the software is available in Source Code form (i.e., check that it complies with Section 3.2(a)), and then check that the Source Code is available in that place, including a notice that informs you that the Source Code is available under the terms of the MPL (i.e., check that it complies with Section 3.1).

-

If you are only distributing libraries, or are only distributing some parts of the program as you received it, it could be that you need to take extra steps to make sure that users of your program are appropriately informed of their rights, as required by section 3.2(a).

-

In the case of Mozilla Firefox, the Mozilla-provided executable programs already meet the requirements of Section 3, including the notices required by Section 3.1 and 3.2.

-

If you want to add your own terms when you distribute the software, Section 3.2(b) requires that those terms must not restrict a recipient's rights under the MPL, and if you offer a warranty on the software, Section 3.5 requires you to make clear that it is offered by you alone.

-

Q8: I want to distribute (outside my organization) executable programs or libraries that I have compiled from someone else's unchanged MPL-licensed source code, either standalone or part of a larger work. What do I have to do?

-

You must inform the recipients where they can get the source for the MPLed code in the executable program or library you are distributing (i.e., you must comply with Section 3.2). You may distribute any executables you create under a license of your choosing, as long as that license does not interfere with the recipients' rights to the source under the terms of the MPL.

-

Q9: I want to distribute (outside my organization) MPL-licensed source code that I have modified. What do I have to do?

-

To see the complete set of requirements, read the license. However, generally:

-
    -

  • You must inform the recipients that the source code is made available to them under the terms of the MPL (Section 3.1), including any Modifications (as defined in Section 1.10) that you have created.

    • -

  • You must make the grants described in Section 2 of the license.

    • -

  • You must respect the restrictions on removing or altering notices in the source code (Section 3.4).

    • -
-

Q10: I want to distribute (outside my organization) an executable program based on MPL-licensed source code that I have modified. What do I have to do?

-

You must make available the MPL-licensed portions of the source code as described in the previous question, and inform the recipients how they can obtain such source code (Section 3.2).

-
- -
-

Other Common Questions

- -

Q11: How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?

-

No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.

- -

Q12: How does the scope of the MPL's copyleft compare with the LGPL and GPL's copyleft?

-

Broadly speaking, the scope of the MPL, LGPL, and GPL can be summarized this way:

-
    -
  • MPL: The copyleft applies to any files containing MPLed code. -
  • LGPL: The copyleft applies to any library based on LGPLed code. -
  • GPL: The copyleft applies to all software based on GPLed code. -
-

However, we would recommend reading the licenses to better understand their scope, and in particular, to understand how the LGPL and GPL define "based on."

- -

Q13: May I combine MPL-licensed code and BSD-licensed code in the same executable program? What about Apache?

-

Yes to both. Mozilla currently does this with BSD-licensed code. For example, libvpx, which is used in Firefox to decode WebM video, is under a BSD license.

- -

Q14: May I combine MPL-licensed code and (L)GPL-licensed code in the same executable program?

-

Yes, by creating a "Larger Work" under the terms of Section 3.3. In particular, three requirements must be met:

-
    -

  1. The software must not be “Incompatible With Secondary Licenses.” Software can become “Incompatible With Secondary Licenses” in one of two ways: the original author marks it as such by adding the file header in Exhibit B, or the original author published the software under MPL 1.1 and did not dual- or tri-license the code with the (L)GPL.

    2. -

  2. The Larger Work must be "a combination of Covered Software with a work governed by one or more Secondary Licenses." So you can't just say "I really prefer (L)GPL" - you must have a need to combine with another, existing GPL work. (This is different from a traditional dual-license, which does not require you to combine, and instead allows you to simply say "I've decided to be GPL-only.")

    3. -

  3. You must "additionally distribute" under (L)GPL. In other words, you must make the MPL-licensed source code available to your recipients under both MPL and (L)GPL. Someone downstream from your recipients can then take under (L)GPL-only or MPL-only. This is different from a traditional dual-license, which never requires publication under both licenses, and so always gives you the option of releasing incompatibly-licensed code.

    4. -
-

No GPL-compatible license can perfectly preserve the original author's ability to reuse downstream derivatives, but the last two restrictions serve to increase the probability that such reuse can occur in the broadest possible set of circumstances.

-

We have written a document explaining how to do this in practical terms, i.e. what to do about license headers and so on.

- -

Q15: Does Sec. 3.3's ability to mix with other licenses lead to more license proliferation?

-

Mozilla's experience with MPL 1.1, and the experience of some of our advisors, was that in practice license incompatibility is often resolved by the use of custom additional permissions or dual- and tri- licenses. Each combination of dual or tri-license, or custom additional permissions, further complicates license interaction and proliferation analysis. We feel that Sec. 3.3, by replacing these ad-hoc solutions with a single, standardized solution for the most common situation, should reduce, rather than increase, the practical risk of license proliferation.

- -

Q16: Is "minified" JavaScript Source Code?

-

No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.

-

This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.

-

Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.

- -

Q17: What does "distribute" mean?

-

The MPL uses "distribute" in the sense of delivery of a copy of the software to another person or entity. We do not use distribute to mean "make available" in the sense of "making functionality available over the web without delivery of a copy of the software." So e.g. in a web-based application, the code which runs on the server is not 'distributed' to the user, but the code which is sent to the client (e.g. HTML, CSS, JavaScript) does count as 'distributed'.

- -

Q18: Should MPL be used for non-software works?

-

MPL was written with software in mind, and should generally only be used for software. However, for consistency and simplicity, it may be appropriate to use the MPL for non-software works (such as documentation, images, and sound files) that are written primarily for use in MPL-licensed software.

- -

Q19: Can I remove or change notice statements which are displayed by a piece of software?

-

Section 3.4 prohibits most changes to license notices that are seen when looking at the source code. We do not encourage changing licensing and notice statements which are displayed when the software is executed. However, such changes are permitted by the license, so that source code can be reused between software with very different user interfaces.

- -

Q20: I've downloaded a copy of some MPL software. Am I an "owner" of that software for purposes of Section 1.1?

-

No. Merely downloading the software does not make you an owner for the purposes of Section 1.1.

- -

Q21: Does the MPL 2.0 give me permission to make my own license by changing the MPL?

-

Yes but, as with MPL 1.1, we strongly discourage you from doing so. It will almost certainly make your software much less popular and less widely used. Software developers and companies are already aware of and understand popular licenses like the MPL. If you create your own, they will have to perform a legal assessment of your changes - and may conclude it's not worth the effort to do so. Or, you may accidentally make your software incompatible with the Free Software Definition or the Open Source Definition, or with the other commonly-used free software licenses that MPL 2.0 is compatible with.

- -

If you like the MPL 2.0, just use it as-is - it is a clear, modern, internationalized, generic license. There is nothing Mozilla-specific, or specific to a particular country or project, in its licensing terms.

For more information on the problems that creating your own license causes, see the Wikipedia article on license proliferation.

- -

Q22: Does MPL 2.0 require that the MPL 2.0 license notice header be included in every file?

-

The license notice must be in some way "attached" to each file. (Sec. 1.4.) In cases where putting it in the file is impossible or impractical, that requirement can be fulfilled by putting the notice somewhere that a recipient "would be likely to look for such a notice," such as a LICENSE file in the same directory as the file. (Ex. A.) The license notice is as short as possible (3 lines) to make it easy to put in as many different types of files as possible.

-

While the license permits putting the header somewhere other than the file itself, individual files often end up being distributed on their own, without the rest of the software they were authored with. As a result, putting the license notice in the file is the surest way to ensure that recipients are always notified.

-

For your convenience, Mozilla has produced boilerplate headers formatted with several common 'comment' syntaxes, suitable for copying and pasting.

- -

Q23: What does "used" mean in the definition of Contributor Version (Sec. 1.2)?

-

“Used” in Section 1.2 means an action taken in the process of creating a Contribution or Modification.

- -

Q24: "Contributor" means one who creates "Covered Software", and "Covered Software" includes "the Executable Form" of MPL-licensed source code. Does this mean that compiling unmodified code to create an executable makes someone a Contributor?

-

No. We intend Contributors to be those who have created an addition or change to the program that adds new expression -- copyrightable material -- to pre-existing code. Mere compilation is not an act of authorship it does not create such an addition, and so does not make you a Contributor.

- -

Q25: What happens if someone doesn't use the per-file boilerplate, and just ships a copy of the full MPL 2 with their code?

-

The code is licensed under the plain MPL 2. It is not considered Incompatible with Secondary Licenses. Making code Incompatible with Secondary Licenses requires an active choice on the part of the licensor; it is not the default. The notice in Exhibit B is not considered "attached" merely by being present as the Exhibit B of a copy of the full MPL 2.

-

The only exception is if the code used to be straight MPL 1.1 and was upgraded to MPL 2, in which case it would be Incompatible with Secondary Licenses (Sec. 1.5 b).

- -

Q26: I would like to distribute source code by using a courier or other physical mechanisms. Is this "reasonable" for purposes of meeting my obligations under Section 3.2(a)?

-

In modern software development, distribution happens almost exclusively over the internet, because of the low cost and convenience. While the MPL allows for alternatives when necessary, in general any mechanism (such as a courier) that adds cost and complexity without a specific, necessary purpose is not reasonable, and so does not comply with the requirements of Section 3.2(a).

+

Q26: I would like to distribute source code by using a courier or other physical mechanisms. Is this "reasonable" for purposes of meeting my obligations under Section 3.2(a)?

+

In modern software development, distribution happens almost exclusively over the internet, because of the low cost and convenience. While the MPL allows for alternatives when necessary, in general any mechanism (such as a courier) that adds cost and complexity without a specific, necessary purpose is not reasonable, and so does not comply with the requirements of Section 3.2(a).

-
{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/2.0/permissive-code-into-mpl.html b/bedrock/mozorg/templates/mozorg/mpl/2.0/permissive-code-into-mpl.html index 43bac6f4fe4..5e4a3d58d28 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/2.0/permissive-code-into-mpl.html +++ b/bedrock/mozorg/templates/mozorg/mpl/2.0/permissive-code-into-mpl.html @@ -2,21 +2,15 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('Permissive-Code-into-MPL Developer Guidelines') }}{% endblock %} {% block page_desc %}{{ _('Copying Permissively-Licensed Code into an MPL 2 File: Guidelines for Developers') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

Copying permissively-Licensed Code into an MPL 2 File: Guidelines for Developers

+{% block article %} +

Copying permissively-Licensed Code into an MPL 2 File: Guidelines for Developers

This document explains what to do when you want to copy a piece of code which is licensed under the BSD, MIT, Apache License 2 or another standard permissive open source licence into an existing Mozilla project file which is licensed under the MPL 2.

@@ -46,7 +40,7 @@

2. Relicense

J. Random Hacker [0] https://www.mozilla.org/MPL/2.0/ - +

The difficulty with this route is that it makes it harder to be certain we can legally send fixes we make to their code back upstream, which is why option 1) is preferred.

In rare circumstances, it might be that it's possible to relicense the MPLed code instead, particularly if it only forms a small part of the resultant combined file. Consult the licensing team if you want to investigate this route.

@@ -64,7 +58,7 @@

3. Boilerplate

* [Full copy of permissively-licensed copyright and permissions notice, * indented two additional spaces] */ - +

So that's the standard MPL 2 header, then the extra sentence "This file incorporates...", then the other boilerplate, indented 2 spaces. For example, for the Apache License 2.0:

 /* This Source Code Form is subject to the terms of the Mozilla Public
@@ -88,9 +82,8 @@ 
3. Boilerplate

  *   See the License for the specific language governing permissions and
  *   limitations under the License.
  */
-
+

As you can see, the additional boilerplate makes this solution sub-optimal - and even more so if a file contains code under two or more permissive licences. And copying code out of such a file gets extremely complicated. This is why it is suggested that the other two routes are investigated first.

As always, if you have questions, contact the licensing team.

-
{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/2.0/revision-faq.html b/bedrock/mozorg/templates/mozorg/mpl/2.0/revision-faq.html index ee648d4bea5..7ae35c93f00 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/2.0/revision-faq.html +++ b/bedrock/mozorg/templates/mozorg/mpl/2.0/revision-faq.html @@ -2,82 +2,75 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('About MPL 2.0: Revision Process and Changes FAQ') }}{% endblock %} {% block page_desc %}{{ _('About MPL 2.0: Revision Process and Changes FAQ') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

About MPL 2.0: Revision Process and Changes FAQ

+{% block article %} +

About MPL 2.0: Revision Process and Changes FAQ

-
-

1. How was MPL 2.0 drafted?

-

MPL 2.0 was drafted over a period of 21 months in a public process that included extensive feedback from a variety of people, including MPL users, lawyers, and open source community groups like the Free Software Foundation and Open Source Initiative.

+
+

1. How was MPL 2.0 drafted?

+

MPL 2.0 was drafted over a period of 21 months in a public process that included extensive feedback from a variety of people, including MPL users, lawyers, and open source community groups like the Free Software Foundation and Open Source Initiative.

-

2. Is the revision process publicly documented?

-

Historical documents about the revision process are available from this website.

+

2. Is the revision process publicly documented?

+

Historical documents about the revision process are available from this website.

-

3. Section 6 of MPL 1.1 says Netscape can update the license, but Mozilla isn't Netscape. Can Mozilla still update the license?

-

As part of the creation of the Mozilla Foundation, Netscape assigned - the ability to publish new licenses to Mozilla, making the Mozilla - Foundation Netscape's successor for this purpose.

+

3. Section 6 of MPL 1.1 says Netscape can update the license, but Mozilla isn't Netscape. Can Mozilla still update the license?

+

As part of the creation of the Mozilla Foundation, Netscape assigned + the ability to publish new licenses to Mozilla, making the Mozilla + Foundation Netscape's successor for this purpose.

-

Upgrading a project from MPL 1.1 to MPL - 2.0

+

Upgrading a project from MPL 1.1 to MPL + 2.0

-

4. I use MPL 1.1 for my project. Why should I upgrade to MPL 2.0?

-

If your project is licensed under MPL 1.1, there are several important reasons why you should move your project to MPL 2.0:

-
    -
  • MPL 2.0 makes compliance simpler, both for you and for people who receive code from you.
    • -
  • MPL 2.0 provides patent protections for you and your contributors more in line with those of other open source licenses, and allows your entire community to protect any contributor if the contributor is sued.
    • -
  • Compatibility with Apache and GPL makes code reuse and redistribution easier for you and for the broader open source community.
    • -
-

For a more complete list of reasons why, see the question about "what has changed", below.

+

4. I use MPL 1.1 for my project. Why should I upgrade to MPL 2.0?

+

If your project is licensed under MPL 1.1, there are several important reasons why you should move your project to MPL 2.0:

+
    +
  • MPL 2.0 makes compliance simpler, both for you and for people who receive code from you.
    • +
  • MPL 2.0 provides patent protections for you and your contributors more in line with those of other open source licenses, and allows your entire community to protect any contributor if the contributor is sued.
    • +
  • Compatibility with Apache and GPL makes code reuse and redistribution easier for you and for the broader open source community.
    • +
+

For a more complete list of reasons why, see the question about "what has changed", below.

-

5. I am the author of code which I have placed under MPL version 1.1. How do I license my project under MPL 2.0 instead of MPL 1.1?

-

If you are the author, to change the license from MPL 1.1 to MPL 2.0, replace the old license header with the new header from MPL 2.0 Exhibit A.

+

5. I am the author of code which I have placed under MPL version 1.1. How do I license my project under MPL 2.0 instead of MPL 1.1?

+

If you are the author, to change the license from MPL 1.1 to MPL 2.0, replace the old license header with the new header from MPL 2.0 Exhibit A.

-

6. I am distributing code written by someone else under the terms of MPL 1.1. Can I distribute that code under the terms of MPL 2.0 instead of MPL 1.1? If so, how?

-

Yes, you can, because MPL 1.1 allows anyone who received code under the terms of MPL 1.1 to distribute under the terms of a later version of the MPL.

-

To do this, replace the old license header with the new header from MPL 2.0 Exhibit A. If you received the code under only MPL 1.1, and not a combination of the MPL plus a member of the GNU family of licenses (such as the Mozilla Tri-License), then you must also add the text of Exhibit B to the license header.

+

6. I am distributing code written by someone else under the terms of MPL 1.1. Can I distribute that code under the terms of MPL 2.0 instead of MPL 1.1? If so, how?

+

Yes, you can, because MPL 1.1 allows anyone who received code under the terms of MPL 1.1 to distribute under the terms of a later version of the MPL.

+

To do this, replace the old license header with the new header from MPL 2.0 Exhibit A. If you received the code under only MPL 1.1, and not a combination of the MPL plus a member of the GNU family of licenses (such as the Mozilla Tri-License), then you must also add the text of Exhibit B to the license header.

-

Changes from MPL 1.1

+

Changes from MPL 1.1

-

7. What has not changed between MPL 1.1 and MPL 2.0?

-

The most important part of the license - the file-level copyleft - is essentially the same in MPL 2.0 and MPL 1.1.

+

7. What has not changed between MPL 1.1 and MPL 2.0?

+

The most important part of the license - the file-level copyleft - is essentially the same in MPL 2.0 and MPL 1.1.

-

8. What has changed between MPL 1.1 and MPL - 2.0?

-

The primary change is simplification. For example, rather than exactly specifying the amount of time source code must be available, the source code must simply be made available when the executable is made available. License headers have been made shorter, and notification requirements have been simplified. Overall, the license is substantially shorter and should be easier to understand.

-

In addition, a handful of new features have been added to the license. For example, the license is now compatible with the Apache license - anyone who complies with the terms of the MPL should also be compliant with the Apache license's terms. Similarly, by default, the license allows the code to be distributed alongside code licensed under the GPL or LGPL. In addition, patent protections have been brought more in line with what other licenses (such as Apache) use, while also allowing any member of a community to defend a contributor who has been sued for infringement.

-

A word-by-word redline of all changes is also available for those seeking to analyze the changes in more detail. Note, however, that the changes are extensive, and you may find that simply reading the new license itself will provide a clearer understanding of its contents.

+

8. What has changed between MPL 1.1 and MPL + 2.0?

+

The primary change is simplification. For example, rather than exactly specifying the amount of time source code must be available, the source code must simply be made available when the executable is made available. License headers have been made shorter, and notification requirements have been simplified. Overall, the license is substantially shorter and should be easier to understand.

+

In addition, a handful of new features have been added to the license. For example, the license is now compatible with the Apache license - anyone who complies with the terms of the MPL should also be compliant with the Apache license's terms. Similarly, by default, the license allows the code to be distributed alongside code licensed under the GPL or LGPL. In addition, patent protections have been brought more in line with what other licenses (such as Apache) use, while also allowing any member of a community to defend a contributor who has been sued for infringement.

+

A word-by-word redline of all changes is also available for those seeking to analyze the changes in more detail. Note, however, that the changes are extensive, and you may find that simply reading the new license itself will provide a clearer understanding of its contents.

-

9. Why did the new license remove the government entities language?

-

Software licensed under the MPL is a commercial item as defined in 48 C.F.R. 2.101, unless it was originally written at the direction, and for the use, of the US government. As a result, removing the language from the license simplifies the license without changing the rights and responsibilities that US Government users have towards MPL-licensed code.

+

9. Why did the new license remove the government entities language?

+

Software licensed under the MPL is a commercial item as defined in 48 C.F.R. 2.101, unless it was originally written at the direction, and for the use, of the US government. As a result, removing the language from the license simplifies the license without changing the rights and responsibilities that US Government users have towards MPL-licensed code.

-

10. Why doesn't the new license require distributors to include a complete copy of the license with the distributed Source Code?

-

When MPL 1.1 was written, source code distribution occurred primarily through tarballs and zip files. In contrast, modern software distribution often occurs on a file-by-file basis over the web (e.g., http://hg.mozilla.org). As a result, MPL 2.0 requires distributors to tell recipients how to get the license (for example, by linking to it in the header of a single source file), rather than requiring them to distribute the entire license itself. In most cases, distributing the license with the code - as was required in MPL 1.1 - is still the best and easiest way to meet this requirement. However, given the diversity of modern source code and executable distribution practices, it was sensible to give more flexibilty and place the burden on the distributor to pick an effective notification mechanism.

+

10. Why doesn't the new license require distributors to include a complete copy of the license with the distributed Source Code?

+

When MPL 1.1 was written, source code distribution occurred primarily through tarballs and zip files. In contrast, modern software distribution often occurs on a file-by-file basis over the web (e.g., http://hg.mozilla.org). As a result, MPL 2.0 requires distributors to tell recipients how to get the license (for example, by linking to it in the header of a single source file), rather than requiring them to distribute the entire license itself. In most cases, distributing the license with the code - as was required in MPL 1.1 - is still the best and easiest way to meet this requirement. However, given the diversity of modern source code and executable distribution practices, it was sensible to give more flexibilty and place the burden on the distributor to pick an effective notification mechanism.

-

11. Why did the new license remove the reference to build scripts and documentation from the definition of Source Code?

-

If you choose to license software under the MPL, it is considered a best practice to release all of the software, including interface files and build scripts, under the MPL. However, since these terms only apply to specific types of software distributed in specific ways, and MPL is now applied to a wide variety of software distributed in a number of different ways, we removed these reference and will allow the broader definition of "preferred form" to be interpreted as appropriate to a given situation.

+

11. Why did the new license remove the reference to build scripts and documentation from the definition of Source Code?

+

If you choose to license software under the MPL, it is considered a best practice to release all of the software, including interface files and build scripts, under the MPL. However, since these terms only apply to specific types of software distributed in specific ways, and MPL is now applied to a wide variety of software distributed in a number of different ways, we removed these reference and will allow the broader definition of "preferred form" to be interpreted as appropriate to a given situation.

-

12. Section 3.2 now requires that I "inform" recipients how they can obtain the Source Code form. Could you give some examples of what it means to "inform"?

-

Historically, informing recipients of source availability was done by means of the "About" box of a piece of software. However, other mechanisms for informing users are also acceptable when appropriate for the type of software being distributed. As a specific example, when using MPL-licensed JavaScript on a website, recipients could be informed by having links to the source in the "Legal" or "Notices" section of the website. More generally, notices should be put in the place a reasonable person is likely to look for legal information about the software they have recieved.

+

12. Section 3.2 now requires that I "inform" recipients how they can obtain the Source Code form. Could you give some examples of what it means to "inform"?

+

Historically, informing recipients of source availability was done by means of the "About" box of a piece of software. However, other mechanisms for informing users are also acceptable when appropriate for the type of software being distributed. As a specific example, when using MPL-licensed JavaScript on a website, recipients could be informed by having links to the source in the "Legal" or "Notices" section of the website. More generally, notices should be put in the place a reasonable person is likely to look for legal information about the software they have recieved.

-

13. Unlike MPL 1.1, MPL 2.0 contains explicit provisions for distribution alongside GPL- and LGPL-licensed code. Why?

-

Providing an explicit mechanism by which MPL and GPL code can be distributed together has several significant benefits:

-
    -

  • It allows elimination of the common dual and tri-license approach, which reduces license proliferation, since (for compatibility and proliferation purposes) each dual-license and tri-license is a separate license.

    • -

  • Along with Apache compatibility, it creates a series of upwards-compatible free software licenses covering much of the world's free and open source software.

    • -

  • It helps protect the original licensor's ability to reintegrate modifications made downstream, by requiring that the initial distribution of changes occurs under both licenses and not just the GPL.

    • -
-
-
+

13. Unlike MPL 1.1, MPL 2.0 contains explicit provisions for distribution alongside GPL- and LGPL-licensed code. Why?

+

Providing an explicit mechanism by which MPL and GPL code can be distributed together has several significant benefits:

+ +
{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/headers/index.html b/bedrock/mozorg/templates/mozorg/mpl/headers/index.html index d07ae436d53..2c8311a62a0 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/headers/index.html +++ b/bedrock/mozorg/templates/mozorg/mpl/headers/index.html @@ -2,20 +2,14 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at https://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('Mozilla License Headers') }}{% endblock %} {% block page_desc %}{{ _('Mozilla License Headers') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

Mozilla License Headers

+{% block article %} +

Mozilla License Headers

This page gives copy-and-pasteable license headers for Mozilla code. When adding license headers to new files to be checked in to the Mozilla source tree, always use the appropriate one of the following.

@@ -25,22 +19,22 @@

MPL 2

/* This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at https://mozilla.org/MPL/2.0/. */ - +
 # This Source Code Form is subject to the terms of the Mozilla Public
 # License, v. 2.0. If a copy of the MPL was not distributed with this
 # file, You can obtain one at https://mozilla.org/MPL/2.0/.
-
+
 <!-- This Source Code Form is subject to the terms of the Mozilla Public
    - License, v. 2.0. If a copy of the MPL was not distributed with this
    - file, You can obtain one at https://mozilla.org/MPL/2.0/. -->
-
+
 This Source Code Form is subject to the terms of the Mozilla Public
 License, v. 2.0. If a copy of the MPL was not distributed with this
 file, You can obtain one at https://mozilla.org/MPL/2.0/.
-
+
@@ -49,20 +43,19 @@

Public Domain

 /* Any copyright is dedicated to the Public Domain.
  * https://creativecommons.org/publicdomain/zero/1.0/ */
-
+
 # Any copyright is dedicated to the Public Domain.
 # https://creativecommons.org/publicdomain/zero/1.0/
-
+
 <!-- Any copyright is dedicated to the Public Domain.
    - https://creativecommons.org/publicdomain/zero/1.0/ -->
-
+
 Any copyright is dedicated to the Public Domain.
 https://creativecommons.org/publicdomain/zero/1.0/
-
+

Licensing questions? Ask in mozilla.legal.

-
{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/historical.html b/bedrock/mozorg/templates/mozorg/mpl/historical.html index 7829435a461..5336ab5344b 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/historical.html +++ b/bedrock/mozorg/templates/mozorg/mpl/historical.html @@ -1,49 +1,42 @@ {# This Source Code Form is subject to the terms of the Mozilla Public -# License, v. 2.0. If a copy of the MPL was not distributed with this -# file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} + # License, v. 2.0. If a copy of the MPL was not distributed with this + # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('Historical Licensing Documents') }}{% endblock %} {% block page_desc %}{{ _('Historical Licensing Documents') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

Historical Licensing Documents

+{% block article %} +

Historical Licensing Documents

-
-

These files are made available for historical and reference purposes only, and should not be used to license software.

-
-
Mozilla Public License, version 1.1
-
This is the Mozilla Public License, version 1.1. It is also available in plain text. MPL 1.1 is obsoleted by MPL 2.0, and Mozilla strongly recommends against using this license for new code.
+
+

These files are made available for historical and reference purposes only, and should not be used to license software.

+
+
Mozilla Public License, version 1.1
+
This is the Mozilla Public License, version 1.1. It is also available in plain text. MPL 1.1 is obsoleted by MPL 2.0, and Mozilla strongly recommends against using this license for new code.
-
MPL version 1.1 FAQ
-
This is the FAQ for MPL 1.1. Because MPL 1.1 has been replaced by MPL 2.0, this FAQ should be used for historical reference purposes only.
+
MPL version 1.1 FAQ
+
This is the FAQ for MPL 1.1. Because MPL 1.1 has been replaced by MPL 2.0, this FAQ should be used for historical reference purposes only.
-
Netscape Public License, version 1.1
-
This is the Netscape Public License, in the form of Amendments to the Mozilla Public License, along with the MPL itself. It is also available in plain text. NPL 1.1 is obsolete and should not be used.
+
Netscape Public License, version 1.1
+
This is the Netscape Public License, in the form of Amendments to the Mozilla Public License, along with the MPL itself. It is also available in plain text. NPL 1.1 is obsolete and should not be used.
-
Relicensing FAQ
-
This gives the details of the process we used between 2001 and 2004 to change the Mozilla source code from MPL or NPL only to the MPL/GPL/LGPL tri-licence.
+
Relicensing FAQ
+
This gives the details of the process we used between 2001 and 2004 to change the Mozilla source code from MPL or NPL only to the MPL/GPL/LGPL tri-licence.
-
Annotated Netscape Public License, version 1.0, and
Annotated Mozilla Public License, version 1.0
-
Since legal documents are difficult for non-lawyers to read, Mozilla has in the past provided a version of the license which contains informal explanations of various sections of the license, in the form of hyperlinks. Note that these explanations are not the license. The explanations are not a legal document, or legal advice. If you need to know exactly what the license requires, you need to read and understand the license itself; if you need legal advice, you need to talk to a lawyer. The annotations are merely a good faith effort to explain the license in simpler language.
+
Annotated Netscape Public License, version 1.0, and
Annotated Mozilla Public License, version 1.0
+
Since legal documents are difficult for non-lawyers to read, Mozilla has in the past provided a version of the license which contains informal explanations of various sections of the license, in the form of hyperlinks. Note that these explanations are not the license. The explanations are not a legal document, or legal advice. If you need to know exactly what the license requires, you need to read and understand the license itself; if you need legal advice, you need to talk to a lawyer. The annotations are merely a good faith effort to explain the license in simpler language.
-
Netscape Public License, version 1.0
-
This is the license under which the Mozilla source code was initially released. It is also available in plain text. The NPL is obsolete and should not be used.
+
Netscape Public License, version 1.0
+
This is the license under which the Mozilla source code was initially released. It is also available in plain text. The NPL is obsolete and should not be used.
-
Mozilla Public License, version 1.0
-
This is the original version of the MPL. It is also available in plain text. MPL 1.0 is obsolete and should not be used.
+
Mozilla Public License, version 1.0
+
This is the original version of the MPL. It is also available in plain text. MPL 1.0 is obsolete and should not be used.
-
NPL version 1.0 FAQ
-
This is a set of Frequently Asked Questions about NPL and MPL 1.0, and about the process by which we arrived at these licenses.
-
-
-
+
NPL version 1.0 FAQ
+
This is a set of Frequently Asked Questions about NPL and MPL 1.0, and about the process by which we arrived at these licenses.
+ + {% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/index.html b/bedrock/mozorg/templates/mozorg/mpl/index.html index 6441ff29d25..0d7ef60f63e 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/index.html +++ b/bedrock/mozorg/templates/mozorg/mpl/index.html @@ -1,45 +1,38 @@ {# This Source Code Form is subject to the terms of the Mozilla Public -# License, v. 2.0. If a copy of the MPL was not distributed with this -# file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} + # License, v. 2.0. If a copy of the MPL was not distributed with this + # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('Mozilla Public Licence') }}{% endblock %} {% block page_desc %}{{ _('About the Licence') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

Mozilla Public License

- -
-

About the License

-

Mozilla is the custodian of the Mozilla Public License ("MPL"), an open source/free software license.

-

The current version of the license is MPL 2.0 (html | plain text). If you want to use or distribute code licensed under the MPL 2.0 and have questions about it, you may want to read the FAQ.

-

MPL 2.0 Revision Process

-

The release of MPL 2.0 was the result of a two year process that revised MPL 1.1. A Revision FAQ documents this process, and explains the most significant changes made.

-

Historical Documents

-

Various historical documents relating to the Mozilla and Netscape Public Licenses are available, including deprecated versions of the license such as MPL 1.1.

-
- -
-

Mozilla Licensing Information

-

The Mozilla Project is only one of many users of the MPL, but because many people come to this page looking for information about Mozilla's open source licensing policies and practices, we've provided the information below as a reference. -

Correctly Licensing New Source Code

-

Any new code checked into Mozilla's source repositories needs to comply with Mozilla's source code licensing policy. Please use the appropriate header text at the top of each file.

-

Licenses For Existing Source Code

-

Most Mozilla software projects use the MPL, but some have different terms. Detailed information on the licensing of existing code can be found by inspecting its license headers, or by visiting the license information page in the relevant Mozilla software.

-

For information on how other things are licensed, including Mozilla's trademarks and websites, see our general licensing information page.

-
- -
-

Questions?

-

If, after reading all the above carefully (particularly the FAQ) you have a further question about the MPL or the licensing terms of Mozilla project code, please send it to licensing@mozilla.org. -

-
+{% block article %} +

Mozilla Public License

+ +
+

About the License

+

Mozilla is the custodian of the Mozilla Public License ("MPL"), an open source/free software license.

+

The current version of the license is MPL 2.0 (html | plain text). If you want to use or distribute code licensed under the MPL 2.0 and have questions about it, you may want to read the FAQ.

+

MPL 2.0 Revision Process

+

The release of MPL 2.0 was the result of a two year process that revised MPL 1.1. A Revision FAQ documents this process, and explains the most significant changes made.

+

Historical Documents

+

Various historical documents relating to the Mozilla and Netscape Public Licenses are available, including deprecated versions of the license such as MPL 1.1.

+
+ +
+

Mozilla Licensing Information

+

The Mozilla Project is only one of many users of the MPL, but because many people come to this page looking for information about Mozilla's open source licensing policies and practices, we've provided the information below as a reference. +

Correctly Licensing New Source Code

+

Any new code checked into Mozilla's source repositories needs to comply with Mozilla's source code licensing policy. Please use the appropriate header text at the top of each file.

+

Licenses For Existing Source Code

+

Most Mozilla software projects use the MPL, but some have different terms. Detailed information on the licensing of existing code can be found by inspecting its license headers, or by visiting the license information page in the relevant Mozilla software.

+

For information on how other things are licensed, including Mozilla's trademarks and websites, see our general licensing information page.

+
+ +
+

Questions?

+

If, after reading all the above carefully (particularly the FAQ) you have a further question about the MPL or the licensing terms of Mozilla project code, please send it to licensing@mozilla.org. +

{% endblock %} diff --git a/bedrock/mozorg/templates/mozorg/mpl/license-policy.html b/bedrock/mozorg/templates/mozorg/mpl/license-policy.html index 4ca957645ef..c1c6629ebf4 100644 --- a/bedrock/mozorg/templates/mozorg/mpl/license-policy.html +++ b/bedrock/mozorg/templates/mozorg/mpl/license-policy.html @@ -1,21 +1,15 @@ {# This Source Code Form is subject to the terms of the Mozilla Public -# License, v. 2.0. If a copy of the MPL was not distributed with this -# file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} + # License, v. 2.0. If a copy of the MPL was not distributed with this + # file, You can obtain one at http://mozilla.org/MPL/2.0/. -#} -{% extends "mozorg/base-resp.html" %} +{% extends "mozorg/base.html" %} {% block page_title %}{{ _('Mozilla Foundation License Policy') }}{% endblock %} {% block page_desc %}{{ _('Mozilla Foundation License Policy') }}{% endblock %} -{% block page_css %} - {{ css_bundle('mpl') }} -{% endblock %} - -{% block content %} - -
-

Mozilla Source Code License Policy

+{% block article %} +

Mozilla Source Code License Policy

Version 4.0

@@ -23,11 +17,11 @@

Introduction

Overview: this flowchart provides a summary of the policy that can help you decide which license to use.

This policy determines which license to use for source files stored in Mozilla-controlled code repositories, whether hosted at Mozilla or elsewhere - "Mozilla Repositories". Committers to Mozilla Repositories must comply with this policy, as they agreed to do in the Committer's Agreement. The following is a brief summary:

- -
@@ -43,12 +37,12 @@

Licensing of Mozilla Code

New files in, modifications to, or code designed to integrate with or build on an existing, consistently-licensed area of Mozilla Code should be under the same license as the existing code. This means that modifications to Product Code will be MPL 2.

New projects which are Mozilla Code may choose either the MPL 2.0 or the Apache License 2.0. No other license is acceptable, because Mozilla is committed to using modern open source licenses with patent grant clauses. The licensing team recommends MPL 2.0 for client-side code; please consult the team before going against this recommendation.

Trivial bits of Mozilla Code, such as testcases or snippets of code used in documentation, should be put in the public domain in order to facilitate re-use. To do that, apply the Creative Commons Public Domain Dedication by using the following boilerplate:

-
+ 

 Any copyright is dedicated to the Public Domain.
 http://creativecommons.org/publicdomain/zero/1.0/
-
+

Note that, for historical reasons, some trivial support code, such as old code samples in developer.mozilla.org, may be under the MIT license.

PD Test Code is Test Code (1) that is Mozilla Code, (2) that does not carry an explicit license header, and (3) that was either committed to a Mozilla Repository on or after 23rd September 2014, or was committed before that date but for which all contributors up to that date were Mozilla employees, contractors or interns. PD Test Code is placed in the public domain pursuant to the Creative Commons Public Domain Dedication. Test Code which has not been demonstrated to be PD Test Code should be considered to be under the MPL 2.

@@ -56,7 +50,7 @@

Licensing of Mozilla Code

Licensing of Third Party Code

When modifying or adding to Third Party Code that has already been checked into a Mozilla Repository, you should use the license pertaining to that code. The only exception is if you are adding Mozilla-specific files that have no reason to go upstream, such as build system files. In that case, you should use the MPL.

If you are planning to import new Third Party Code into a Mozilla Repository, always consult the licensing team first. They can check whether the license is compatible - even simple-looking licenses can have twists in them - and make sure our requirements are met. After such consultation, a developer checking in Third Party Code should make sure that:

-
{% endblock %} diff --git a/media/css/mozorg/mpl-1-1-annotated.scss b/media/css/mozorg/mpl-1-1-annotated.scss index 6136329cf32..19d19faafb3 100644 --- a/media/css/mozorg/mpl-1-1-annotated.scss +++ b/media/css/mozorg/mpl-1-1-annotated.scss @@ -2,8 +2,6 @@ // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. -@import '../pebbles/includes/lib'; - /* Thanks to Eric Meyer for the inspiration http://www.meyerweb.com/eric/css/edge/popups/demo.html */ diff --git a/media/css/mozorg/mpl-1-1.scss b/media/css/mozorg/mpl-1-1.scss index 589b020921a..ff55d45f85c 100644 --- a/media/css/mozorg/mpl-1-1.scss +++ b/media/css/mozorg/mpl-1-1.scss @@ -2,8 +2,6 @@ // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. -@import '../pebbles/includes/lib'; - .very-strong { text-transform: uppercase; } diff --git a/media/css/mozorg/mpl-2-0.scss b/media/css/mozorg/mpl-2-0.scss index 800b8be6848..a63e6fc83f8 100644 --- a/media/css/mozorg/mpl-2-0.scss +++ b/media/css/mozorg/mpl-2-0.scss @@ -2,8 +2,6 @@ // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. -@import '../pebbles/includes/lib'; - body { font-family: serif; -moz-hyphens: auto; diff --git a/media/css/mozorg/mpl-differences.scss b/media/css/mozorg/mpl-differences.scss index 6cb8c2919bb..991b180a13f 100644 --- a/media/css/mozorg/mpl-differences.scss +++ b/media/css/mozorg/mpl-differences.scss @@ -2,8 +2,6 @@ // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. -@import '../pebbles/includes/lib'; - /* Thanks to Eric Meyer for the inspiration http://www.meyerweb.com/eric/css/edge/popups/demo.html */ diff --git a/media/css/mozorg/mpl.less b/media/css/mozorg/mpl.less deleted file mode 100644 index be9164bd53d..00000000000 --- a/media/css/mozorg/mpl.less +++ /dev/null @@ -1,38 +0,0 @@ -// This Source Code Form is subject to the terms of the Mozilla Public -// License, v. 2.0. If a copy of the MPL was not distributed with this -// file, You can obtain one at http://mozilla.org/MPL/2.0/. - -@import "../sandstone/lib.less"; - -#main-content { - margin-top: 40px; - - h1 { - margin: 0 10px 0.5em; - } - > h2 { - padding-left: 10px; - } - h3 { - .font-size(18px); - font-weight: bold; - line-height: 1.3; - } - .version { - margin-left: 10px; - } - section { - .span(8); - } - pre { - margin-bottom: @gridGutterWidth; - } -} - -@media only screen and (max-width: @breakDesktop) { - #main-content { - section { - .span-all(); - } - } -} diff --git a/media/static-bundles.json b/media/static-bundles.json index 1ed0a4ea63e..634e3a2231a 100644 --- a/media/static-bundles.json +++ b/media/static-bundles.json @@ -140,12 +140,6 @@ ], "name": "firefox_releases_index" }, - { - "files": [ - "css/mozorg/mpl.less" - ], - "name": "mpl" - }, { "files": [ "css/base/mozilla-modal.less",