Dockhand Adjusts Open Source License Model: Commercial Use Now Requires a Paid License

The open source Docker management tool Dockhand has made a significant change to its licensing model, drawing attention from the community. The update centers on a shift in the conversion timeline and tighter restrictions on commercial use cases. For developers and enterprises relying on this tool to manage container infrastructure, understanding these changes is essential.

What Changed in the License Model

According to the change record (commit 95a79d4) submitted by Dockhand on GitHub, two core clauses were modified:

Previously, Dockhand used a fixed-date conversion mechanism — all versions would transition to Apache License 2.0 on January 1, 2029. Under the new terms, the conversion date is now four years from the date a given version is first publicly released.

This means the conversion mechanism has shifted from a "global fixed date" to a "rolling per-version calculation." In other words, each newly released version starts its own four-year restricted period from its release date, after which it converts to the more permissive Apache 2.0 license. This approach is common among projects using the Business Source License (BSL) — it allows vendors to maintain commercial control over the latest versions for a longer period, rather than having all code open up at a single fixed point in time.

The Business Source License (BSL) was pioneered by MariaDB in 2016, designed to strike a balance between "fully open source" and "fully proprietary": source code is publicly accessible and available for review and non-commercial use, but with restrictions on specific commercial use cases during a time window, after which it automatically converts to a permissive license like Apache 2.0. BSL has been adopted by notable infrastructure projects including HashiCorp (Terraform), Sentry, and CockroachDB — and has remained controversial, as the open source community generally considers BSL non-compliant with OSI's definition of "open source," classifying it as "source available" rather than truly open source. Understanding the BSL framework helps in assessing the practical impact of Dockhand's latest adjustment on different user groups.

The Bar for Commercial Use Has Been Raised

Another key aspect of this update is the redefinition of commercial use boundaries. The new terms explicitly list which use cases do not require an additional license:

• Internal business use within an organization: Internal use is explicitly permitted regardless of how many Docker environments are managed;
• Managed Service Providers (MSPs): MSPs are allowed to manage Docker infrastructure on behalf of clients, provided the MSP itself does not offer Dockhand as a service to others.

The critical change is this — any production use beyond these scenarios, including use by companies, sole proprietors, self-employed individuals, public institutions, or any other organization (or on their behalf), now requires purchasing a Commercial License from the Licensor.

This language is stricter than the previous terms. Where BSL previously focused primarily on restricting "offering Dockhand as a commercial SaaS/managed service," the new wording broadens and clarifies the scope of commercial production use. Enterprise users who want to deploy Dockhand in production environments in a compliant manner will essentially need to obtain a commercial license.

Inconsistency Between Documentation and Code

One detail worth noting: despite the updated license terms, Dockhand's README.md still contains the old description. The Reddit discussion points out that the README still reads:

Dockhand is licensed under the Business Source License 1.1 (BSL 1.1).

• Free for: personal use, internal business use, non-profits, education, evaluation
• Not permitted: offering Dockhand as a commercial SaaS/hosted service
• Converts to Apache 2.0: January 1, 2029

This description clearly conflicts with the now-effective LICENSE file — most notably, the conversion date still reflects the old "January 1, 2029." The community generally believes this is likely an oversight by the maintainers when updating the license. The original poster also noted that the official website has the same outdated information.

This inconsistency between code and documentation is a potential trap for users. Legal validity typically follows the actual LICENSE file, not the summary language in the README. Users who rely solely on the README to determine whether their use is compliant may reach incorrect conclusions.

In software licensing practice, the LICENSE file in the root of a project repository is generally considered the binding authorization text. Descriptions in README files, websites, or other documentation are informal and do not constitute legal terms. When conflicts exist, the actual content of the LICENSE file prevails. For enterprise users, compliance review should focus directly on the LICENSE file itself and, where necessary, involve legal counsel — not rely on any secondary summaries or simplified descriptions. This principle applies equally to all open source projects using BSL, SSPL, or similar custom licenses.

What This Means for Users

For individual developers and teams using the tool internally, the direct impact of this change is limited — internal business use remains free with no restrictions on the number of managed environments. The users truly affected are enterprises looking to deploy Dockhand in commercial production environments, who now need to assess whether a commercial license is required.

From a broader perspective, this is yet another classic example of the tension between open source and commercialization. Licenses like BSL — "source available but with commercial restrictions" — have been adopted by a growing number of infrastructure projects in recent years. They preserve code transparency and the possibility of community contributions while giving vendors a sustainable path to monetization. Dockhand's shift from a fixed conversion date to a rolling four-year window per version is, in essence, an extension of the commercial window — reflecting the project's long-term commercial strategy.

For teams considering adopting Dockhand, it is recommended to refer directly to the latest LICENSE file in the GitHub repository rather than relying on potentially outdated information in the README or on the official website. Before deploying in a commercial context, clearly determining whether your use case falls within the "requires a commercial license" category is a necessary step to avoid compliance risk.