Re: (L)GPL libraries and scripting languages

[Free Software Foundation]

On Tue, 2002-08-06 at 13:44, Guido Flohr wrote:
> 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!
>

Your work, distributed on its own, is probably not a derivative work of
GNU gettext.  So, you can distribute it under any license you want.  If
you (or somebody else) distribute it with gettext, then they could only
do so as a whole work under the terms of the GPL (although your portion
of the code could still have additional permissions).


-- 
-Dave Turner
Free Software Licensing Guru
This is not legal advice.  If you need legal advice, see a lawyer.