GPLv3 source request · open record
GRBL is licensed under the GPLv3. SainSmart publishes this firmware as a public download. The binary contains no licence notice, no copyright notice and no offer of source. This page documents a request for that source, and every fact it relies on.
SainSmart has replied. On 20 August 2026 their customer support wrote that the company is conducting an internal compliance review of this request, and that its technical and engineering teams are carrying out a detailed review of the relevant source information. They undertook to share an update as soon as possible. The reply is reproduced in full in section 6.
On the same day, SainSmart also said so publicly. Their official SainSmart Technology, Inc. account commented on the video linked above:
“Our support team is following up on your request, which is currently under internal compliance and technical review. We’ll share you the update once the review is complete. Thank you for your patience.”
To be accurate about what that is and is not: it is a holding reply, not an answer. No Corresponding Source has been provided, no location for it has been identified, and no position has been stated on whether the GPLv3 applies. But it is a substantive and constructive response from a company that has been asked a licence question, made both privately and in public under its own name, and this record treats it as one. The earlier reply, on 18 August, had asked what purpose the source was needed for and for order information; the licence attaches neither condition.
This record was published publicly on 19 August 2026. On the same date, with the request still unanswered, the matter was referred to the Free Software Foundation, copying the Software Freedom Conservancy, exactly as SainSmart was told it would be. That referral asks those organisations for advice and for whether they wish to take the matter up with GRBL's copyright holders. It is not a claim that either organisation has adopted the case, and neither has endorsed anything on this page.
This page will be updated the day a response arrives from any party, including if SainSmart declines. The simplest resolution remains available to them at any time: publish the Corresponding Source next to the firmware download.
Do not take any of this on trust. The firmware is a public download and the hashes are
published below. You can confirm the central claim yourself in about two minutes: download the
file, search it for Grbl 1.1f, then search it for GPL. One of those
searches comes back empty.
Every entry below is documented elsewhere on this page or in the linked files. Dates are the dates things actually happened, not the dates they were written up.
| 2024-04 | A 3030-PROVer MAX owner reports the same firmware banner on a public forum and, asked to request the source, reports back that support “will not be releasing the firmware code”. A third party's account, quoted and linked in section 6, not a statement from SainSmart. |
| 2026-08-17 | Firmware downloaded from SainSmart's public S3 URL. The request returned HTTP 200 with no credentials sent; the response headers and hashes were captured at the same time. |
| 2026-08-17 17:10 |
Source request sent to support@sainsmart.com. |
| 2026-08-18 04:14 |
SainSmart replied, asking what purpose the complete source code was needed for and for 3030-PROVer MAX order information. They did not decline, and did not address whether the GPLv3 applies. |
| 2026-08-18 06:02 |
Reply sent: the licence conditions the obligation on neither a stated purpose nor a purchase. The file and its hashes were identified precisely, and SainSmart was asked either to say where the source can be obtained, or to state in writing that the firmware is not a GRBL derivative. |
| 2026-08-18 | This page published, with the build-level analysis added the same day. |
| 2026-08-19 | No further reply from SainSmart. The one-minute summary video was published on X, Facebook and Instagram, each linking here, and the request was put to SainSmart publicly. |
| 2026-08-19 | With the request still unanswered, the matter was referred to the Free Software Foundation, copying the Software Freedom Conservancy, as SainSmart had already been told it would be. The referral is published in full: read it here. It asks those organisations for advice and for whether they wish to raise the matter with GRBL's copyright holders. Neither has adopted the case, and neither has endorsed this page. |
| 2026-08-20 | Structural provenance analysis published: the compiled settings-report and
settings-restore routines follow GRBL 1.1f's internal order and layout, not merely its
output. This also corrected the application load base to 0x08006800 and with
it the runtime addresses quoted on this page. Working attached:
genmitsu-provenance-v1.zip. See
section 5. |
| 2026-08-20 | Second pass: twenty-four routines mapped to their upstream counterparts across
gcode.c, planner.c, stepper.c, protocol.c,
report.c and settings.c. An unrelated Ghidra BSim run, made before
the load base was corrected, independently lands on the same address for
plan_next_block_index. Working published:
genmitsu-provenance-v2.zip. |
| 2026-08-20 | Third pass: reference implementations of the mapped routines compiled from upstream GRBL
source for Cortex-M3 at six optimisation levels, plus machine-checked fingerprints. GRBL's
private planner constants ±0.999999 and its step-generator scalar
1.25 each occur exactly once in the firmware, and
plan_buffer_line() calls its internal helpers in upstream's order. A generic
n-gram similarity experiment in the same pass did not discriminate, and is published as a
negative result. Working:
genmitsu-provenance-v3.zip. |
| 2026-08-20 | SainSmart replied. Their customer support wrote that an internal compliance review of the request is underway, that technical and engineering teams are reviewing the relevant source information, and that an update will follow. Reproduced in full in section 6. SainSmart's official account said the same publicly the same day, commenting on the video that this record is under “internal compliance and technical review”. |
| Open | A compliance review is under way. No Corresponding Source has been provided yet, no location for it identified, and no position stated on whether the GPLv3 applies. This row will change when it does. |
SainSmart publishes the 3030-PROVer MAX firmware for public download at:
https://genmitsu.s3.us-east-1.amazonaws.com/101-60-3030PVM/3030_PROVerMAX_Firmware_V3.0.ziplinked from their own resource page at
docs.sainsmart.com.
The file is served to anyone who requests it. No login, no account, no proof of purchase. A
plain request with no credentials, no cookies and no referer returns HTTP/1.1 200 OK.
The full response headers are published here.
That is what makes GPLv3 section 6(d) the operative clause. Conveying object code by offering access from a designated place requires offering equivalent access to the Corresponding Source, in the same way, through the same place, at no further charge.
The request does not rest on owning a machine, and the author of this page is not a purchaser of a 3030-PROVer MAX. It rests on having received the object code from SainSmart's own public download, which is a conveyance under the licence. That is why the request stands regardless of order numbers.
The initial email of 2026-08-17 described the sender as a customer using the machine. That sentence was inaccurate. It is reproduced below unedited rather than quietly removed, because a record that has been tidied up is worth nothing. It never formed the basis of the request and nothing here depends on it.
Since SainSmart asked the purpose, here it is, offered as context and not because the licence requires one: this firmware was obtained and examined in the course of developing four-axis CAM software that has to produce correct G-code for this machine's rotary axis. Reverse engineering a published interface so that other software can interoperate with it is a lawful and ordinary thing to do, and it is how the licence question surfaced at all. To post-process correctly for a machine you read what its firmware actually is, and what this firmware announces itself to be, in its own banner, is GRBL.
The artifact discussed here is self-authenticating. SainSmart's own S3 object metadata carries the hash of the file they uploaded, and it matches the file served:
| What | Value |
|---|---|
x-amz-meta-sha256set by SainSmart |
cb044bc6757d59a1e4ba79f5a99f1967245684eee8c0f1d4ade31aa6f26a7e04 |
| SHA-256 of the zip as received 239,154 bytes |
cb044bc6757d59a1e4ba79f5a99f1967245684eee8c0f1d4ade31aa6f26a7e04 |
firmware.bin inside it119,796 bytes |
582322cd7bb8ae4c159376330e2731ca1281a35472ea9968558d6091343a911f |
There is therefore no ambiguity about which file is under discussion. A script that re-derives
all of the above from scratch, using nothing but curl and sha256sum, is
published here, along with the
checksums. Or do it by hand:
curl -O https://genmitsu.s3.us-east-1.amazonaws.com/101-60-3030PVM/3030_PROVerMAX_Firmware_V3.0.zip
sha256sum 3030_PROVerMAX_Firmware_V3.0.zip
unzip 3030_PROVerMAX_Firmware_V3.0.zip
strings -a 3030_PROVerMAX_Firmware_V3.0/firmware.bin | grep -i grbl
strings -a 3030_PROVerMAX_Firmware_V3.0/firmware.bin | grep -iE 'gpl|gnu|copyright|licen'The shipped image explicitly identifies itself as Grbl 1.1f, and the structural analysis
in section 5 independently supports that identification as a source-derived
GRBL build. The licence question follows from that: GRBL is GPLv3, and a program derived from it
carries that licence. Present verbatim in firmware.bin:
Grbl 1.1f ['$' for help] <- the standard GRBL startup banner
Grbl for ARM32
GRBL Controller V2
[VER:ARM32 V3.0.20230816:Along with GRBL's status and error reporting protocol: [HLP:, [OPT:,
|MPos:, |WPos:, |Bf:, |FS:, |Ov:,
|WCO:, ALARM: and error:.
GRBL is gnea/grbl, licensed under the GNU General Public License version 3.
All 119,796 bytes of firmware.bin were searched, case-insensitively, for each of
the following: gpl, gnu, general public,
copyright, (c), licens, licenc,
free software, grbl.org, github, jeon,
skogsrud, warranty.
Zero occurrences of any of them. No licence notice. No copyright notice. No attribution to GRBL's authors. No written offer of source.
Everything above rests only on the strings the firmware prints. This section goes one level
deeper, into the compiled code, because the structure of the program is consistent throughout with
a GRBL build and contains nothing that points away from one. Each claim below was read directly out
of firmware.bin with a standard ARM disassembler; addresses are given so any of it can
be checked against the same file whose hash is published in section 2.
The image is an ARM Cortex-M binary for an STM32F1-class microcontroller: it addresses the STM32 GPIO, timer, USART, RCC and FLASH peripheral blocks, and it contains no floating-point-unit instructions, so all real-number maths is done in software. It is fully stripped, with no compiler banner and no symbol names. GRBL is written in C and compiles to exactly this kind of image.
Of the entire interrupt vector table, exactly one hardware interrupt has a real handler; every other vector points at a default trap. That one handler is the step generator, and it produces step pulses the way GRBL's stepper does: OR-ing a per-axis bit into a shared output byte inside a short interrupts-off critical section.
handler @ 0x0801182c -> set_step_bits(0x08)
set_step_bits(0x10)
set_step_bits(0x20)
set_step_bits(0x40)
set_step_bits @ 0x08013d62: disable interrupts; port |= mask; enable interruptsThe same shape as GRBL's stepper.c, in a part of the program with no connection to
the version banner, so it is not a string that could have been copied for compatibility alone.
A block of default configuration constants sits at 0x080121ec. Among them are GRBL's
own stock behavioural defaults, present to the digit — the kind of internal value a
clean-room reimplementation would have no reason to reproduce exactly:
| Address | Value | What it is |
|---|---|---|
| 0x080121ec | 0.010 | $11 junction deviation — GRBL's default is 0.010 |
| 0x080121f0 | 0.002 | $12 arc tolerance — GRBL's default is 0.002 |
The version banner is assembled the way GRBL assembles it. GRBL's reporting code builds its
build-info line as [VER:<version>.<build>:; the shipped firmware prints
[VER:ARM32 V3.0.20230816:, the same construction with the version text substituted.
Added 2026-08-20. The findings above concern strings and constants. These concern executable structure, which is the harder thing to explain away, because a program that merely imitates GRBL's serial protocol has no reason to arrange its own internals the same way.
First, a correction that this analysis produced. The distributed firmware.bin is not
loaded at the start of flash. It is an application image that loads at 0x08006800,
leaving 0x6800 bytes below it reserved for the vendor's boot and configuration region,
which is not included in the download. Its reset vector points at
0x08006900, and the matching startup code sits at file offset 0x100, which
fixes the base at 0x08006900 - 0x100. Runtime addresses on this page have been
recalculated accordingly; earlier revisions computed them from the start of flash. File offsets,
hashes and the substance of every finding are unchanged.
The settings report is emitted in GRBL's exact order. The compiled routine at
0x08010a80 reports setting numbers in the sequence
0 1 2 3 4 5 6 10 11 12 13 20 21 22 23 24 25 26 27 30 31 32, which is the sequence
GRBL 1.1f's report_grbl_settings() emits. It then starts the axis settings at
100, runs four categories, indexes the axis arrays by four bytes per float, adds
10 to the setting number after each category, and negates max travel by flipping the
IEEE-754 sign bit — the same loop, the same numbering scheme, the same per-category
behaviour as upstream. The vendor build selects three or four axes before the inner loop, which is
what extending that routine for a fourth axis looks like.
The settings restore follows GRBL's structure too. The routine at
0x08011e14 tests restore-flag bits 0x01, 0x02 and
0x04, matching GRBL's defaults, parameters and startup-lines bits. On the defaults
branch it writes the settings structure in upstream's order: step pulse 10, idle lock
255, step invert mask, direction invert mask 3, status mask, then junction
deviation and arc tolerance into consecutive structure slots. On the parameters branch it zeroes a
sixteen-byte object — four floats, one per axis — and loops an index from zero through
seven inclusive, which is exactly GRBL's coordinate-data reset over
SETTING_INDEX_NCOORD. None of that is visible from outside the machine, so none of it
serves protocol compatibility.
The reporting strings appear in upstream's source order.
error:, ALARM:, [MSG:, Reset to continue,
'$H'|'$X' to unlock, Caution: Unlocked, Enabled,
Disabled, Check Door, Check Limits, Pgm End,
Restoring defaults, Restoring spindle, Sleeping — the
order of the corresponding cases in GRBL's report.c, with the vendor's own
Estop is activated! appended after the stock group.
Taken together this is consistent with a source-derived port of GRBL 1.1f rather than an independent implementation that speaks GRBL's protocol. That is a technical conclusion about provenance, not a legal one, and it is stated here only because it is checkable.
A second pass mapped twenty-four routines in the firmware to their upstream counterparts in
gcode.c, planner.c, stepper.c, protocol.c,
report.c and settings.c, each with the reasoning recorded. The planner
alone accounts for thirteen of them, including plan_buffer_line,
plan_compute_profile_nominal_speed and planner_recalculate.
The clearest single example needs no tooling to check. At 0x0800cf10:
adds r1, r0, #1
uxtb r0, r1
cmp r0, #36
bne +2
movs r0, #0
bx lrwhich is GRBL's plan_next_block_index(): increment the ring index, and if it has
reached the buffer size, wrap to zero. Immediately after it, at 0x0800cf1c, sits its
mirror image — if the index is zero set it to the buffer size, then decrement — which is
GRBL's plan_prev_block_index(). Two one-line static helpers, adjacent, in upstream's
order, sharing the same buffer constant. The constant here is 36, a vendor value;
stock GRBL ships a smaller planner buffer. That is what a modified copy looks like: upstream's
structure, retuned.
Before the load base was corrected, an entirely separate analysis of this binary was run using
Ghidra's BSim, which matches compiled functions against reference builds by
signature rather than by reading structure. It reported a match for
plan_next_block_index at a similarity of 1.00.
Rebased to the correct application base, that hit lands at 0x0800cf10 —
the same address the structural analysis arrived at independently, by a different method, with
no knowledge of the BSim result. The two approaches were not run by the same tooling and did not
share inputs.
Where they disagree, that is recorded too: BSim named the routine at 0x0800d094
plan_cycle_reinitialize where the structural map calls it plan_reset.
Those are neighbouring routines in the same upstream file and BSim's confidence there was low, so
the map's reading is likely the better one. It is noted rather than smoothed over.
A third pass went after the parts of GRBL that exist only inside the program, where protocol compatibility offers no explanation at all.
Two constants that belong to GRBL's planner. When GRBL decides how fast it can
carry speed through a corner, it tests the cosine of the junction angle against
0.999999 and -0.999999 to catch the straight-line and full-reversal cases.
Those two values sit in this firmware's planner literal pool as
0x3F7FFFEF and 0xBF7FFFEF, adjacent, at
0x0800d598 and 0x0800d59c, with a large-value guard immediately after
them. Each occurs exactly once in the whole binary. Separately, GRBL's step generator uses
a private tuning scalar of 1.25; that value appears once, at
0x08012ed0, in the step-preparation path. None of these are visible over the serial
link, and nothing about GRBL compatibility requires choosing the same numbers.
The planner calls its own helpers in GRBL's order. Reading the calls out of
plan_buffer_line() at 0x0800d230, in the order they occur:
convert_delta_vector_to_unit_vector
limit_value_by_axis_maximum
limit_value_by_axis_maximum
convert_delta_vector_to_unit_vector (again, inside the junction geometry)
limit_value_by_axis_maximum
plan_compute_profile_nominal_speed
plan_compute_profile_parameters
plan_next_block_index
planner_recalculateThat is the shape of GRBL's plan_buffer_line(): normalise the movement vector, clamp
it against the per-axis maxima twice, then do the same normalise-and-clamp again while computing the
junction, then the profile helpers, then advance the ring and recalculate. Two programs can agree on
what to print. They do not independently agree on the order in which their private internal helpers
call each other.
Alongside this, the same pass compiled reference implementations of those routines from upstream GRBL source for Cortex-M3 at six optimisation levels, so the comparison is against real compiled code rather than intuition.
Recorded because a record that only reports its successes is worth less. The same pass also tried scoring similarity by generic instruction n-grams against those reference builds. It did not discriminate. For several routines an unrelated control function scored as high as, or higher than, the expected match. That approach is reported as a negative result and carries none of the conclusion here.
Two further limits stated by the analysis itself: the reference builds were made with Clang, not with the ARM GCC that SainSmart is likely to have used, so no claim is made about identifying their compiler; and in the parser check, twenty-two of twenty-four expected command-family values appear as direct immediates while two are folded by the compiler into jump-table behaviour. The conclusion rests on the private constants and the internal call structure, which survive compilation across toolchains, not on similarity percentages.
The full working is published, including the scan scripts, their JSON output, the function map
with its per-entry reasoning, and complete disassembly listings for the parser, planner, stepper,
protocol loop and settings routines:
genmitsu-provenance-v3.zip, which also carries the
reference-build sources, the compiled reference objects and their disassembly, and the
machine-checked fingerprint results including the negative one. Earlier passes remain at
genmitsu-provenance-v2.zip and
genmitsu-provenance-v1.zip.
Every address is given as both a file offset and a runtime address, so all of it can be checked
against the same firmware.bin whose hash is published in
section 2. The disassembly reproduces with any ARM disassembler by linking
the raw image at 0x08006800. The bundle also contains the notes from the independent
re-derivation of every claim before it was published here, including the cross-check above and
the one disagreement it turned up.
Stock GRBL was written for 8-bit AVR; public, GPLv3-licensed ports that move GRBL 1.1f onto STM32 microcontrollers have existed for years and are freely available. Whatever SainSmart started from and however they changed it, a program built on GPLv3 code carries the GPLv3 with it. Porting it to new hardware or adding features does not create a new, unencumbered work; it creates a derivative work under the same licence, the source obligation included.
In April 2024, more than two years before the request documented below, a 3030-PROVer MAX owner posting as hendr1x ran into the same firmware on the Sienci community forum. Their machine reported the same strings analysed on this page:
Grbl 1.1f ['$' for help]
Grbl for ARM32
Version:ARM32 V3.0Asked by another user to request the source, they reported back on 15 April 2024:
“I just heard back from support. They will not be releasing the firmware code.”
and on 23 April 2024:
“Genmitsu developers have stated they will be offering no help on this matter.”
In the same thread they wrote that when they asked about the controller board, SainSmart “confirmed it was a custom made board for them”.
Read this carefully for what it is. It is a third party's account of what he was told, not a statement from SainSmart, and not something this page can verify beyond quoting the public thread and linking it so you can read the whole exchange yourself. SainSmart may dispute that characterisation, and if they do, that will be published here. What it does show is that the question predates this request by more than two years, and that the answer reported then was not that the firmware is unrelated to GRBL, but that the code would not be released.
To Whom It May Concern,
I am a customer using the Genmitsu 3030-PROVer MAX CNC router. The firmware provided for this machine is a modified derivative of GRBL, which is licensed under the GNU General Public License v3.0 (GPLv3).
Under the terms of the GPLv3 license, any distributor of binaries compiled from this code must make the corresponding, complete source code available to the users who receive the product.
Please provide a link to the complete source code, including the custom multi-axis/4th-axis configuration files, or forward this request to your compliance and engineering teams.
Thank you,
Jason
Hello Jason,
Thanks for contacting SainSmart! This is Jamie from SainSmart support.
Could you please let us know the purpose for which you need the complete source code? This will help us better understand your requirements and determine how we may be able to assist you.
Also, could you please provide us with your 3030-PROVer MAX order information? We'd like to verify the purchase details on our side first.
Thank you for your cooperation. We look forward to your reply.
Best regards,
Jamie
SainSmart Customer Support Representative
No source was provided, no location for the source was identified, and no position was stated on whether the GPLv3 applies. Neither of the two questions asked is a precondition in the licence: section 6(d) does not condition source availability on the recipient's purpose, nor on a purchase.
The full reply is published here, and the complete thread here. It restates the basis above: the obligation arises from distribution, the file and its hashes are identified precisely, and SainSmart is asked either to say where the source can be obtained or to state plainly and in writing that the firmware is not a GRBL derivative.
Thank you for your patience, and I sincerely apologize for the delay in getting back to you.
We are currently conducting an internal compliance review regarding your request. As part of this process, our technical and engineering teams are carrying out a detailed review of the relevant source information.
We take this matter seriously and will be actively following up with the relevant teams. Rest assured that we will share an update with you as soon as possible.
Thank you again for your patience and understanding while we work through this request.
SainSmart replied to the initial email within about four hours, asking two questions the licence does not make preconditions. The substantive reply answering them was sent on 2026-08-18 at 06:02. On 20 August 2026 SainSmart wrote again, stating that an internal compliance review of the request is under way and that their technical and engineering teams are reviewing the relevant source information.
That is a holding reply rather than an answer: no source has been provided, no location for it identified, and no position stated on whether the GPLv3 applies. It is recorded here as a constructive response nonetheless, because it is one. A company that opens a compliance review after a licence question is doing the thing a licence question is meant to prompt, and this page has no interest in reading it less generously than that. The straightforward resolution remains the same and remains available: publish the Corresponding Source alongside the firmware download.
Because the request concerns a public download and therefore every person who received it, this record was published publicly on 19 August 2026. On that date the step already stated to SainSmart in the reply above was taken: the matter was referred to the Free Software Foundation, copying the Software Freedom Conservancy, the organisations listed in section 9. They were asked for advice and for whether they wish to raise it with GRBL's copyright holders. Neither organisation has adopted the case or endorsed this page, and this note records only that the referral was made. The referral is published here in full and unedited, like everything else in this record: fsf-referral-2026-08-19.txt.
Stated plainly, so the record claims exactly what it proves and nothing it does not.
The obligation documented here runs to everyone who received the firmware. If you bought a 3030-PROVer MAX, you are in a stronger position than the author of this page: you did not merely download the object code, you received it as the purchaser of the product it runs on. Section 6 of the GPLv3 gives you, as a recipient, a right to the Corresponding Source. You need no one's permission to ask for it, and you do not have to accept a stated purpose or an order number as a precondition, because the licence attaches neither.
Asking is the whole mechanism. A licence like this stays honest because the people who received the software request what it entitles them to. If you would like to, here is a request you can send as written. It asserts nothing you cannot see for yourself: that the firmware supplied for your machine calls itself GRBL.
Subject: GPLv3 source request — Genmitsu 3030-PROVer MAX firmware
To Vastmind LLC, operator of SainSmart / Genmitsu,
I own a Genmitsu 3030-PROVer MAX that I purchased from you. The firmware you supply for it identifies itself, in its own startup banner, as “Grbl 1.1f”. GRBL is licensed under the GNU General Public License version 3.
Under section 6 of that licence, as a recipient of the firmware I am entitled to the Corresponding Source: the code needed to build, install and modify it, including the build scripts and configuration, and any changes you have made to it. Please tell me where I can obtain it.
If it is your position that this firmware is not a GRBL derivative and the GPLv3 does not apply, please say so in writing.
Thank you,
[your name]
[your order number, if you wish to include it]
Send it to support@sainsmart.com. If you would also like the request to reach the
organisations that assist copyright holders with these cases, you can copy
licensing@fsf.org. Keep it civil. The aim is the source, not a fight, and a calm dated
request on the record is worth more than an angry one.
The firmware is published under the SainSmart brand, and its sibling brand Genmitsu. SainSmart is an operating name of Vastmind LLC, the company that owns the SAINSMART trademark (US Reg. 5,437,476) and operates sainsmart.com, whose own pages carry a “© Vastmind LLC” footer. A request for the Corresponding Source is properly addressed to that company, through its published support channel. This page does not name any individual as responsible, because the operating entity is the accountable party and naming a person without solid evidence would be the one careless move on a page built to avoid them.
Making source available is Vastmind LLC's obligation. Enforcing the licence is not something the author of this page can do, and no such claim is made. A GPL licence is enforceable by its copyright holders. For GRBL that is Sungeun K. Jeon and Simen Svale Skogsrud, and contributors to gnea/grbl. Recipients of a binary may request source; they cannot sue over it.
Two organisations work with copyright holders on precisely this kind of case:
licensing@fsf.orgIf you own a Genmitsu machine, the practical stake is straightforward. Source is what lets a community fix defects the vendor will not, keep a machine working after it goes end of life, and add capabilities like proper fourth-axis handling. It is the difference between owning a tool and renting one.
The simplest resolution remains available to SainSmart at any time: publish the Corresponding Source next to the firmware download. That satisfies section 6(d) directly and resolves the matter for every user at once, rather than one support ticket at a time.