I knew when I mentioned something negative about the GNU Project's General Public License (GPL), in my column last week, I would inevitably be accused of arguing the GPL was a bad license. I knew this would happen despite my qualification to the argument that I had released code under the GPL myself. What did not fit into that piece shall now be dealt with: is the GPL a bad license?
The simple answer, for those interested in that, is no, it is not a bad license. The longer answer, however, is worth perusing, because a license inevitably has an impact on both the developer and the end-user. This is especially true with a license, such as the GPL, which encourages derivative works and sets requirements upon the release of those works.
I am convinced no one can argue successfully against what the GPL has accomplished. While Linux would surely have come into existence without the GPL, it was the license's requirement to essentially “play fair” that insured innovation would not be bled off into an unmanageable array of incompatible kernels with incompatible licenses. The famous example is to point to UNIX segmentation in the 1980's, which has, despite naysayers' predictions, never repeated itself within the GNU/Linux community. While BSD licensed code could be, and still can be, integrated into proprietary code bases, this cannot happen with GPL-licensed code. Hence, if Red Hat runs off in a strange direction tomorrow, it would have to work much harder at severing compatibility than its UNIX forerunners did (and before anyone asks, no, I do not have information suggesting Red Hat plans any such thing).
Many, arguing what I see as a hypocritical argument, suggest that the GPL is somehow “evil” for insisting that they must put their extensions to a GPL-licensed code base under the GPL (or a less restrictive license such as the LGPL or BSD license). While there is good reason for proprietary developers to loathe the GPL when they can freely raid anything good released under a BSD or MIT license, the argument that therefore code ought to be released under one of those licenses rings hollow. If you do not plan to make your code freely available at all, why should you expect other developers to bend over backwards and not only give their code to you, but also let you not return the favor?
I have yet to hear a decent answer to that question, and I expect I shall be waiting a lot longer to hear it. Usually, my anti-GPL friends will, at this point, perform the odd ideological contortions necessary to speak of the need for as much software freedom as possible, in a most Stallman-esque manner, while doing so for the end goal of being able to write proprietary software with that most entirely liberated code.
Much of the code written under Open Source licenses would surely be best released under the GPL for the very reason these people scorn it: the software cannot be placed under a proprietary license, something that does little to benefit the original developer, to whom future developers are indebted, or anyone else.
Given that statement, why on earth would I say that KDE is worse off for being tied to a GPL-licensed library? This is not a contradiction. While it seems sensible, and desirable, for applications to be placed under the GPL, since any code written on top of them is simply extending or continuing development of the original applications, libraries are different. Libraries have often caused much confusion: exactly how closely tied does my code need to be to your code before I must place my code under a compatible license? If I write a program using Qt as my base library, I may never see a line of Qt code, so, in some sense, I may feel that my code base is entirely isolated from Qt. In reality it is not, but the point is that using libraries when writing a new program is markedly different from simply modifying an existing code base.
The Free Software Foundation recognized the need for a separate library license and so it offered one, which it named the LGPL or Library General Public License (more recently renamed the Lesser GPL). In that license's preamble, the rationale for this license is made explicit:
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.
Both of these reasons are relevant, for the most part, exclusively to libraries. If you want an application or other code, such as the Linux kernel, to become a de facto standard, there is no need to release it under the LGPL: end users will not care about whether they can link non-Free software to their word processor. Likewise, the existence of non-Free word processors does not necessitate that your word processor ought to be under something less than the GPL; after all, the primary goal would be to insure that improvements can make it back into the code base and therefore give the application a better shot at competing with non-Free alternatives. The GPL insures that this is the case.
The difference with libraries is the fact that libraries are products that are marketed, so to speak, to developers, not end users. I do not care if my application is written against Qt, GTK+, MFC, Cocoa, Carbon or something else: all I care is that the program works well with my other programs and follows the interface standards I expect in my operating environment. On the other hand, a developer must be concerned with such things, and also with how licenses impact his or her own licensing abilities.
This, however, means in the end, the end user will care about libraries, even if he is completely unaware of what a library is. If most proprietary software, including the Yahoo! Messenger that he wants to use, uses GTK+ and integrates in look and feel much better with other GTK+ applications, the end user is going to care.
It is in the interest of an organization, volunteer or commercial, that wants to attract a large user base to its user interface to make its core libraries as unrestricted as possible, so long, as the LGPL preamble says, the free library “does the same job as a widely used non-free” library. Libraries like Qt and GTK+ may have a vast array of goals, but for the purpose of the GNU/Linux desktop, only one interests us: providing the foundation necessary to build applications parallel in functionality to those on other platforms. Therefore, it goes without saying that non-Free alternatives exist in the form of Windows and Mac OS X libraries. Qt may be better, but clearly it is not better by a long enough shot to convince Mozilla, Yahoo, Adobe, AOL, Macromedia, EMC/VMware and others to face the choice of either buying a commercial license or ceding the right to develop proprietary versions of their product. (And yes, with its proprietary feedback agent compiled in, not even Mozilla could get away without a commercial Qt license).
This is not a moral problem, it is a practical problem. Trolltech has no reason to be desirous to release Qt under the LGPL or BSD license, nor should they. That is not the point of this commentary, or the last. The point is simple: the GPL at the library level is not desirable for many developers — even those developing FOSS code — since many prefer to leave their options open as to how they will license the code in the future. Even if you never plan to release code under a non-Free license, why restrict yourself if you do not have to? As I said last week, the KDE/Qt combination is the only major platform to which a developer must go to a specific company and buy the right to develop GPL incompatible software.
With Windows, Mac OS X, and GNOME offering complete user environments that do not require the developer to even think about this, much less pay anything additional for the option to develop non-Free code, there are alternatives. This is the heart of the matter that I wrote about last week. Some will dismiss it and some may not care if their environment ever has much non-Free software, but that does not erase this issue. If GTK+ is the library best able to boast of an end-to-end application suite, from the largest FOSS projects to the smallest proprietary software package, the environments that integrate with those applications best, GNOME and, to a lesser extent, XFce, will have the most to gain.
If administrators view two platforms with the same logic I have explained above, and one appears to be more likely to foster developers of every type (and, arguably, already has), which one do you think they are going to pick?
The GPL is not a bad license; in my opinion, it is a very good license. Yet, I will go on the record asserting that it is not the best choice for basic libraries for a desktop environment; it is too restrictive on what licenses the code that every application written for that environment will have to use for it to be an ideal choice. While KDE advocates can point to all of the successes the environment has had, I would argue that these are in spite of the licensing of Qt, and that it would be much better to fix the situation so that the licensing of the basic libraries actually helps the environment's future development.
Next week, after casting some doubt on KDE the past two weeks, I'll explain why I am not the GNOME user I have been presumed to be.