Download presentation
Presentation is loading. Please wait.
1
MOZILLA LICENSE HISTORICAL EVOLUTION
MPL 1.0 was written by Mitchell Baker in 1998 MPL 1.1 (1999) This revision was done through an open process that considered comments from both institutional and individual contributors. The primary goals were to clarify terms regarding patents and allow for multiple licensing. This last feature was meant to encourage cooperation with developers that still preferred stricter licenses like the GPL. MPL 2.0 (2012) with the goals of greater simplicity and better compatibility with other licenses
2
MOZILLA LICENSE TERMS The MPL has been approved as both a free software license (with a weak copyleft) by the Free Software Foundation and an open-source software license by the Open Source Initiative. The MPL allows covered source code to be mixed with other files under a different, even proprietary license. However, code files licensed under the MPL must remain under the MPL and freely available in source form. This makes the MPL a compromise between the BSD licenses, which permits all derived works to be relicensed as proprietary, and the GPL, which requires the whole of a derived work, even new components, to remain under the GPL. By allowing proprietary modules in derived projects while requiring core files to remain open source, the MPL is designed to motivate both businesses and the open- source community to help develop core software. The rights granted by the Mozilla Public License are primarily defined as passing from "contributors," who create or modify source code, to the licensee. In the absence of patents, MPL-licensed code can be freely used, altered, and redistributed. Versions with patented code can still be used, transferred, and even sold, but cannot be altered without special permission. In addition, the MPL does not grant the licensee any rights to a contributor's trademarks. To fulfill the terms of the MPL, the licensee must meet certain "responsibilities," mostly concerning the distribution of licensed software. The licensee must ensure access to or provide all source code files covered by the MPL, even if the software is offered as an executable or combined with other code under a proprietary license. The one exception to covered files remaining under the MPL occurs when they are combined with code under the GPL, Lesser GPL (LGPL), or Affero GPL (AGPL). In this case, the creator of the combined software can choose to provide the entire work under the stricter GPL-based licenses.
3
COMPATIBILITY WITH OTHER LICENSE
MOZILLA LICENSE COMPATIBILITY WITH OTHER LICENSE Unlike strong copyleft licenses, code under the MPL may be combined with proprietary files in a "larger work" so long as conditions for the MPL are still met for "covered" components (Section 3.3 of the license). The MPL treats the source code file as the boundary between MPL-licensed and proprietary parts, meaning that all or none of the code in a given source file falls under the MPL. MPL version 2.0 is compatible with both the Apache License and GPL, but version 1.1 had "some complex restrictions" that made it incompatible with the GPL by default. Although the MPL 1.1 did include a provision (Section 13) for providing a work under a secondary license (including the GPL or GPL-compatible ones), MPL 1.1 and GPL code could not "legally be linked," leading the Free Software Foundation to discourage using the MPL For these reasons, earlier versions of the Mozilla Suite and Firefox were released under multiple licenses: the MPL, GPL, and LGPL.
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.