Script License Management

If you are building commercial software with AutoHotkey, you may need to build some license management infrastructure in order to avoid software cracks, source code leaks, password sharing, etc.

This does not constitute legal advice.

The AutoHotkey interpreter software is released under the GPL v2.0 license. This license gives users broad rights to freely access and use the software and its source code, as well as any "derivative" software and source code from applications that "in whole or in part contains or is derived from the Program or any part thereof".

Scripts written to be run by AutoHotkey are not inherently constrained under that GPL v2.0 license, but by bundling your script with a copy of the AutoHotkey interpreter with a tool like ahk2exe, in order to form a "compiled" or "bundled" script, it is clear that the terms of the GPL v2.0 license should apply.

Distributing your scripts alongside a standalone copy of AutoHotkey does not avoid the implicit transfer of the GPL v2.0 license to your script file. When distributed alongside a standalone copy of AutoHotkey, your script forms what is effectively a kind of plug-in for the AutoHotkey interpreter software. When the AutoHotkey interpreter loads your script into its own process space, and the script's code is integrated with the AutoHotkey standard library of GPL-v2.0-licensed functions, the script and interpreter form a single combined program that would in its entirety be covered by GPL v2.0.

Building an installer that first downloads and installs AutoHotkey before installing your own non-GPL-licensed AutoHotkey-based software is also not clearly legal, although to my knowledge this has not yet been tried in a court of law.

The primary developers of AutoHotkey have expressed in the past that they have no intent of prosecuting developers who build software that bundles the AutoHotkey interpreter in this way. However, these statements of intent do not actually waive their legal rights if they were to change their minds. In addition to the primary developers, there are a couple dozen known contributors, some of which who are known to be hostile towards the AutoHotkey project, that would also have standing to prosecute this type of GPL v2.0 violation.

It is also possible that in some jurisdictions, users of any software you create that bundles the AutoHotkey interpreter may also have the right to enforce the GPL v2.0 license against your software. In California, the ongoing case of SFC v. Vizio argues that any third party who stands to benefit from a GPL license being enforced has the power to enforce the license.

Keeping all of this in mind, the only legally sound way to distribute closed-source software written in AutoHotkey appears to be to distribute it separately from the AutoHotkey interpreter entirely. This would require your users to first install AutoHotkey on their own before choosing themselves to integrate it with your script by running the script with the interpreter.

Although the premiere AutoHotkey interpreter is licensed under this "viral" GPL v2.0 license that tends to spread itself around to adjacent components, alternate interpreters come with their own licenses that offer their own licenses and restrictions.

The Keysharp project is licensed with an older revision of the BSD 2-term license. This license readily permits the bundling of the Keysharp software alongside other dis-similarly licensed software, provided that the Keysharp software itself retains its licensing information separately from the rest of the bundle.

See full article: Source Encryption

Keeping in mind the issues with the licensing of the AutoHotkey interpreter, if you are building software you intend to sell I recommend focusing on the use of FeiYue's Source Code Encryptor because it does not require impermissible bundling of the interpreter.

Software licenses are usually tied to both a user of the software, and some number of computer systems that the software will be installed onto. In order to enforce the installation limit, one or more metrics of the computer system must be fingerprinted to validate that the user did not attempt to impermissibly transfer the software from one computer to another. Together, these collected metrics form what is called a "fingerprint".

Here are some of the fingerprint-able metrics you can access from AutoHotkey:

Motherboard Serial Number:

MsgBox ComObjGet("winmgmts:").ExecQuery("SELECT SerialNumber FROM Win32_BaseBoard").ItemIndex(0).SerialNumber

Processor Serial Number:

MsgBox ComObjGet("winmgmts:").ExecQuery("SELECT ProcessorId FROM Win32_Processor").ItemIndex(0).ProcessorId

BIOS Serial Number:

MsgBox ComObjGet("winmgmts:").ExecQuery("Select SerialNumber from Win32_BIOS").ItemIndex(0).SerialNumber

Computer Name (host name):

MsgBox A_ComputerName

User Name:

MsgBox A_UserName

Processor Metadata:

MsgBox (
    EnvGet("PROCESSOR_ARCHITECTURE") "`n"
    EnvGet("PROCESSOR_IDENTIFIER") "`n"
    EnvGet("PROCESSOR_LEVEL") "`n"
    EnvGet("PROCESSOR_REVISION")
)

You must register with your legal name, address, phone number, and link a valid credit card (you shouldn't be charged).

Create an instance, "always-free". Put in your SSH Key

Create an ingress rule, CIDR 0.0.0.0/0 destination port range 80 https://dev.to/armiedema/opening-up-port-80-and-443-for-oracle-cloud-servers-j35

Instance creation is subject to availability at the time you're creating the instance. Priority is given to "pay as you go" accounts, which you can upgrade to under "Bill & Cost Management > Billing > Upgrade and Manage Payment". After upgrading, you can still use "always free" resources as long as you keep them under the free limits. Any usage in excess of the limits will be billed to you. Upgrading requires you have at least $100 free on the linked credit card for a temporary hold, which will be refunded immediately.

https://docs.oracle.com/en-us/iaas/Content/Billing/Tasks/changingpaymentmethod.htm

Account upgrades can take some time, so please be patient! For me, it took a little over six hours to complete.