No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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 :
So from that standpoint, I would say, All of these tools the use the GPL code are derived works and are GPLED.
In reply to Re: Re (tilly) 1: GPL and LGPL linkage to Perl
by mdupont
|
|