This document does not annotate the license in any way. It only seeks to explain the legalese with which the license itself is written. See also the annotated Mozilla Public License (MozPL) at the Mozilla website.
We have had some experiences, where the term Initial Developer was confusing for the contractor developing a product for us. Netscape Inc., which authored the MozPL, developed their product - the Navigator - in-house, and therefore there was no confusion.
But that is not the way of the European Environment Agency. We typically pay a contractor from the start to develop a product, so in some cases when we asked the contractor to fill out the MozPL template, they put their own company name as the Initial Developer.
So to avoid confusion for the contractors, (those who don't read these lines), we have changed the term Initial Developer to Initial Owner in the template. The meaning is intended to be the same.
In conclusion: If you work under a contract for the European Environment Agency then the Initial Owner is the European Environment Agency. If you contribute of your own free will, paying the cost, then the Initial Owner is you.
If you contribute work, you retain your moral rights to your contribution, which has the effect for source code that the ownership becomes diluted or shared. That is why we call ourselves Initial Owners - not just owners.
If you make modifications to an existing file you are a contributor.
It is possible for you to compile and package the source code standalone or bundled with proprietory code as part of a larger works and sell it for profit. You may want to do this to provide product warranty. But, you must tell the licensee that the source code to EEA-owned part of the work is available and that EEA nor any contributor accepts any liability for the malfunction of the code. (MozPL Section 3.6)
Any modifications you make to MozPL covered code is covered by MozPL with you in the role as contributor and you must make the modification available free of charge (MozPL 1.1, Section 2.2)
Coverage is on source file level. Meaning: If you add a source file to the codebase, that file is owned by you, and you decide what license to use. But it must be possible to compile the product without that source file. If you modify a file already in the codebase the file continues to be under MozPL, and you must make the file available as open source.
You must fill out the blanks. By original code is meant the name of the product this file is a part of. The Initial Owner is you or the organisation you develop the code for. If you are a contributer you can add your own name to the list of contributors.
After scrutinising the most popular Open Source licenses we settled on the Mozilla Public License as being best suited to our needs.
Much of the software we produce is used by our 9 topic centers and as of this writing 33 national focal points. We wanted to avoid a situation, where a vendor created a derived work, that was then sold for profit to some of the branches. It is not the money making we perceive as a problem, but the risk of incompatibility between the augmented products. With MozPL every branch can benefit from improvements.
As you see from the license, it is legal to take our source code, compile it and sell it for profit. But if you change anything in our source you must make the modification available for free for at least 12 months.
Here is an analysis written by Frank Hecker in Setting Up Shop:
Mozilla Public License
The Mozilla Public License (MozPL or MPL) and the related Netscape Public License (NPL) were created by Netscape as part of the project to release Netscape Communicator source code. Where the BSD License was created by a university and the GPL and Artistic License were created by free software developers (albeit with somewhat different philosophies), the MozPL is notable as an open-source license created by a commercial software company. As one of the newest open-source licenses the MozPL was influenced by and to some extent incorporates features from a number of older licenses, including the GPL and LGPL; however the MozPL is a distinctive license in its own right and has a number of interesting and even innovative features not found in other open-source licenses.
First, the MozPL contains a general and relatively rigorous definition of when and how derived works fall under the MozPL license provisions (or are "Covered Code," using the terminology of the license). For MozPL-ed source code considered as a set of source files, modifications of the original source files are considered to also fall under the MozPL, as are new source files incorporating extracts from the original source files. Such modified or new files are required to be licensed under the same terms as the original files, and in particular must be made freely and publicly available in source form. In this way the MozPL is similar to the GPL in mandating sharing of code modifications and seeking to prevent open-source code from being converted to proprietary code.
However unlike the GPL the MozPL explicitly permits MozPL-ed code to be combined with separate proprietary code to create a proprietary program (a "Larger Work" in MozPL terminology) which does not fall under MozPL terms; such a program may be licensed for a fee and its (proprietary) source code need not be made publicly available. As implied above, the separation between the open-source code and the proprietary code is made at the source file boundaries; a given source file is either under the MozPL or under a different license, which may be a proprietary or an open-source license. (The other license must be compatible with the MozPL in the sense that its provisions may not conflict with those of the MozPL; among other things this rules out combining MozPL-ed and GPL-ed code, since the presence of the GPL-ed code would result in the application of GPL terms to the combined code. However the LGPL allows enough flexibility so that LGPL-ed code may be combined with MozPL-ed code.)
Thus an open-source product initially released under the MozPL may be extended with proprietary code to create new proprietary products, as long as the proprietary code is separate (i.e., in separate files) and interacts with the open-source code using a defined API. (This feature of the MozPL is to some extent reminiscent of the LGPL, although the corresponding LGPL terms are more restrictive.) If the enabling code for the API is not already in the open-source product then changes to the open-source product to create the API fall under the MozPL (because they would be modifications to the original MozPL-ed source files) and must be made freely and publicly available by the developer creating the API (which in this case would be the developer creating the proprietary product). This encourages open competition among both commercial and non-commercial developers by allowing others to create alternatives (whether open-source or proprietary) to any proprietary products based on MozPL-ed code.
Document last modified: 2008/06/13 . Content in this portal is modified daily by a community of providers.