Shadow of communism
Translation of the article “Why you shouldn’t use the Lesser GPL for your next library” with comments by Oleg Andreyev, Academician of the Russian Academy of Software Development.
www.gnu.org/licenses/why-not-lgpl.html
Why you should not use Lesser GPL for your next library.
The GNU project has two major licenses for libraries. The first is the Lesser GPL, the second is the usual GPL. Between them there is a significant difference: the LGPL allows you to use the library in closed programs, and the GPL - only in free.
')
The choice of license is determined by strategy and depends on the situation. Currently, most GNU libraries are covered by the LGPL, which means that we use one strategy, rejecting another. Therefore, we encourage the release of more libraries under the GPL license.
Developers of closed software have a cash advantage; free software developers should create an advantage to each other. Using the usual GPL for the library gives an advantage over the closed software: free programs can use such a library, but non-free ones cannot.
Using the GPL is not beneficial for every library. The most common situation is when the functions of a free library are already available for closed-source software through alternative implementations. In this case, the library does not give any particular advantage for free software and therefore it is better to use the LGPL.
That is why we use the LGPL for glibc. There are many alternative C-libraries in the world. If we use the GPL for our implementation, then developers of closed software will have no problems with using alternatives. But difficulties may arise with us.
However, when a library has interesting unique capabilities (like the GNU Readline, for example), that’s another story. The Readline library implements input processing and storage of history for interactive programs; its capabilities are not fully accessible in other similar implementations. The release of such a library under the GPL license and restricting its use among free software gives our community a tangible effect. Now at least one application is free because it was necessary to use Readline.
If we put together an array of powerful, unparalleled GPL libraries, they will act as building blocks for new free programs. This will greatly benefit the further development of free software and other projects will decide to make their software free in order to use our libraries. It is easiest to influence university libraries, but today many commercial organizations are beginning to look towards free software, and they can be influenced in this way.
Developers of proprietary software in an attempt to downplay the importance of free competition will try to dissuade the authors from contributing to the GPL-code collection. For example, they can appeal to ambition, promising "a greater number of library users" in the case of permission to use the code in a closed software. The promise of popularity is tempting, and it is easy for the library developer to conclude that increasing the popularity of a library is something that the community needs in the first place.
But we must not give in to these temptations, comrades. Because we will achieve much more if we stand together. We, the free software developers, should help each other. By releasing libraries that are only available for free software, we help each other’s programs be better than closed alternatives. The whole free software movement will grow further, because free software is generally more competitive.
_____________________________________________________
Stolman writes that with time free software will be more and more, and in the absence of alternatives, an increasing number of commercial codes will be free and, ultimately, communism will come to the software world (if the UAC does not come earlier). I have an alternative point of view: as the number of GPL-software grows, more and more attention will be paid to the limitations of the GPL and the advantages of much more free licenses such as LGPL, BSD, MIT, Apache2, etc. More developers will face real difficulties using the GPL code and more and more code will be released truly free. Free from Stolman's claims, developer communities, corporations, and anyone else. Sooner or later, a truly free implementation of Readline and other libraries will appear, just as there are many implementations of libc. As a result, the GPL-code will be limited to itself and, like any closed ecosystem, will degenerate due to the inability to develop.
Note. GPL-code does not degenerate because “communism is bad,” but because human nature is such that, first of all, it seeks to minimize its personal risks. Commercial developers who, for whatever reason, need to open the code, have reason to release it under the GPL only to prevent competitors from hiding their designs and, thus, not giving them an advantage. But those who want to make a popular high-quality and free implementation, there is no reason to spoil the life of their own commercial development and their colleagues. Liberal relations generate mutual respect, and a greater number of users of the code, even from the side of closed software, lead to a greater volume of feedback and an increase in the quality of the product. But communism is bad or good, the author does not know, because no one else has built it anywhere.
www.gnu.org/licenses/why-not-lgpl.html
Why you should not use Lesser GPL for your next library.
The GNU project has two major licenses for libraries. The first is the Lesser GPL, the second is the usual GPL. Between them there is a significant difference: the LGPL allows you to use the library in closed programs, and the GPL - only in free.
')
The choice of license is determined by strategy and depends on the situation. Currently, most GNU libraries are covered by the LGPL, which means that we use one strategy, rejecting another. Therefore, we encourage the release of more libraries under the GPL license.
Developers of closed software have a cash advantage; free software developers should create an advantage to each other. Using the usual GPL for the library gives an advantage over the closed software: free programs can use such a library, but non-free ones cannot.
Using the GPL is not beneficial for every library. The most common situation is when the functions of a free library are already available for closed-source software through alternative implementations. In this case, the library does not give any particular advantage for free software and therefore it is better to use the LGPL.
That is why we use the LGPL for glibc. There are many alternative C-libraries in the world. If we use the GPL for our implementation, then developers of closed software will have no problems with using alternatives. But difficulties may arise with us.
However, when a library has interesting unique capabilities (like the GNU Readline, for example), that’s another story. The Readline library implements input processing and storage of history for interactive programs; its capabilities are not fully accessible in other similar implementations. The release of such a library under the GPL license and restricting its use among free software gives our community a tangible effect. Now at least one application is free because it was necessary to use Readline.
If we put together an array of powerful, unparalleled GPL libraries, they will act as building blocks for new free programs. This will greatly benefit the further development of free software and other projects will decide to make their software free in order to use our libraries. It is easiest to influence university libraries, but today many commercial organizations are beginning to look towards free software, and they can be influenced in this way.
Developers of proprietary software in an attempt to downplay the importance of free competition will try to dissuade the authors from contributing to the GPL-code collection. For example, they can appeal to ambition, promising "a greater number of library users" in the case of permission to use the code in a closed software. The promise of popularity is tempting, and it is easy for the library developer to conclude that increasing the popularity of a library is something that the community needs in the first place.
But we must not give in to these temptations, comrades. Because we will achieve much more if we stand together. We, the free software developers, should help each other. By releasing libraries that are only available for free software, we help each other’s programs be better than closed alternatives. The whole free software movement will grow further, because free software is generally more competitive.
_____________________________________________________
Stolman writes that with time free software will be more and more, and in the absence of alternatives, an increasing number of commercial codes will be free and, ultimately, communism will come to the software world (if the UAC does not come earlier). I have an alternative point of view: as the number of GPL-software grows, more and more attention will be paid to the limitations of the GPL and the advantages of much more free licenses such as LGPL, BSD, MIT, Apache2, etc. More developers will face real difficulties using the GPL code and more and more code will be released truly free. Free from Stolman's claims, developer communities, corporations, and anyone else. Sooner or later, a truly free implementation of Readline and other libraries will appear, just as there are many implementations of libc. As a result, the GPL-code will be limited to itself and, like any closed ecosystem, will degenerate due to the inability to develop.
Note. GPL-code does not degenerate because “communism is bad,” but because human nature is such that, first of all, it seeks to minimize its personal risks. Commercial developers who, for whatever reason, need to open the code, have reason to release it under the GPL only to prevent competitors from hiding their designs and, thus, not giving them an advantage. But those who want to make a popular high-quality and free implementation, there is no reason to spoil the life of their own commercial development and their colleagues. Liberal relations generate mutual respect, and a greater number of users of the code, even from the side of closed software, lead to a greater volume of feedback and an increase in the quality of the product. But communism is bad or good, the author does not know, because no one else has built it anywhere.
Source: https://habr.com/ru/post/29106/
All Articles