For the past three years, I have been working on a project to create a object oriented interface to the GCC compiler, the GCC Node Introspector.

This turned into a perl project after realising the power of perl for handling strings and complex data structures. Also the number of tools that link into perl are amazing.

This linking of programs can to GPL code can be very tricky, and full of problems as a detailed review of the GPL and LGPL can point out.

In this meditation, I will point out what I see as some bumpy spots for Perl and GPL, and clauses that might have been overlooked for too long.

Let us review the the GPL and its implications for linking to Perl :


<quote> This General Public License does not permit incorporating your program into proprietary programs.

If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library.

If this is what you want to do, use the GNU Library General Public License instead of this License.


GPL Comment

incorporating is a term that implies to me containment,

If I write a proprietary program that uses the output of the GPL Code is that containment?

If I open the a pipe to another program, and call functions in it using data from a GPL program, is that not what a linker does, but via a different method?

Lets look at the LGPL 2.1

<quote>We use this license for certain libraries in order to permit linking those libraries into non-free programs.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library.

The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom.

The Lesser General Public License permits more lax criteria for linking other code with the library.


LGPL Comment

Now this does not cover linking via RPC/IPC or Shared Memory or File.

Let alone CORBA or XML-RPC/SOAP.

This comes done to the definition of linking, is linking only with the linker, or is linking a method of passing data between function calls?

Can I call a GPLed Function in GIMP via a perl script webpage, but I cannot link to it?

LGPL part 2

<quote> 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. <quote>

LGPL Comment part 2

distribution conditions are incompatible with these Does that cover PAL which gives you more freedom. Can I link via perl and all of a sudden, there is no more GPL?

By these terms, every perl script which links in with GPLed GIMP via script would require such permission to be asked.

The perl script is called from an apache server, goes across all types of close-source maybe even patented software sitting on routers and switches, and then gets displayed in a microsoft browser, only to call a javascript function that uses the microsoft api to draw on some graphic card.

As you can see, the network has changed the meaning of linking.


(Updated to add a readmore, better formatting and an introduction.)

Replies are listed 'Best First'.
Re: GPL and LGPL linkage to Perl
by mirod (Canon) on Feb 28, 2002 at 09:50 UTC

    For crying out Loud!

    Once and for all, Perl is distributed under both the GPL AND the Artistic license. The goal, explicitely stated by Larry, of this double licensing is to make everybody happy: suits can use the Artistic License (which he describes as an antidote to the GPL) so they can use it in commercial software, and rabid GNU zealots see their beloved GPL being used.

    The goal (once again explicitely stated by Larry) is not to have a legally sound scheme, it is to quiet down both sides of the Open-Source vs Free Software debate, plus commercial software producers. In fact it is designed precisely to avoid that kind of GPL/LGPL nit-picking.

    See this interview for Larry's description of this hack, and a legal analysis of the Artistic License in "Essay on the Artistic License

      So you are saying that there is nothing stopping linking of the entire GNU compiler source code via Perl, and then the releasing of a closed source code generator?

      Here is a mail from joe buck from the GCC mailling list:

      "I'm afraid that's exactly what RMS is extremely worried about:

      specifically, that proposed changes make it easier for *proprietary*

      tools to use the gcc front ends or back ends."

      So GPL/PAL co-linkage allows for the turning over of the entire GPL.



        So you are saying that there is nothing stopping linking of the entire GNU compiler source code via Perl, and then the releasing of a closed source code generator?

        That's not what he's saying at all. Your example is quite obviously a derived work of GPL'd software.

        What he's saying is that most perl modules are distributed under the dual license scheme, and so this isn't an issue for the majority of cases. However, we do need to be aware that there are some perl modules on CPAN that are just GPL'd, and are not dual licensed, so you need to be aware of those.

Re (tilly) 1: GPL and LGPL linkage to Perl
by tilly (Archbishop) on Feb 28, 2002 at 18:22 UTC
    First of all none of us are lawyers, so take anything we say with appropriate amounts of salt. Furthermore note that without case law, there are huge grey areas which might resolve in any way at all.

    Since the GPL is entirely a copyright license, the legal question is at what point you have a derivative work under copyright. When you compile something with gcc, it is fairly clear. The output files don't contain copyrighted material from gcc, so it isn't a derivative work (under copyright law). When you use a templating system it is also clear. The output includes copyrighted material from the templates, so you have a derivative work. (There may be no derivation from the implementation of the templating system.) Where it is grey is when you have a program that interoperates with other code. At what point are they separate, and at what point do you have a copyrightable whole? This is unresolved, though historically people said, "If you link, it is a whole, if they merely talk through IPC, it isn't."

    Whatever the answer there, there is a parallel non-trivial complication in the case of Perl. Perl is distributed with your choice of the GPL or Artistic license. Should you link Perl with GPLed code, your copy would then have to be GPLed. You can link in LGPLed code and there is no problem. Now suppose that you write a Perl program, and you have a GPLed copy of Perl, and have linked in (and loaded) lots of GPLed stuff. Does your script need to be GPLed? I know of no definitive answer, but at least one opinion saying "No" and another saying "Yes".

    If you want more detailed discussion of this question, I would suggest looking up the free software license discussion mailing list. (They might send you to a more appropriate list still. If so, then I don't know which one.)

      I quote joe buck from the gcc mailling list :

      I wrote to him :

      Also with Perl, you can just link to perl and you have gone around the GPL.

      He said :
      In this case I think you're wrong. Perl is dual-licensed, but if you link Perl to GPL (only) code, the program as a whole can only be distributed under GPL terms.

      So does that mean that all the GPL xs routines are going to have to be reviewed?

      In the other section on the gnu faq that you pointed out it is answered very clearly :

      A concequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program In a GPL-compatible way, regardless of the license used in the Perl or Java Interpreter that the combined Perl or Java program will run on.

      Why would it allowed to link to a gzip routine, but not to the compiler itself?

      It really comes down to asking permission and getting

      it, as provided in the GPL.

      I wrote to this topic to Richard Stallman.

      Richard Stallman said to me in the question if the

      data exchange over the network is not linking and

      therefore not covered by the GPL

      "We have a different interpretation of the situation. Connecting modules through sockets or pipes does not necessarily mean they are separate programs. In simple cases they are separate, but not when they exchange complex data structures."

      That would support the idea that all these are derived

      works and fall under the GPL.

      I wrote to Linus Torvalds who said :

      Feel free to consider this email (in its

      entirety, not snipped into pieces) as being

      public, so if you think you want to post it, go


      The GPL notion of "linking" is really nothing but

      a specific technical way of trying to define

      "derived work".

      From a legal standpoint, technical issues have

      some validity, but in the end the _only_ thing

      that matters is whether it is derived or not.

      Linking is only one (strong) indicator that it is

      indeed derived. There are others. There are

      >counter-indicators as well, of course, one of

      them being "previous work" (thus my willingness,

      for example, to have binary modules that were

      basically derived from SCO device drivers that

      existed prior to Linux - one of the original

      impetuses for the module interface).

      And intent matters.


      So from that standpoint,

      I would say, All of these tools the use the GPL code are derived works and are GPLED.