Re: license for eSvn
Scripsit Pierre Chifflier <[EMAIL PROTECTED]> > On Mon, Sep 06, 2004 at 08:05:24PM +0100, Henning Makholm wrote: > > > and that this kind of license is already used by other debian > > > packages > > Which packages? If that is true, bugs should be filed and packages > > moved to non-free, preferrably before sarge releases if at all > > possible. > lincvs. Which has been accepted a long time ago into main. Hm, the copyyright file for lincvs appears to be wrong. It says: | This program is free software; you can redistribute it and/or modify | it under the terms of the GNU General Public License as published by | the Free Software Foundation; either version 2, or (at your option) | any later version. with no platform restrictions. However, the file LICENCE in the source tarball contains: | LinCVS is available under two different licenses: | | If LinCVS is linked against the GPLed version of Qt | LinCVS is released under the terms of GPL also. | | If LinCVS is linked against a nonGPLed version of Qt | LinCVS is released under the terms of the | LinCVS License for non-Unix platforms (LLNU) and the same notice appears in the actual C++ source file I sampled. This is non-free because it only gives a license for as long as one links with Qt; if I rewrite the code to work with another toolkit (even a public-domain one) I find myself with no license for the code at all. The freedom of the GPL does not survive that kind of crippling; so the software has no free license. The lincvs author should be contacted for a license clarification, or, alternatively, the package should be moved to non-free. What both authors probably *intend* is to offer a dual license which lets the user choose arbitrarily between the GPL and another license. That would automatically imply that the usual *internal* restrictions prevent the user from linking with a GPL-incompatible library if he chooses the GPL, and from linking with GPL code if he choses the other license. The author can of course point this out as guidance for the user - but he cannot, without losing DFSG-freedom, deny the user the right to choose the free license even in situations where the author expects the free license to be useless. -- Henning Makholm "Punctuation, is? fun!"
Re: updated: Re: license for eSvn
Scripsit Pierre Chifflier <[EMAIL PROTECTED]> > So the final license is: > GPL, with an explicit exception allowing linking with any version of > Qt without having to redistribute sources of Qt. (that is the license > of psi package) That seems fine. For DFSG purposes we don't need the explicit exception, but it doesn't hurt either, of course. -- Henning Makholm "Det er du nok fandens ene om at mene. For det ligger i Australien!"
Bug#270461: lincvs: No free license & misleading copyright file
Package: lincvs Version: 1.3.2-3 Severity: serious The copyright file for lincvs claims: | Copyright: (c) 1999-2003 by above named authors. | | This program is free software; you can redistribute it and/or modify | it under the terms of the GNU General Public License as published by | the Free Software Foundation; either version 2, or (at your option) | any later version. However, the copyright notice in the upstream source's LICENSE file reads | LinCVS is available under two different licenses: | | If LinCVS is linked against the GPLed version of Qt | LinCVS is released under the terms of GPL also. | | If LinCVS is linked against a nonGPLed version of Qt | LinCVS is released under the terms of the | LinCVS License for non-Unix platforms (LLNU) This language is also found in most of the actual source files, except for the files src/AnnotateGrepLinesDialog.ui src/ccvscommand.h src/ccvscommand.cpp src/MergeDialog.ui src/AnnotateGrepLineDialog.ui src/cmainwindow.ui which contain ordinary GPL notices. The notice in the LICENSE file specifies a non-free license. GPL is usually free, but when, as here, it is applied only under the condition that one links with (a certain version of Qt) it is not free. The restriction means that I cannot take the lincvs code nd modify it such that it does not use Qt anymore - I would find myself without any applicable license at all. Furthermore, such a restricted GPL grant is incompatible with the raw GPL-ness of src/AnnotateGrepLinesDialog.ui et al. What the upstream author probably *meant* is something along the lines of This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 or (at your option) any later version; or (at your option) under the terms of the LinCVS License for non-Unix platforms (LLNU) which is reproduced below. The two license options give you slightly different rights under slightly different conditions; you can choose the one that suits your purpose best. If you redistribute a modified version of LinCVS, you have the option of using either of the license options, or to preserve the dual licensing. Beware that if you choose to redistribute under only one of the license options, your recipients will not be able to link with either the free or the commercial editions of Qt. This would be DFSG free, but what the authors actually *did* is not. To solve this problem, the Debian maintainer should contact the upstream authors and ask them whether they would agree to an ordinary dual licensing scheme like the one sketched above. If they do, this bug report can be closed once evidence of their agreement reaches the copyright file. If an agreement with the authors cannot be reached, the package will have to move to non-free. -- Henning Makholm "Underlige Ugle vågner midt om natten."
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote: > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > > > and of course that any document > > written in Microsoft Word is derived from Word. > > I can use a word document without a copy of word, these days. There > are at least half a dozen other things that can work with them. Perhaps I am misunderstanding, but by this argument, wouldn't the fact that "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl with no SSL at all" qualify it as mere aggregation - if the dividing point is that multiple implementations, at least some of which are Free, can be used with it? Shades of libreadline -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Tue, Sep 07, 2004 at 05:34:29PM +, Joel Baker wrote: > On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote: > > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > > > > > and of course that any document > > > written in Microsoft Word is derived from Word. > > > > I can use a word document without a copy of word, these days. There > > are at least half a dozen other things that can work with them. > > Perhaps I am misunderstanding, but by this argument, wouldn't the fact that > "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl > with no SSL at all" qualify it as mere aggregation - if the dividing point > is that multiple implementations, at least some of which are Free, can be > used with it? Maybe. You have implicitly introduced the notion that these three variations on libcurl are distinct, and I'm just not sure about that. This transitive option stuff is murky. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Bug#270461: lincvs: No free license & misleading copyright file
On Tue, Sep 07, 2004 at 03:04:09PM +0100, Henning Makholm wrote: > The notice in the LICENSE file specifies a non-free license. GPL is > usually free, but when, as here, it is applied only under the > condition that one links with (a certain version of Qt) it is not > free. The restriction means that I cannot take the lincvs code nd I think this is the wrong way of putting it. This is not a case of a "non-free application of the GPL". This software is not under the GPL at all; it's under a different, non-free, GPL-incompatible license that's easily confused with the GPL. > Furthermore, such a restricted GPL grant is incompatible with the raw > GPL-ness of src/AnnotateGrepLinesDialog.ui et al. Also, dual-licensing the rest would be relatively useless without dual- licensing these files, too, unless these files are easily removed. -- Glenn Maynard
Re: GPL-licensed packages with depend-chain to OpenSSL
On Tue, Sep 07, 2004 at 07:57:06PM +0100, Andrew Suffield wrote: > On Tue, Sep 07, 2004 at 05:34:29PM +, Joel Baker wrote: > > On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote: > > > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote: > > > > > > > and of course that any document > > > > written in Microsoft Word is derived from Word. > > > > > > I can use a word document without a copy of word, these days. There > > > are at least half a dozen other things that can work with them. > > > > Perhaps I am misunderstanding, but by this argument, wouldn't the fact that > > "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl > > with no SSL at all" qualify it as mere aggregation - if the dividing point > > is that multiple implementations, at least some of which are Free, can be > > used with it? > > Maybe. You have implicitly introduced the notion that these three > variations on libcurl are distinct, and I'm just not sure about > that. This transitive option stuff is murky. Perhaps; IMO, a transitive API (that is, an API which provides a thin veneer over other APIs, such as Curl's SSL API) falls under one of two cases: 1) It is, itself, an API barrier beyond which the program cannot "see", and which means the license of the transitive API governs whether it can be used with GPL code. or 2) It "passes through" to the API which *it* calls, and the licensing of any / all implementations of that API distributed come into play. There are some "smell of the wind" tests one could propose to decide between case 1 and case 2, the foremost I can think of having to do with how similar the APIs are (that is, how "thick" the veneer is - panelling, or a two foot wall?), but for the specific instance at hand, it isn't actually necessary to decide, AFAICT. Specifically: In case 1, Curl's license governs, and as far as I understand, this isn't a problem at all (or the issue wouldn't be so murky). In case 2, we degenerate into a situation identical to the readline library situation - multiple implementations of the API exist which can fufill the API requirements for dynamic linking. A quick review of the topic from past d-l posts, courtesy of Google, makes my head hurt a lot more than it did before I began, but the best summary I can find is that "derived work" status may be invalidated if programming to a (non-copyrightable) API, rather than to a specific implementation (modulo Debian packaging choices such as whether it Depends, Recommends, or Suggests packages with various licenses). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- signature.asc Description: Digital signature
