As I mentioned in the court ruling, Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. (
https://en.wikipedia.org/wiki/Lewis_Gal ... rica,_Inc.), the court does not recognize the technical term of "dynamic linking" and "binding", as portions of the programming community does, but rather if the creative work is derivative by having portions of the original contained within itself and in a
permanent form. Remember, the only case to make it to court, is Nintendo
losing and Galoob winning (who had the "dynamically linked plug-in/add-on).
The court also went even further into defining what a derivative work is, in regards to software. The Appellate court rejected Nintendo's claim of "dynamic linking" and "derivative work"
"[a] derivative work must incorporate a protected work in some concrete or permanent form."
Not only this, but the Appellate court reaffirmed the right of "Fair use". And which the GNU GPL also explicitly reaffirms this as well (
https://www.gnu.org/licenses/old-licens ... GPLFairUse).
And more precisely, Galoob had a plug-in/add-on that Nintendo claimed was "
dynamically linked" and
directly modifying their program by giving instructions. Galoob's Game Genie had
no independent purpose and could only be used
in conjunction with Nintendo's NES. The
court ruled against Nintendo and their claims. The plug-in/add-on of Galoob was
not considered dynamically linked
nor a derivative work, because it
could be separated and that code from the main program was not contained within the plug-in/add-on, so that it could be called a derivative work.
From lexikos
That isn't necessarily the case if the executable has been compressed.
A user's AutoHotkey script
can be separated, whether compressed, obfuscated, or encrypted. Because it
can be decompressed, deobfuscated, and decrypted. Further, the GNU GPL makes
no such restrictions on the use of compression, obfuscation, or encryption. There is
nothing in the GNU GPL that restricts, prohibits, or speaks against compression, obfuscation, or encryption.
From lexikos
The compiled EXE is not output of AutoHotkey, nor merely output of Ahk2Exe. It contains an AutoHotkey binary, compiled from AutoHotkey source code (though different portions of the code than AutoHotkey.exe). It cannot restrict what the user does with the script part independently of the compiled EXE, but the GPL most certainly can restrict what the user does (legally) with the compiled EXE.
From GNU GPL
Can I use GPL-covered editors such as GNU Emacs to develop nonfree programs? Can I use GPL-covered tools such as GCC to compile them?
Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.
Some programs copy parts of themselves into the output for technical reasons—for example, Bison copies a standard parser program into its output file. In such cases, the copied text in the output is covered by the same license that covers it in the source code. Meanwhile, the part of the output which is derived from the program's input inherits the copyright status of the input.
As it happens, Bison can also be used to develop nonfree programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction. We made the decision because there were other tools comparable to Bison which already permitted use for nonfree programs.
Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free?
In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program. If the user uses your program to enter or convert his own data, the copyright on the output belongs to him, not you. More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from.
So the only way you have a say in the use of the output is if substantial parts of the output are copied (more or less) from text in your program. For instance, part of the output of Bison (see above) would be covered by the GNU GPL, if we had not made an exception in this specific case.
You could artificially make a program copy certain text into its output even if there is no technical reason to do so. But if that copied text serves no practical purpose, the user could simply delete that text from the output and use only the rest. Then he would not have to obey the conditions on redistribution of the copied text.
In terms of output, I was referring to instructions (or data) processed through a GPL interpreter, where developers of compilers or interpreters attempts to lay claim to it. The GNU GPL specifically states, in addition to the law, that the developer has no such claim to the output or code that the user wrote. For instance, a user develops a game application with a GPL compiler or uses a GPL interpreter, the developers can't claim the output or code were derivative works that belong to them.
The GNU GPL then added confusion about Bison, where it copies a portion of itself into the output. They then make it clear that they permit nonfree/commercial use of Bison without restriction. This is likely the case not so much out of the goodness of their hearts, but because of legal copyright definitions.
In terms of restrictions on a compiled EXE, that is
not done by the GNU GPL. It's the
law and courts that decide the matter. And whether or not to pursue a violation comes from the copyright holders. As far as legal precedent. This has already been established in the Nintendo vs Galoob case. Any attempt to pursue the matter, would have to face the already made legal decision and definitions. The courts will be looking at
if the compiled EXE is a derivative work that violates copyright, not simply if there is a "binding", "linking", "bundling", or any other computer jargon. And Nintendo lost the case, the court made the "dynamic linking" computer jargon irrelevant, and Galoob's code was found not to be a derivative work of their main program.
From lexikos
Unlike the Game Genie device, which did not incorporate any portion of Nintendo's work, a compiled EXE clearly incorporates AutoHotkey.
Reading the court case of Nintendo vs Galoob is a helpful guide to how the courts see it. Because Nintendo's position was indeed that Game Genie's plug-in/add-on was a "
dynamically linked derivative work", thus was part of Nintendo's main program. So the counter argument, concerning AutoHotkey, appears to be that by the script and AutoHotkey interpreter being bundled together by what is called a "compiled" EXE, they are one. The answer looks to be
no, from the legal perspective. This argument is
similar to what Nintendo was making against Galoob. Nintendo was claiming that Galoob's add-on/plug-in was "dynamically linked" and a derivative work of their program. The Appellate court
rejected Nintendo's claim, because the plug-in/add-on could be
separated, there was no permanent change to the source/main code, and the source/main code was
not contained within the separated plug-in/add-on. The user's AutoHotkey script can be
separated, there is
no permanent change to the AutoHotkey interpreter, and there is no source code or interpreter code contained within the separated script.
AutoHotkey can not nor does not inject source code into a user's script, which is probably more aptly described as a document of instructions. The script itself does not contain source code nor code from the interpreter. And the GNU GPL even went into this more precisely
by clarifying interpreters. The AutoHotkey script is just data processed by the AutoHotkey interpreter, so there is no requirements about it's licensing. Even further, the AutoHotkey script can be created with numerous other software, such as Notepad, LibreOffice, etc... This only strengthens the position of it being more like a document of instructions, not a derivative work (as defined by the court) that contains portions of source code within itself.
And the court's definition of what is a "derivative work" for the purposes of copyright
deviates substantially from the layman's commonly used terms of "derived" or "linked". The courts have specific tests, often comparing the similarity of structure/content and purpose between 2 items, that they use. It is here where I think the FSF and GNU GPL purposely blurs definitions a bit (to include what appear to be contradictions) or attempts to create "viral infection" through association, and also where commonly used computer jargon creates confusion. However, we should focus too on the legal definitions in
copyright law versus just computer jargon, because that will ultimately decide the outcome.
GNU GPL
If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.
From lexikos
Clearly, "the interpreted program is effectively linked to the facilities it uses through these bindings" is talking about the script. AutoHotkey contains numerous libraries; it is not merely an interpreter.
From the GNU GPL
However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.
Note- That the GNU GPL is stating this part in the secondary paragraph, not the primary paragraph, where they state there are no requirements about licensing data processed through an interpreter.
As mentioned, the court does not recognize "dynamic linking" in the way that the programming community does. Rather, they will look at if the user's script is a derivative work that contains portions of the interpreter or source code (within itself) in a
permanent way. This is because copyright law is based on
original and creative works. Let us remember that the claim brought to the court will not be based on just if a "dynamic link or binding" occurred, but on if a violation of copyright occurred. So it is better to think in terms of copyright law, not computer lingo.
So when we are talking about "bindings" and "linked", are those
permanent bindings and linking where the script and interpreter can't be
separated from each other. In other words, where the copyright's holder original work is
permanently contained
within the other item in question. Keep also in mind, that this reflects on "Fair use" as well. The answer is
no, the bindings and links are
not of a permanent nature. If a compiled executable was made, where the user's portion and the original copyrighted work, source code, or interpreter could not be separated, then that is a permanent. This is why in a previous posting, I stated the AutoHotkey situation is easier, not harder to determine. Because the script and interpreter are more bundled together, than actually "compiled" in the traditional sense.
That the user's script and AutoHotkey's interpreter
can be separated from each other, means their
respective copyrights can be separate. And that is what the court appears to be looking at in a claim, as they did in Nintendo vs Galoob. Galoob's add-on/plug-in, could be
separated from the main code,
upon separation there was no part of the main code in the add-on/plug-in, and this separation resulted in
no permanent change to the main code. This then means you are dealing with
2 distinct items, versus a true and permanent merging and intermixing into 1 item.
In addition to selling his script (under his own copyright), the user also has the right of distribution, selling (charging for distribution), and "Fair use" of the AutoHotkey interpreter under the GNU GPL. As long as he meets the requirements of the GNU GPL of linking to the source code or a written offer to provide it upon request.
Of course. But that does not give them the right to distribute a derived work of AutoHotkey without complying with the license terms.
Again, one must comply with the terms of the license to have any rights granted by that license. The debate is about interpretation of the terms.
In this we are in agreement, if distributing AutoHotkey (along with selling any script of their's), users should comply with the GNU GPL requirements. And to comply with the terms of the GNU GPL, they should provide a l
ink to the AutoHotey/GPL source code (modified or unmodified) or have a
written offer to give it upon request. It's important to clarify what is under the GPL, so that the users know their rights on what they can do with it, and that they have access to the GPL source code. Keep in mind this is distinct and separate from the user's script, copyright, and license.
AutoHotkey_L VS AutoHotkey_Basic VS User's script
I detected possible confusion on this matter, so think it might be good to clarify the distinction. AutoHotkey_L is a
derivative work of AutoHotkey_Basic, because it directly contains portions of code from the original work (AutoHotkey_Basic)
within itself (C++). AutoHotkey_L is a “new edition” of a preexisting work (AutoHotkey_Basic) with
substantial similarity, thus a derivative that has to stay under the GPL. The 2 are
intermixed and interdependent upon each other. In executable form, one would not be able to separate code of one from the other.
A user's AutoHotkey script can be created on any word processing software. The code written on the user's script
can be separated from the AutoHotkey source (or interpreter) and is in a different programnot
ming language, C++ vs AutoHotkey. Thus distinguishing them from each other, from a legal perspective, and issues of copyright and licensing are much more clear. The user's code is
not a "new edition" of the AutoHotkey source's or interpreter's code. The script of the user is different in purpose, content, coding language, and internal structure from that of the source or interpreter, and so is arguably
not a derivative work and can be licensed by it's creator as they see fit. Even if the user's script is "bundled with", "linked to", or makes use of the AutoHotkey interpreter, separation and distinction between them can always be made.
And in terms of copyright, the AutoHotkey language in terms of who created it and named what, would arguably be a separate matter to the AutoHotkey source code. Meaning who has the right to call the terms used in the AutoHotkey language their own would be hotly contested.