Freek Dijkstra wrote: > On 13-08-2004 0:09, "Josh Triplett" <[EMAIL PROTECTED]> wrote: >>I think the issue of non-GPL-compatible licenses is certainly annoying, >>but I don't really see any way around it without losing the copyleft. > > I see a theoretical and a practical way. > > First of all the theoretical way: > > I would have preferred that the GPL would be less strict in allowing dynamic > linking of GPL software with non-GPL compatible, but still free software. > Given the list at http://www.gnu.org/licenses/license-list.html, the FSF is > perfectly capable of making the distinction between "free" and "non-free" > (where BSD, Apache, OpenSSL, etc. licences are still considered "free"; thus > basically all licences which force that the source is kept open).
No, only copyleft licenses require the source to be kept open; the BSD and Apache licenses are not copyleft licenses. I assume you are referring to the fact that the FSF distinguishes between "GPL-compatible", "GPL-incompatible but still Free Software", and "Proprietary", rather than using "GPL-compatible" as their definition for Free Software? I believe the reasoning behind this is that licenses must be exact and precise, while their definition for Free Software, at http://www.gnu.org/philosophy/free-sw.html, is far less precise (and has changed in various ways over time). > I'm 100% convinced they can put that into a solid licence. However, they > explicitly decided not to, in order to push their idea of open software. First of all, the FSF does not push any idea of "open software", and many members of the FSF will probably be quite vocal about that. :) See http://www.gnu.org/philosophy/free-software-for-freedom.html . Second, as I said above, I don't believe it is as easy as you claim to codify the rules for all Free Software with the precision required for a license. > See http://www.gnu.org/licenses/gpl-faq.html#WhySomeGPLAndNotLGPL That FAQ item simply points out the advantages of copyleft: prohibiting combination with proprietary software. GPLed software cannot be combined with either proprietary software or GPL-incompatible Free Software; LGPLed software can be combined with both. You seem to be suggesting that a license should exist that allows combination with all Free Software, GPL-compatible or not, and only prohibits combination with proprietary software. That is a reasonable goal, but it requires a legally-precise definition for "all Free Software" (or a canonical list of Free licenses somewhere, which for practial reasons cannot be adjusted later). > What annoys me propably most is that this simple licence is non-GPL > compatible, and any software written with this licence is not allowed to be > linked against GPL-software: > This code may be freely modified, copied and distributed, so > long as no fee is charged for it. > (question 3, http://www.gnu.org/cgi-bin/license-quiz.cgi) That license is not only non-GPL-compatible, it is entirely non-free (by the DFSG, the OSD, and the FSF's criteria), so the GPL is doing its job there. > Secondly, a practical way may be: > > As you surely are aware, it is possible to include an exception to the GPL, > stating you, as the copyright holder allow that your program links against > (specific) non-GPL-compatible libraries. Yes. You can grant any exception you like; it doesn't have to be for a specific library. You could even grant a blanket exception for certain licenses, such as the MySQL FLOSS exception, or a blanket exception for all non-GPL-compatible programs, as GNU Classpath did. By doing that, you are weakening the copyleft, and broadening the number of programs you can link to. Whether that is something you want to do is up to you; there are some cases where weaker copylefts or no copylefts were the right decision. > Now, if I read the answer to this FAQ: > http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat > The FSF states here: > If you wrote and released the program under the GPL, and you > designed it specifically to work with those facilities, people > can take that as an implicit exception permitting them to link > it with those facilities. But if that is what you intend, it > is better to say so explicitly. > "those facilities" refer to a interpreter who automatically "binds to" > non-GPL-compatible software, like libraries. > > Well, I do not see a technical difference from, for example the people who > designed netatalk to specifically work with the OpenSSL "facility", and a > linker who dynamically links with (binds to) the OpenSSL library. > > So by explictly designing GPL code to link against non-GPL code, the author > *implicitly* gives the exception that the program may indeed be linked to > this particular non-GPL code. The "implicit exception" has indeed been argued in the past. However, as that FAQ entry points out, it is better to make an explicit exception; otherwise, people who copy, modify, and distribute your software may be unable to know whether they are in violation of the license or not. Furthermore, how does that handle the case when the authors were not the ones to add the OpenSSL linkage (or not all of the authors were)? You are suggesting that the ability to link with GPL-incompatible code would only be usable by the authors (which is already the case). Regardless, since you need the agreement of all authors in order to ignore the GPL in that way, you might as well make an explicit exception at that point; therefore, this "implicit exception" argument is only useful in the case where the authors did not know (or for some reason did not want) to make an explicit exception at the time (such as the Netatalk case). - Josh Triplett
signature.asc
Description: OpenPGP digital signature
