Creating the License

Parallel to the Great Code Cleanup was the license effort. The first step was to resolve the big question: Would any of the existing licenses work with the open code? No one wanted to have to draft new licenses, but everyone realized it might be necessary to accommodate all of the third-party code and to make the project work on a corporate level. No existing proprietary software had ever been released under a free source license.

A group of Open Source community leaders, including Linus Torvalds, Eric Raymond, and Tim O'Reilly, were invited to visit the Mountain View campus. They spoke with audiences of executives, attorneys, and programmers about what they were in for, and met with small groups to talk about some of the issues they were likely to face. They spent a great deal of time with the Netscape legal team discussing the existing licenses -- both their strengths and the problems they created. These advisors also acted as a sounding board for ideas.

One team dove into researching existing licensing agreements with the advice and guidance of the Netscape legal team, trying to determine whether one of them would work for Mozilla. Beginning with the GNU General Public License, the GNU Library General Public License (LGPL), and the BSD license, we took long looks to outline exactly what problems they solved and created. Unlike the code to which these agreements had been applied in the past, Netscape's existing code base presented unique circumstances. One of the thorniest issues was the private licensing agreements that governed many of the third-party components used in the code. The license needed to create an environment where these and other new commercial developers could contribute their code to Mozilla while protecting their business interests.

The more permissive BSD license, which only requires that the copyright holder be referenced in unlimited changes to code, was deemed insufficient for Mozilla development. It would leave developers open to the risk that modifications to their work would not be returned to them or to the rest of the community. This point alone was a big issue, since it was crucial to the long-term viability of open source development efforts.

On the other hand, the requirements of the GPL made it undesirable in this project. The GPL is ``viral''; when applied to an original piece of code, any other code with which the original is compiled must also be covered under the GPL. This aspect made it untenable for commercial software developers. For instance, the GPL would require that third-party components compiled into branded versions of Communicator also be released under the GPL, something outside of Netscape's reach, as Netscape does not control these third parties. And Netscape itself uses a portion of the Communicator code in its other products (such as servers). Since Netscape has no immediate plans to release that source code, the GPL viral effect on these products would present the same problem for Netscape as for other companies. The more open and less restrictive LGPL, a modification of the GPL, came closest to meeting Netscape's needs for use with commercial development, but it still contained too many of the same commercial pitfalls as the GPL.

After a frenzied month of research, discussion, meetings with experts and advocates from the free software community, and amidst public speculation, the team decided that a new license had to be crafted for this unique situation. The Netscape Public License (NPL) broke new ground in attempting to strike a compromise between promoting free source development by commercial enterprises and protecting free source developers. The process of fashioning a next-generation Open Source license took over a month.

In another extraordinary move, when the first draft of the Netscape Public License (NPL) was complete it was beta-tested publicly. On March 5, a draft was posted in a new newsgroup called netscape.public.mozilla.license, and a request was made for public comment. It was met with cheers and jeers. One section of the license acted as a lightening rod, catching most of the flames: the portion of the NPL that granted Netscape special rights to use code covered by the NPL in other Netscape products without those products falling under the NPL. It also allowed Netscape to issue revised versions of the NPL, and most controversially, to re-license code covered by the NPL to third parties under terms different from the NPL. Some of the people providing feedback went so far as to suggest that this fact alone would make the NPL unacceptable to the Open Source development community.

On March 11th, a status report appeared on netscape.public.mozilla.license from jwz (Jamie Zawinsky). It read, in part:

First of all, THANK YOU for the incredible amount of cogent feedback you've been giving! It has been incredibly helpful, and rest assured, the opinions expressed here are being taken very seriously.

Next week, you can expect to see a dramatically reworked section 5. I probably shouldn't comment on it too much (wouldn't want to set expectations incorrectly) but the message that most of you hate it as it stands now has been received loud and clear.

On March 21st, the revision was posted. This was unprecedented. The reaction was incredulous: ``I told them it was awful and they listened! I can't believe it!'' People realized that this was a true open-source project, in spite of its unlikely birthplace. The discussions going on in the newsgroups were helping to guide the process, rather than providing commentary on its results. The continuing discussions took on a new tone and spirits were high.

The community criticism of the beta of the NPL had sent the license team back to the drawing board. They sought a solution that would allow Netscape to balance the goals of engaging free source developers while continuing to meet business objectives. The result was the release of a second license to work with the NPL, the Mozilla Public License (MozPL). The two licenses are identical, except that the NPL includes amendments granting Netscape additional rights.

All of the code initially issued on March 31, 1998 was released under the NPL, and all modifications to that code must be released under the NPL. New code developed can be released under the MozPL or any other compatible license. Changes to files contained in the source code are considered modifications and are covered by the NPL. And to resolve much of the concern expressed on the Net: new files that do not contain any of the original code or subsequent modified code are not considered modifications and are not covered by the NPL. This resulting code can be covered by any compatible license. The GPL is not compatible with the Netscape Public License or the Mozilla Public License. The GPL is by design incompatible with all other licenses, since it prohibits the addition of any restrictions or further permissions to its boundaries. All code developed to work with GPL software must in turn be covered by the GPL. Another minor point is that the GPL insists that when you distribute code covered under its terms, it must be complete and entire. The NPL does not have this condition.

The discussions on the newsgroups had brought an important issue into sharp relief: developers needed Netscape to allow a distinction between bug fixes and new code. Clearly, it's one thing to say, ``I'm making a bug fix, a small modification to your program,'' and quite another to realize ``I'm adding a new feature to your program.'' They provoke different feelings. Most people feel all right about giving away a bug fix, and the value of making a contribution is its own reward. But new code is a different story. A developer who has done a lot of new work doesn't want to see somebody else use it to make money for themselves.

The NPL and the MozPL were designed to encourage open development on the Mozilla code base, but from the beginning there was also another goal in mind. Netscape was willing to be the first large corporation to open up its proprietary source, because it wanted to foster wider corporate interest in development in open source environments. Creating an atmosphere that made it possible for large, profit-making organizations to adopt this model and participate in the movement was paramount. The legal infrastructure in most Open Source licensing is a big hurdle to corporate cooperation. With Mozilla, the license was a project unto itself.

By giving away the source code for future versions, we hoped to engage the entire Net community in creating new innovation in the browser market. The idea that there would be talented programmers worldwide hacking on our code, infusing the browser with their creative energy, motivated everyone to keep going even when the going got tough.