(L)GPL libraries and scripting languages

[Guido Flohr]

Hi,

I Cc: this mail to address@hidden, because that's where I
got the advice to send a mail here and ask for a statement.

I have written a Perl module Locale::Messages that is a wrapper
around either Locale::gettext_pp or Locale::gettext.  Locale::gettext_pp
is a pure Perl re-implementation of the functions gettext(), dgettext(),
dcgettext(), textdomain(), and bindtextdomain() first implemented
by Sun Microsystems and later by the GNU project in the GNU gettext
package, and now by myself, in Perl.  These five functions, the 
"gettext core", are also available in the package Locale::gettext that 
is available separately on the Comprehensive Perl Authors Network 
CPAN (http://www.cpan.org/), more exactly at

        http://www.cpan.org/authors/id/P/PV/PVANDRY/gettext-1.01.tar.gz

It is written by Philip Vandry <address@hidden> and contains no
copyright statement.  It is written in C (resp. the Perl extension
language XS that is directly converted into C) and acts as a mere
wrapper around calls to gettext(), dgettext() and so on found in a
shared library installed on the system.  The installation routine for
Locale::gettext tries to resolve these symbols into a library
accessible by the linker flag "-lintl" but will of course also succeed,
if the references can be satisfied by the system libc (which should
be the case for example on a Solaris sytem).

My module makes calls to the internationalization routines transparent
and completely platform-independent: The module determines at runtime,
whether Locale::gettext (the C version, not written by me) is installed
on the system, and the Perl interpreter will then dynamically load
the shared libraries referenced by Locale::gettext.  If Locale::gettext
is not installed, or loading the shared libraries fails for some other
reason, my wrapper module will load (my) pure Perl implementation and
execute the code found there instead.

I want to publish my module with a copyright statement that reads:

        This is free software.  You can use and redistribute
        it under the terms of the Artistic License or - at your
        choice - the GNU General Public License.

Some people suspected that such a license statement would violate
the GPL.  I had to put my module under the GPL exclusively which
is not what I intent.  In fact, it is crucial for me, that my
module can be used in proprietary software (necessarily written
in Perl, too).

The above described situation is currently utterly theoretical,
but already worth a clarification?

In fact, things have changed a little bit: I need two additional
features for my library, notably on-the-fly charset conversion of
translated messages and correct handling of plural forms.  Both
features are currently only available in the GNU implementation of
gettext, not in the one shipped by Sun Microsystems.  I have
implemented the missing functions dgettext(), dngettext(), dcngettext(),
and bind_textdomain_codeset() in my Locale::gettext_pp, also in
pure Perl.  I have changed the code in the wrapper Locale::Messages
to require a ridiculously high version number of the C/XS implementation
Locale::gettext, so that effectively, the C module never gets loaded,
at least currently.

However, a skilled Perl programmer would be able to change the
sources of my module and require a non-fictional version number of 
Locale::gettext.  In that case, Perl would load the shared library
(if it is available) and use it.  As long as that skilled Perl
programmer makes do with the "core gettext" functionality, everything
will work just fine, calling the GNU extensions would result in
a runtime error (that can be caught).  My point of view: I am not
responsible for the software, if it is modified, and so I don't 
care.

Another detail: GNU gettext is available under the terms and conditions
of the Lesser General Public License LGPL, not the GNU General Public
License GPL.

Summary: My module is a complete re-implementation of gettext, it
neither depends on GNU gettext or any other runtime library, nor does
it share a single line of code with any existing implementation.
It is my own work, and IMHO I can publish and distribute it under whatever
license I want.

Even if you agree with me here, there seems to be some uncertainty
of the effect of the GPL or LGPL to bindings for (L)GPL shared libraries
in scripting languages.  As far as I am concerned, I fully agree
with the point of view of Sleepycat software, the vendors of Berkeley
DB, (see http://www.sleepycat.com/faq.html#A22):

        "Do I have to license Berkeley DB to use it in Perl or 
        Python scripts?

        No. The Berkeley DB license requires that software that 
        uses Berkeley DB be freely redistributable. In the case 
        of Perl or Python, that software is Perl or Python, and 
        not your scripts.  Any scripts you write are your property, 
        including scripts that make use of Berkeley DB. None of 
        the Perl, Python or Berkeley DB licenses place any restrictions 
        on what you may do with them." 

I think, an "official" statement, whether you share this opinion or
not, would be very helpful.

The Perl community seems to have silently agreed on the "Sleepycat
point of view".  The somewhat official source for free Perl extensions
is the CPAN (http://www.cpan.org/) and the modules available there
have a large variety of licenses.  Some are GPL, some LPGL, some have
the Perl Artistic License, some have a mixture of them, many have no
explicit license at all.  In general, CPAN authors do not seem to care about
the license of possibly referenced run-time libraries, but rather refer
to the Perl interpreter itself ("... is free software and available
under the same terms and conditions as Perl itself").  There are
dozens of XML related packages available on the CPAN, and all these
modules necessarily reference XML::Parser which provides a binding
to libexpat.  I seriously doubt that many authors have ever checked
the expat license, I even suspect that many of them are not even 
aware of the fact that their module actuates loading a shared library
at runtime.  In fact, you can never be sure.  There are quite a few
Perl extensions available that have switched from a C implementation
to pure Perl and back, or make that configurable at runtime.  One
could even argue, that it is the very purpose of scripting languages
to hide such implementation details.  Anyway, I am convinced that nobody
ever uploaded a Perl extension to the CPAN and had the intention to
violate the GPL or any other free software license. 

This is my personal opinion, I cannot speak for the Perl community.
If there is a general problem with the (L)GPL on one side and Perl 
or the CPAN on the other, this should of course rather be settled 
with the Perl maintainers or the maintainers of the CPAN.

Thanks for your patience!

Guido
-- 
Imperia AG, Development
Leyboldstr. 10 - D-50354 Hürth - http://www.imperia.de/

pgpgC519tEptD.pgp
Description: PGP signature