This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Since this is such an important question, Unfortunately, I am not sure which question is the one that you find so important. You quoted a message which talks about a whole range of different issues. I will respond to a few of them. Joel> I dismissed kermit because I remembered that it could not be Joel> included in Linux distributions because of the licensing. Kermit is not free software; it is far too restricted. Thus, it cannot be included in any free operating system. For the definition of free software, see http://www.gnu.org/philosophy/categories.html. Joel> Someone else may be able to give a better explanation but Joel> let's take the Every discussion I have ever seen of the LGPL Joel> on-line says that if you use an LGPL'ed library in your Joel> application, then you must provide the proprietary part of Joel> your application in a form such that it can be relinked Joel> against the LGPL'ed code. Yes, this is what the LGPL requires. The LGPL was designed specifically to require this. The danger of a spurious liability lawsuit is a part of life in our society, and it makes sense to be concerned about it. It seems to me that Joel is disproprortionately worried about one scenario out of many that could lead to this result--and not a particularly likely one. Using an LGPL-covered library makes no real difference to the situation, because it is always possible for a customer to tinker with the box he bought, and break it. People usually deal with this issue with warning labels, such as, "Don't mess with this, that voids the warranty and it might even be dangerous." Joel> LGPL for example. I have assumed for so long that the GPL Joel> is inappropriate for libraries and link-in code, that I have Joel> forgotten why it is not appropriate. We use the ordinary GPL for some of our libraries. In fact, that is our default choice, for a library just as for any other program. The GNU project's goal is to encourage and facilitate the development of free software. We want to encourage people to use free software, even when they are proprietary software--but that does not mean we think that developing proprietary software is a good thing, or that we aim in general to help people do that. Using the GPL for a library means it is available only for free programs. That way, we help the development of free software but do not help the development of proprietary software. In many cases that is exactly what we want to achieve. We make an exception, and use the LGPL or the libgcc.a distribution terms, when there is a specific reason to do that. The most common reason is that a particular library is the key to using a much larger body of free software, instead of some proprietary alternative. For example, libgcc.a is a tiny part of GCC; if libgcc.a were covered by the GPL, it would be blocking proprietary developers from using GCC. We judged it was better for free software development to have more users for GCC, and thus more development of GCC. Likewise, GNU libc is a small part of the GNU system, or of the Linux-based variants of the GNU system that people usually call "Linux" (see http://www.gnu.org/gnu/linux-and-gnu.html). If GNU libc were covered by the GPL, that would make it impossible to compile a proprietary program for any these systems. We designed the LGPL for GNU libc specifically so that this would not be impossible. The existence of equivalent alternatives is also a crucial factor. There are many proprietary compilers, and many proprietary operating systems that have C libraries which, while not free software, may be linked into compiled programs. So if we did not allow using libgcc.a and GNU libc in this way, that would not hamper the development of proprietary programs; it would only give the developers a reason to pick a different compiler, or a different operating system. Clearly it is better for the progress of free software to allow use of these particular libraries in proprietary software. But that is not true for for all libraries. If a free library implements some useful special feature, often it is better (for the development of free software) to distribute it under the ordinary GPL so that it gives free software development efforts an advantage over proprietary development efforts.