The Mozilla Foundation has started the process of revising the Mozilla Public License (“MPL”) and has published the first drafts in the process. You can read the proposed changes to definitions and licenses and comment on them. https://mpl.co-ment.com/text/KVR6Y3hsirl/view/. I am very familiar with the MPL because we used it as the base for the CDDL which I drafted with Sun’s lawyers for the open sourcing of the Solaris operating system.
The changes are a welcome simplification to the MPL definitions and license grant. In particular, the definition of “Modifications” has been changed to delete the phrase “any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications” and the definition of Modification is now based solely upon “files”. This change is very important because of the vagueness of the deleted phrase.
Mozilla has also spent significant effort in revising the terms of the patent license to use a more traditional approach, clarifying the license grant and the definition of patent claims. However, the modifications do not appear to have modified the scope of the license grants. Most of these changes represent moves of phrases from the license grant in the current MPL to the definition of “Patent Claim” in the new version. The patent licenses are now reciprocal, instead of having separate licenses for the Initial Developer and, then, for Contributors. In fact, the new definitions have deleted the definition of Initial Developer and now incorporates the concept in the definition of “Contributor”.
In addition, the new draft has deleted the requirement to provide notice of any third party patent claims in a Modification or Contributor API which is known to the Contributor (this requirement in Section 3.4 of the current version of MPL):
(a) Third Party Claims.
If Contributor has knowledge that a license under a third party’s intellectual property rights is required to exercise the rights granted by such Contributor under Sections 2.1 or 2.2, Contributor must include a text file with the Source Code distribution titled “LEGAL” which describes the claim and the party making the claim in sufficient detail that a recipient will know whom to contact. If Contributor obtains such knowledge after the Modification is made available as described in Section 3.2, Contributor shall promptly modify the LEGAL file in all copies Contributor makes available thereafter and shall take other steps (such as notifying appropriate mailing lists or newsgroups) reasonably calculated to inform those who received the Covered Code that new knowledge has been obtained.
(b) Contributor APIs.
If Contributor’s Modifications include an application programming interface and Contributor has knowledge of patent licenses which are reasonably necessary to implement that API, Contributor must also include this information in the LEGAL file.
This deletion is important because of the difficulty of complying with this obligation.
I look forward to reviewing the rest of the modifications. I am particularly interested in whether Mozilla will modify the “patent peace” provision in the current version of the MPL which has proved a problem for many large companies.
8.2. If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer or a Contributor (the Initial Developer or Contributor against whom You file such action is referred to as “Participant”) alleging that:
(a) such Participant’s Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant. If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above.
(b) any software, hardware, or device, other than such Participant’s Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant.
Section 8.2(b) has made many large companies reluctant to contribute to MPL licensed software because of its potential to limit the flexibility of a contributor in using its patent portfolio against products and software other than the MPL licensed software.
MPL has the opportunity to play an important role as the license of choice between pure copyleft (such as GPLv2) and pure permissive (such as BSD and Apache). However, it has not been able to fulfill that role because of the concerns raised by the ambiguity of its scope (the Modifications definition and notice obligations) and its expansive approach to “patent peace”. I hope that these revisions will make the MPL attractive to a broader set of users.
I congratulate the Mozilla Foundation for taking the initiative and hope that the result will be a more attactive alternative between GPL and Apache. I encourage the community to participate actively in the revision to make the new version of the MPL as valuable as possible!
Major Change in Patent Agreements: Covenant Not to Sue Same as Patent License for Patent Exhaustion
08/04/09
In a major change in the law, the Court of Appeals for the Federal Circuit (”CAFC”) held in Transcore v. ETC found that covenants not to sue have the same effect on patent exhaustion as a patent license (i.e. a sale permitted under the covenant not to sue would “exhaust” the patent) http://www.cafc.uscourts.gov/opinions/08-1430.pdf.
Consequently, a first sale that falls within the scope of a patentee’s covenant not to sue is considered “authorized” and exhausts the patent with respect to downstream customers and users. This holding is dramatically different from the assumptions of most lawyers. In fact, lawyers frequently use a convenant not to sue rather than a patent license to avoid patent exhaustion.
This issue is very important for software licensors, both commercial and open source, because they must now rethink their approach to patent licensing. For example, Red Hat used covenants not to sue in its Firestar settlement to cover certain parts of its ecosystem http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf. This decision means that lawyers need to review their existing agreements to see how this change will effect the rights of their clients. They also need to be much more careful about drafting patent agreements.
Another troubling aspect of the Transcore decision is its finding the covenant not to sue applied to a patent not yet issued at the time of the settlement on the basis of the theory of “legal estoppel.”