FLA

[Marc Mutz]

--Boundary-02=_VYqQ+OmD0v29ymK
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Thursday 06 February 2003 16:31, Ralf Nolden wrote:
<snip>
> libraries and plugin interfaces: LGPL  (don't know how much kparts
> are affected as they are loaded on demand into the program. How does
> a kpart need to be treated in that respect that a commercial program
> can load a kpart also ?)
<snip>

I'd instead make that:

libraries in kdelibs: normally LGPL (or BSD or whatever we allow=20
currently), with GPL'd code allowed if and only if it can be wholly=20
disabled by a --disable-FEATURE ./configure switch and is not essential=20
(for a certain definition of "essential").

This is already used in libgcrypt (the cryptography code extracted from=20
GnuPG), which was re-licensed from GPL to LGPL (on request of the=20
=46SF-NA, even, AFAIK), except for the entropy gatherers, which remain=20
under GPL. The README has these words for the construct:

    License
    -------

    Most of this library is distributed under the terms of the GNU
    Lesser General Public License (LGPL); see the file COPYING.LIB for
    the actual terms.  However some parts are distributed under the
    GNU General Public License (GPL) so if you configure Libgcrypt to
    include these modules, you have to comply with the conditions of
    the GPL as found in the file COPYING.  The modules under the GPL
    are:

      rndunix - Entropy gatherer for Unices without a /dev/random
      rndw32  - Entropy gatherer for MS Windows

    The documentation is available under the terms of the GNU Free
    Documentation License; see the file COPYING.DOC for the terms.

    This library used to be available under the GPL - this was changed
    with version 1.1.7 with the rationale that there are now many free
    crypto libraries available and many of them come with capabilities
    similar to Libcrypt.  We decided that to foster the use of
    cryptography in Free Software an LGPLed library would make more
    sense because it avoids problems due to license incompatibilities
    between some Free Software licenses and the GPL.

    Please note that in many cases it is better for a library to be
    licensed under the GPL, so that it provides an advantage for free
    software projects.  The Lesser GPL is so named because it does
    less to protect the freedom of the users of the code that it
    covers.  See http://www.gnu.org/philosophy/why-not-lgpl.html for
    more explanation.

I think the same text - canonically adapted - could then be used for=20
kdelibs. I don't see why we should impair our possibilities for using=20
powerful GPL'd libraries[1] in kdelibs libs, just to cater proprietary=20
applications. If the GPL'd functionality isn't strictly essential[2] to=20
kdelibs and can be disabled at configure-time, I don't see a reason to=20
not allow it in kdelibs.

Marc

[1] My main example is gpgme, which will _never_ be re-licensed under=20
LGPL.
[2] As an example, a basic date picker would be LGPL, while additional=20
features are only available to GPL'd applications. But the main user of=20
GPL in kdelibs would be probably new libs like a what currently is in=20
libkdenetwork, all of which is under GPL.

=2D-=20
Nie wird so viel gelogen wie vor der Wahl, w=E4hrend des Kriegs und nach
der Jagd                                          -- Otto von Bismarck

--Boundary-02=_VYqQ+OmD0v29ymK
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+QqYV3oWD+L2/6DgRAnTFAKD1yg2tKgLI/i1fU2W3XptF/NS1vwCgseTs
2GQO1sX2Kh2SyKaaNdOwO10=
=lzQJ
-----END PGP SIGNATURE-----

--Boundary-02=_VYqQ+OmD0v29ymK--