Re: Re (tilly) 1: GPL and LGPL linkage to Perl

[mdupont]

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.