This page is a discussion for and against releasing Tcl scripts under the GPL licence, primarily as opposed to releasing them under a BSD-style licence such as that of the Tcl core. A short summary of the issue is:
The whole issue has rather strong cultural aspects, so it is unlikely that anyone will ever come up with a technical, juridical, or philosophical argument that universally settles the question of whether GPLing is the right thing or not.
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:
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.
WJP I wouldn't worry too much about the interpretation of the GPL in some backwater, for two reasons. One is that copyright law is federal law (in North America at any rate) and even in relative backwaters federal judges are pretty sophisticated. Furthermore, a goofy decision on the law can be expected to be overturned at the appellate level.
The other reason is that the GPL, unlike many other software licenses, was written by very good lawyers specializing in intellectual property law and has been discussed and debated by a lot of people. We probably have a better idea of what it means, how the courts will interpret it, and where it is unclear, than for any other license.
GWL The license that Tcl/Tk/TclLib/TkLib uses is a modified BSD license. It too (in fact before GPL) was written by very good lawyers specializing in intellectual property law and has been discussed and debated by a lot of people. It has also been reviewed by many corporate lawyers and found both binding and non-invasive. The list of corporations (some of which have merged into other companies) whose lawyers have reviewed (to my personal knowledge) includes but is not limited too:
Additionally the lawyers for several US Government agencies have reviewed the license (to my personal knowledge):
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.
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.
NEM: This page is confusing me (as most things GPL-related seem to). The premise of the page seems to be that the GPL doesn't apply any particular constraints on distribution of scripts. Well, neither does the Tcl/BSD license. So perhaps, someone could answer the reverse question: if this is true, what advantage does the GPL have over a BSD license for scripts? Does the GPL impose any additional constraints on scripts?
As a separate point, what does "machine-readable" mean? Is that correct? Binary machine code is "machine-readable". Should that be "human-readable"?
SLB The key phrase is 'machine-readable source code'. If you get the source code as a paper listing, you won't be able to compile it.
SLB The purpose of the GPL as distinct from the LGPL is described here:
By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. [L2 ].
Leaving aside the questions of exactly what the limits are for proprietary software using GPL software and whether such restrictions are legally enforceable, there is an idealogical issue here.
jmn It often seems GPL adherents see their's as the 'one true ideology'. Anyone anti-GPL is presumed to be thoroughly pro-Commercial and pro-IP but actually it may mean:
a) Disagreement with the GPL's 'fight fire with fire' approach of using the legal system; - where lawyers are involved, anyone & everyone could get burned. (Though admittedly there's a certain wicked appeal to the inventiveness and intent of the license)
b) That the anti-GPList believes there are better ways to encourage community code-sharing & reuse (PD, BSD/MIT licenses) - and that free software doesn't need legal thorns in order to compete. I'd rather pay a voluntary contribution to the original authors of the bulk of a project, than a fee to some company that took the code and added a few features before shrink-wrapping. If someone else does want to pay that commercial entity for getting those features added and shipped quickly - great! The next free release of the project will no doubt include those features if the demand was general enough - maybe the code is even contributed back by that same company after a 'competitive lag'.
c) We harbour petty grudges against RMS for saying bad things about Tcl many many years ago.. (haha - only serious!)
All hail RMS - the god of unnecessary reimplementation!
DKF: Yes, it's the whole "software as political crusade" aspect of the FSF that gets up many people's noses.
FPX: Choosing one license over the other is at a package author's sole discretion. The (L)GPL is a sensible license and has its place. It basically says, you're free to use my free software in any way you want, as long as you make your software (your "derived product") just as free. The BSD and other less restrictive licenses allow software to be used, modified, and sold without giving anything back to the community, and some author's don't like that idea. A case in point is WINE [L3 ]. Originally under the BSD-like X11 license, third-party corporations made significant improvements to the software in their own, proprietary branches, not releasing their patches. WINE then switched its license, and is now using the LGPL. Note the essential difference between GPL and LGPL: When you use a GPL package, your complete software becomes a derived product and must be covered by the GPL. When you use a LGPL package, your software is not a derived product, you can use any license you like; you just have to publish any modifications to the package under LGPL. This interpretation makes just as much sense for Tcl as for any other (compiled) language. Note that this only applies to published products: Both GPL and LGPL allow you to use derived products in-house without releasing any of your software.
CMcC: I now understand that the choice not to use GPL for software can be a protest against the political use of software. :)
SLB: LGPL certainly places fewer restrictions on application developers than GPL. However, in addition to the requirement mentioned by FPX, LGPL aims to ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library [L4 ].
On UNIX systems, some applications statically link the Tcl interpreter to avoid the problems that can arise when $LD_LIBRARY_PATH fails to locate the interpreter's dynamic library or worse picks up the wrong version. Such techniques would be more difficult if Tcl were LGPL.
WJP If you have qualms about the GPL but would otherwise like to use some GPL-ed code, I suggest contacting the author. Some users of the GPL are very hard core and will tell you to buzz off, but many others are willing to consider an alternative license in some circumstances. For example, there are projects that are dual licensed under both the GPL and a commercial license. Their authors will accept things that would violate the GPL in return for some other consideration, which may be money or may be some other arrangment regarding code, such as delayed open source release of the proprietary code. Some authors will agree to license code under the LGPL instead of the GPL if persuaded that it is in a good cause. Indeed, even RMS has done this in some cases. (He's not as extreme as some people think.) I myself generally release code under the GPL as a way of influencing the growth of free software, but am willing to make exceptions to this (in the event that anybody wants my code). So, don't take GPL licensing to be an absolute. A compromise may well be available if you ask.
KBK 2005-12-23: There are practical legal reasons that many Tcl'ish things, including the core, will be forever licensed under our BSD-like terms. They were released under those terms, with copyright vesting in corporate entities that no longer exist. The assigns of those copyrights will be difficult to locate, and negotiating any change to the license terms will be even more difficult to work out since the copyright holders have no interest in the project. The release under the BSD-like license was an irrevocable grant of precisely the rights granted by that license. We can depend on that - but no more; specifically, we cannot unilaterally change the terms to GPL, LGPL, the actual BSD license, or anything else. If this is 'license proliferation' (evil in the eyes of the OSF), or ideological impurity, so be it. We're stuck with it.
WJP 2005-12-23: I understand that Tcl licensing can't change. My point is that those interested in using code released under the GPL shouldn't shy away from it because of problems they have with the GPL without finding out if alternative licensing is possible for the GPL code.
LV 2006 Dec 15 - I have read comments in the past that seemed to indicate that the main restricts of GPL like licenses related to binary libraries that one might link into an application (or, I suppose, in the case of tcl, packages which might be required). But if a program performs an exec or open with a pipe, wouldn't one expect that would also constitute use of the GPL'd program, forcing the calling program to also use GPL?
gl 2006 Dec 18 From the GPL-FAQ: [L5 ] If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program. In short, the answer is No.
SLB I think a more accurate answer is, 'it depends' - you should also consider this paragraph from the same GPL-FAQ:
"... pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
DKF: If the "inner" program is reasonably considered to be independent of the outside program, and the "outer" program can be plugged into a different inner with the same effect, there can be no license cross-contamination between the two, the above paragraph notwithstanding. The first part of the previous paragraph really protects from inward-migration of the GPL's viralness (if "inner" is independent, it's "outer" that is choosing to make the coupling and is therefore the obligated party), and the second part deals with outward-migration (once again, because it demonstrates independence).
MAKR 2007-01-03: Common example in Tcl/Tk space for DKF's description: A command line only utility gpl is extended with a script tkgpl to provide a GUI. Usually tkgpl can only be used with gpl and is therefore derivative work in the sense of the GPL.
I wanted to give another example to comments farther above. There was some discussion about whether or not source GPL.tcl could be viewed as linking. Well, it depends:
IANAL though, so take this with a piece of salt. But I am programming Tcl in a corporate environment and these are the guidelines for me (short: avoid all GPLed stuff).
WJP 2007-01-07: It looks like code licensed under the LGPL avoids this problem.