playground:servers

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
playground:servers [2025-05-14 16:23] – geekplayground:servers [2025-05-22 19:51] (current) – geek
Line 19: Line 19:
 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. 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.+Keeping all of this in mind, the only clearly acceptable way to distribute closed-source software written using the official AutoHotkey interpreter 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.
  
 ==== Alternate Interpreters ==== ==== Alternate Interpreters ====
Line 38: Line 38:
  
 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". 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".
 +
 +Some metrics can change over the lifetime of a single installation. For example, the operating system version, processor, motherboard, storage volume identifier, etc. Generally, some components of a fingerprint are allowed to change as long as the remainder of the fingerprint remains the same, allowing a sort of "Ship of Theseus" style evolution of the fingerprint. The goal is to prevent the software from losing its license authorization because of regular maintenance of the system (like replacing a failed hard drive, upgrading the CPU and/or motherboard, upgrading the OS) while still preventing the software from being copied to a new system entirely.
  
 Here are some of the fingerprint-able metrics you can access from AutoHotkey: Here are some of the fingerprint-able metrics you can access from AutoHotkey:
Line 57: Line 59:
 <code autohotkey> <code autohotkey>
 MsgBox ComObjGet("winmgmts:").ExecQuery("Select SerialNumber from Win32_BIOS").ItemIndex(0).SerialNumber MsgBox ComObjGet("winmgmts:").ExecQuery("Select SerialNumber from Win32_BIOS").ItemIndex(0).SerialNumber
 +</code>
 +
 +Operating System Version:
 +<code autohotkey>
 +MsgBox A_OSVersion
 </code> </code>
  
Line 82: Line 89:
 </code> </code>
  
 +Storage volume identifiers: ''VOL > info.txt''
 +
 +Network card MAC addresses: ''%%Getmac /NH >> info.txt%%''
 +
 +Computer System Product UUID (This is used to identify an OEM PC, it may be generic for custom built PCs or VMs):
 +<code autohotkey>
 +MsgBox ComObjGet("winmgmts:").ExecQuery("Select UUID from Win32_ComputerSystemProduct").ItemIndex(0).UUID
 +</code>
 +
 +MachineGuid (This is used to identify a Windows installation, but can be spoofed or cloned sometimes even by accident using tools like CloneZilla):
 +<code autohotkey>
 +MsgBox RegRead("HKLM\SOFTWARE\Microsoft\Cryptography", "MachineGuid")
 +</code>
 ===== Oracle Free VPS ===== ===== Oracle Free VPS =====
  
Line 98: Line 118:
 Account upgrades can take some time, so please be patient! For me, it took a little over six hours to complete. Account upgrades can take some time, so please be patient! For me, it took a little over six hours to complete.
  
 +===== Authentication Strategies =====
 +
 +Once you have installed a suitable VPS to act as your authentication server, you will need to consider what authentication strategy you will use. The two main strategies are HTTP Basic Authentication, and custom authentication built using a server-side program like PHP.
 +
 +==== HTTP Basic Authentication ====
 +
 +Basic authentication from the HTTP protocol allows you to require a username and password to be given in order to access resources from the web server. By assigning each user a username and password, your script can provide those credentials when trying to request a validation file from the server.
 +
 +Fingerprinting information can be used with this authentication scheme. However, the fingerprint will be merely concatenated onto the password such that if any part of the fingerprint changes, the credentials will be invalid. This is less useful than custom authentication.
 +
 +==== Custom Authentication ====
  
 +Custom authentication requires installing server-side software like PHP that can listen to requests made by your script and respond depending on the information your script provides in the request. Your script will make a request to the server providing the username and password, as well as each individual fingerprint component. The server can allow individual components of the fingerprint to change according to rules you decide, and keep track of those changes over time in a database.