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:

http://gcc.gnu.org/ml/gcc/1999-01n/msg00706.html

"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.

Mike

updated:formatting

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.

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 :

http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html

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

ahead.

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.

Linus

So from that standpoint,

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