> > >>Its easy to think of modules as add ons to a program but its only in >>source version that any such distinction can be made. I suppose if the >>Perl compiler you use can compile the modules separately from the >>propriatary code then there would be no violation of the GPL, but if >>there is no such separation in the binary then I don't see why the GPL >>shouldn't apply. If there is some distinction in the binary then you >>could argue that you were simply using the modules and not modifying >>them or building something off of them. (Much like it isn't a violation >>of GPL to run propritary code on a Linux system). Maybe what we need is >>a fancy compiler like this. >> > >"Simply using" the modules is the same as linking. If the module is GPL >only, then so is your code which links to it. It doesn't matter that Perl >is a scripting language. IANAL but this comes straight from the FSF. >
If you're using the modules but not distributing anything then you don't have to worry. If you are distributing perl code, then the source is already visible so I don't think thats the issue either. Its when you distribute compiled code that you run into issues because the binary contains GPL code so the source of the entire binary must also be open source. Well what if instead of compiling everything to one binary, you put off the mixing of GPL and propritary code until run time. As a simple, and inneficient, example, suppose you have your magical perl compiler create two binarys one with GPL code and one without. When you execute one it starts the other and they communicate over pipes. Would the GPL apply in this situation? If the propritary code was compiled to some java like byte code which was then run by an executable that contains GPL code, would that mean the byte code would fall under the GPL. I'm not talking about linking. I was wondering about other options that might not infringe on the GPL. - Johnathan
