This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
The name "Library GPL" suggests to many programmers that "the LGPL is the right thing to use for any libraries." But that's contrary to what the GNU Project says. For some libraries, it is better to use the GPL. In effect, this means that the name is working against us. Maybe it would be easier to explain that some libraries should not use the LGPL, if we used a different name instead of "Library GPL." Any suggestions for another name? Here's a draft of an article to explain why we want to find some libraries to place under the GPL. Please don't save or redistribute this version; please wait for the final version. Why you shouldn't use the Library GPL for your next library The GNU Project has two principal licenses used for libraries. One is the GNU Library GPL; the other is the ordinary GNU GPL. Most GNU libraries are covered by the Library GPL, but that needs to change. We are seeking more libraries to release *under the ordinary GPL.* The choice of license makes a big difference. When a library is released under the LGPL, it can be used in proprietary programs. When a library is released under the GPL, then its use is limited to free software. Which license is best for a given library is a matter of strategy, and which strategy is best depends on the details of the situation. When we use the ordinary GPL for a library, the purpose is it to give free software developers an advantage over proprietary developers. Proprietary software developers have the advantage of money; free software developers need to make advantages for each other. Using the GPL for a library is not always advantageous. If a free library's features are already available conveniently for proprietary software through other libraries (presumably non-free ones), then it will not give free software an advantage over proprietary software. In such as case, it is better to use the LGPL for that library. This is why we did not put the GNU C library under the GPL. After all, there are plenty of other C libraries; using the GPL for ours would have driven proprietary software developers to use another. However, when a library provides a unique capability, like GNU Readline, the situation is different. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline. If we amass a large collection of GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free so in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some company projects can be influenced in this way. Proprietary software developers will try to convince us not to contribute our libraries to the GPL-covered collection. If they succeed, their free competition will lose an advantage. For example, they may appeal to the ego, promising "more users for this package" if we let them use it in proprietary software products. Popularity is tempting to the ego, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs most. But if we resist the temptation, and stand together, we can achieve so much more. If we link our egos with the spread of free software and the freedom it brings, rather than with the success of specific programs, we can make free software more powerful, and that will boost the success of free software as nothing else could.