20040701 CMcC: GPL is a free software license with a requirement that you distribute source code with any Program or Work under the following (or similar) provisions:
3a) [[you must]] Accompany it with the complete corresponding machine-readable source code,
which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used
for software interchangeGiven that all scripts are immediately also 'machine-readable source code', it seems to me that distributing a pure tcl source file under GPL does nothing but prevent someone byte-compiling it, or possibly obfuscating it (which doesn't seem to me to be a bad thing.)
In particular, I don't believe that [source GPL.tcl] imposes the GPL on the code executing it, and I strongly disbelieve that it entails anything about the license of the interpreter under which the code is running.
My argument, by analogy, is that the relationship between a tcl script and the interpreter under which it runs is that of a Virtual Machine, analogous with the relationship between a C program and the O/S under which it runs. If it were necessary for the distributor of a GPL.tcl script to provide source to tclsh, it would analogously be necessary for the distributor of a GPL.c program to provide source to Windows under some circumstances. Since nobody has every alleged the latter, the former is by analogy untrue. (NB: I understand there is some problem with argument by analogy :)
(This link discusses the converse case: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL )
I therefore don't understand the prevailing aversion to GPL among tclers.
JMN 2003-07-01 Your particular 'beliefs' are one thing; but it may be the particular 'beliefs' and interpretations of some hick judge in some jurisdictional backwater who ends up doing the actual pronouncements of what *exactly* terms like linking & distribution mean. (e.g If my business splits in two.. have I 'distributed' my code base??). Actually I don't care to have such questions answered.. why suffer code under such lengthy legalese open to multiple interpretations & nuances. Keep the license simple like Tcl itself and the problems go away.
CMcC No real need to quote 'beliefs', I think. You ask why subject oneself to interpretations and nuances? Well, I guess, to be sure we're all on the same page, to enunciate and delineate shared values, because it's unavoidable, etc. I haven't given the tcl license a thorough going-over, but I'm sure a skilled lawyer would find some nuances for your hick judge to interpret, since that's what lawyers and judges do.
The point of the discussion, for me, is to state that I can't see any legitimate reason why a script author would have an aversion to GPL, since it doesn't seem to impose any additional constraints or obligations.
SLB The GPL FAQ [L1 ] answers the question of sourcing a GPL Tcl script pretty clearly in its question 'Can I use the GPL for a plug-in for a non-free program?' (short answer 'no').
CMcC It's far from clear. The question you mention begins If the program dynamically links plug-ins.... The term dynamic linking has its usual specific technical meaning, and this doesn't include sourcing a script into an interpreter.
So: [source GPL.tcl] in a script could be construed as dynamic linkage in the technical sense, but loading GPL.tcl into an interpreter isn't the same thing at all, it's like loading a program onto your (abstract) computer. Therefore GPL.tcl could gpl-'taint' a larger scripted system in which it was embedded, but not the interpreter within which it ran. The converse is also true - you can write proprietory software in (say) Python.
This matters because since tcl scripts are already always source, the GPL doesn't do anything unpleasant to tcl scripts, and so the aversion to GPL for scripts seems irrational.