The April Roche & Associés newsletter has a discussion of the new Mozilla public license. Changes work to coordinate the MPL with the various GPLs from the Free Software Foundation, make a clearer distinction between the management of source code and distribution of executables, and overall make the license more readable–which Mozilla has succeeded in doing, unlike the Free Software Foundation that against all notions of a clear architecture has opted for spaghetti code when it comes to modifications. The GPL 3.0 may still cleverly work, but it has passed the event horizon for readability.
For universities, MPL 2.0 represents a potentially go-to license for managing software in a patent environment. MPL 2.0 handles patents as well as copyrights, with separate provisions for each. It allows separate management for executables, so long as source is available, and it provides for inclusion of software with incompatibilities with GPL class licenses.
Areas that require some vigilance include:
1) Patents. Patents are licensed to the extent that any Patent Claims “Licensable” by the Contributor are required to practice the software in the form made available by the university developers.
As with the Apache 2 license, this means that if the university claims ownership of the software, then it is the Contributor for the purposes of the license and the university’s entire patent portfolio–now and in the future–is in play with regard to anything that would cover the practice of the software. “Licenseable” means “having the right to grant…whether at the time of the initial grant or subsequently….” If the university does not claim ownership of the software (and any patent rights specific to the software), then the university’s patent portfolio is not implicated in any developer use of MPL v2.
Section 2.3 anticipates that a Contributor can withdraw code from a distribution for patent reasons, and that allows a university to address code that circulates for which the university cannot comply with the general grant of rights. But that also appears to apply only to recipients of the redacted version.
2) Warranty and support. The license allows recipients to charge for warranty, support, and liability matters, provided the licensee indemnifies the Contributors.
It doesn’t appear that the MPL v2 contemplates that the originator of a distribution will charge for support. However, nothing prevents a lab from making code available to the university under MPL v2, and the university charging for support (but not for IP) and routing that income back to the lab. This arrangement would make clear that the payment obligation was for the support service, not an IP claim. Because copyright licenses always have a service component, it is entirely appropriate to book support service fees within the royalty policy as a *cost* to be recovered, just as patent services from a law firm are within the royalty policy as a cost.
3) Regulatory matters. The MPL v2 allows a recipient to identify limitations in its terms based on regulatory or judicial requirements, provided the limitations are described in an included text file.
This is another reason to have any software that will go out under the MPL v2 conveyed to the university by means of the MPL v2 rather than by assignment of ownership. The university then can include any regulatory limitations in an included text file as part of its redistribution, allowing for full compliance with any specific requirements that may apply. This may be particularly helpful for state universities that have statutory limitations on indemnification or choice of law text.