Translations of this page

On the Netscape Public License

by Richard Stallman

(The original version of this article was written in March 1998 about a draft of the NPL. Our first article on the subject was Netscape is considering making the Netscape browser free software.)

The Netscape Public License, or NPL, as it was ultimately designed in 1998, is a free software license--but it has three major flaws. One flaw sends a bad philosophical message, another puts the free software community in a weak position, while the third creates a major practical problem within the free software community. Two of the flaws apply to the Mozilla Public License as well. Because of these flaws, we urge that you not use the NPL or the MPL for your free software.

1. Not all users are equal

The first problem I noticed in the NPL was that it does not give Netscape and the rest of us equal rights, as the GNU GPL does. Under the NPL, we can use Netscape's code only as specified in the NPL, but Netscape can use our changes in any way at all--even in proprietary licensed versions of the software.

The problem here is subtle, because this does not make the program non-free. It does not stop us from redistributing the program, or from changing it; it does not deny us any particular freedom. Considered from a purely pragmatic viewpoint, it may not look like a problem at all.

The problem lies in the deeper message embodied in this condition. It denies the idea of cooperation among equals that our community rests on, and says that working on a free program means contributing to a proprietary software product. Those who accept this condition are likely to be changed by it, and the change will not strengthen our community.

One proposed solution for this asymmetry is to put a time limit on it--perhaps three or five years. That would be a big improvement, because the time limit would deny the problematical deeper message.

The practical effects of this condition are minimized by another drawback of the NPL: it is not designed as a thorough copyleft. In other words, it does not try very hard to ensure that modifications made by users are available as free software.

The MPL (Mozilla Public License) does not have this problem. That is the principal difference between the MPL and the NPL.

2. Not a copyleft

The NPL has the form of a copyleft; it explicitly says that all modifications made by users must be released under the NPL. But this applies only to modifications to the existing code--not to added subroutines, if they are put in separate files. As a practical matter, this means it is easy to make proprietary changes if you want to: just put the bulk of your code into a separate file, and call the collection a Larger Work. Only the subroutine calls added to the old files will have to be released under the NPL, and they will not be very useful on their own.

The lack of real copyleft is not a catastrophe; it does not make the software non-free. For example, the X.org distribution terms do not try to use copyleft at all, yet X.org is free software nonetheless. BSD is also non-copylefted free software (although the older BSD terms have a serious drawback and should not be imitated--if you want to release non-copylefted free software, please use the X.org terms instead). NPL-covered software is also free software without being copylefted, and this by itself does not make the NPL worse than other non-copyleft free software license.

However, while this is not catastrophic, it is nonetheless a drawback. And because the NPL looks like a copyleft, some users may be confused about it, and might adopt the NPL, thinking that they are obtaining the benefits of copyleft for their software, when that is not the case. To avoid this outcome, we will need to work hard to educate people about an issue that is not easy to explain in a few words.

3. Not compatible with the GPL

The most serious practical problem in the NPL is that it is incompatible with the GNU GPL. It is impossible to combine NPL-covered code and GNU GPL-covered code together in one program, not even by linking separate object files or libraries; no matter how this is done, it has to violate one license or the other.

This conflict occurs because the GPL is serious about copyleft: it was designed to ensure that all changes and extensions to a free program must be free. So it does not leave a loophole for making changes proprietary by putting them into a separate file. To close this loophole, the GPL does not allow linking the copylefted program with code that has other restrictions or conditions--such as the NPL.

Being incompatible with the GPL does not make a program non-free; it does not raise a fundamental ethical issue. But it is likely to create a serious problem for the free software community, dividing the code base into two collections that cannot be mixed. As a practical matter, this problem is very important.

Solving this by changing the GPL is possible, but that would entail abandoning copyleft--which would do more harm than good. But it is possible to solve this problem with a small change in the NPL. (See below for a specific way of doing this.)

4. A note about names

NPL stands for Netscape Public License, but GPL does not stand for GNU Public License. The full name of our license is the GNU General Public License, abbreviated GNU GPL. Sometimes people leave out the word ``GNU'' and write just GPL.

(This is not a problem, just a fact that you should know.)

Conclusion

Since problem 3 is the most serious, I hope that people will politely and rationally explain to Netscape the importance of solving it. Solutions are available; they just have to decide to use them.

Here is a possible way to permit linking NPL-covered code and GPL-covered code together. It can be done by adding these two paragraphs to the NPL:

A.1. You may distribute a Covered Work under the terms of the GNU
     General Public License, version 2 or newer, as published by the
     Free Software Foundation, when it is included in a Larger Work
     which is as a whole distributed under the terms of the same
     version of the GNU General Public License.

A.2. If you have received a copy of a Larger Work under the terms of a
     version or a choice of versions of the GNU General Public
     License, and you make modifications to some NPL-covered portions
     of this Larger Work, you have the option of altering these
     portions to say that their distribution terms are that version or
     that choice of versions of GNU General Public License.

This allows people to combine NPL-covered code with GPL-covered code, and to distribute the combined work under the terms of the GNU GPL.

It permits people to release modifications to such combined works under the terms of the GNU GPL--but the easiest way to release them is under the NPL.

When people take advantage of A.2, their changes will be released only under the terms of the GNU GPL; so these changes would not be available for Netscape to use in proprietary versions. It makes sense that Netscape would see this as unfortunate.

However, the NPL gives proprietary software developers an easy way to make their changes entirely unavailable to Netscape--by putting their code into separate files and calling the combination a Larger Work. In fact, this is easier, for them, than A.2 is for GPL users.

If Netscape feels it can live with the trouble of (effectively) proprietary modifications, surely the trouble of GPL-covered modifications is a small by comparison. If Netscape believes that practical considerations will encourage most of the proprietary software world to release its changes back to Netscape, without being compelled to, the same reasons ought to apply in the free software world as well. Netscape should recognize that this change is acceptable, and adopt it, to avoid confronting free software developers with a serious dilemma.

Other Texts to Read