'''Since tcl scripts are already always source, the GPL doesn't do anything unpleasant to tcl scripts''' 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 interchange Given 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. [SLB] The Tcl license is shorter and simpler than GPL. It has clause about government use that is obscure, the rest *seems* straightforward. Perhaps someone would like to take my claim as a challenge to find an ambiguity in the Tcl license that could cause problems? [CMcC] 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 [http://www.gnu.org/licenses/gpl-faq.html] 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. [jmn] One objection comes down to the problem of it being linked to code that is not intended for release at all or until a certain date. In a future where more and more systems are built as distributed systems, can you definitively state that 'linking' cannot be construed as occurring across machine & organisational boundaries? Even if you don't subscribe to the idea of Intellectual Property & enforcement (which I don't), you might think that keeping certain code as a 'trade secret' for a certain period of time is reasonable and thus avoid complex licenses that may seek to restrict you in this regard. My business provides services over the internet - services built up from many components, in-house & commercial & open source. What is 'linked' and what is 'distributed' is a grey area. As you said 'It's far from clear' - and that in itself is a reason to avoid licenses such as the GPL. [SLB] A second question in the FAQ relavent to this discussion is: ''What is the difference between "mere aggregation" and "combining two modules into one program"?'' A Tcl interpreter and its scripts all run in one address space, which is one characteristic of 'combination' in [GPL] speak. It also talks about whether communication between modules is 'intimate' which is highly subjective. My conclusion: if you're distributing GPL Tcl scripts for use within a proprietory product, it's hard to be sure you cannot be successfully sued. [CMcC] Of course, a tcl script doesn't run in the same address space as its interpreter. Example: In tcl, what is the address of the C main function? Its first argument, argc? That's really the point of interpreters - they implement virtual machines. [SLB] In C, however, a Tcl procedure is a data structure that does have an address. Ok, it maybe stretching a point to say they're in the same address space. However, it could be argued that way. As [jmn] said, the [GPL] has too many grey areas. [CMcC] It's not ''stretching a point'', it's simply false. C has an address space, a Tcl procedure is stored in C's address space - your swap space is addressable, your C process is stored in swap - this does not mean that your C process and swap share an address space since the two are incommensurale and neither is able to be accessed by the other. A C and a Tcl program can share data, but a Tcl script is in '''no meaningful sense''' ''linked'', or ''dynamically linked'' with the Tcl interpreter. Even sharing vars between C and Tcl isn't ''linking'', unless you'd say that linux and tclsh are linked by virtue of sharing $env. [DKF]: I suspect that one of these days the [FSF] will come badly unstuck when some court says that something they don't want happening is licit anyway (and really hard to stop) or that something they do want happening is not required, and that it is in the area of things like scripts and Java class libraries that this unsticking will happen. It is my take on things that if two pieces of code are independent of each other (i.e. neither requires the other) then no third-party code can force either of those two things to have a license change. ---- [Category Contentious Bastardry]