Pimp My IDE / garage dispatchBack to the garage
October 10, 2026 / build provenance / software licenses

Read the build plate.

A public repository, a store download, and a self-built package can share a product name while carrying different code and terms.

Do not ask whether a product is open source as one yes-or-no question. Record the exact artifact, source revision, included modules, license files, and distribution route.

The noun is too broad.

Bitwarden announced that its next app-store releases will use commercially licensed builds. The company says the GPLv3 version will keep receiving updates on GitHub, current features remain in both versions, and self-hosting does not change.[1]

Those statements describe several related artifacts. They do not give every artifact one license. "Bitwarden is open source" and "Bitwarden went closed source" both erase the useful question: which build did you receive?

The product name is not the license receipt.

The repository already has two lanes.

At revision df96418, the client repository says GPLv3 is the default. It limits the Bitwarden License to code under bitwarden_license unless a file header says otherwise.[2] The commercial license grants use of those modules for internal development and testing in a non-production environment. It restricts redistribution and competing use.

The browser workflow makes the split concrete. Its matrix builds an open-source lane without the licensed folder and a commercial lane that includes selected code from that folder. The workflow then runs separate package commands and names the commercial artifacts with a bit- prefix.[2]

Availability, rights, and parity are separate.

Readable source does not answer what you may redistribute. A license file does not prove which modules entered a store binary. A promise of feature parity does not prove that parity at every later release. Self-hosting rights do not identify the license of a desktop or browser package.

The announcement makes current claims about the next release and current features. Treat those as dated commitments. Save the version, download route, source revision, license notice, and feature check together. Repeat the check after an update changes any of them.

Concern is not evidence of a later split.

The Hacker News discussion contains two clear reactions. Some readers accept commercial-use limits if public source and personal self-hosting continue. Others worry that feature parity may erode.[3] Those comments explain why buyers want durable evidence. They do not establish what Bitwarden will ship later.

The useful response is a watchable contract. Track whether the GPL build still publishes, whether the relevant feature exists in both lanes, whether the store notice matches the binary route, and whether self-host instructions still work. A future change should trip a named check instead of restarting the argument.

Put a plate beside every dependency.

For editor extensions, credential helpers, agents, and desktop tools, keep six fields: artifact name, version, download route, source revision, included-module boundary, and governing license files. Add a feature-parity check only when the vendor claims parity.

The customs bench below builds that record. It does not identify an installed binary or give legal advice. It marks which evidence fields you selected and leaves the real version, digest, and license notice open.

Interactive makeover / build selector plus provenance receipt

Scan the arrival route.

A normal product badge hides the package route. This reader joins route selection, evidence checks, a moving customs carriage, and a copyable record. It never turns selected fields into verified facts.

Select routeName artifactInspect evidenceSave receipt

Arrival lane

Choose how the package reached you. Then select the evidence fields your review will require.

Choose a package route
Choose evidence fields
App store lane2 of 4 fields selected

Commercial build route expected

The announcement says the next app-store release will use the commercial build. Capture the store, package version, binary digest, and bundled license notice.

Route
APP_STORE
Expected lane
COMMERCIAL_BUILD
Source claim
GPL_BUILD_PUBLISHED_SEPARATELY
Proof state
2_OF_4_FIELDS_SELECTED
Template structure started. The installed package is not identified or verified.
Sources read / October 10, 2026 UTC

Source log

Open the customs record
  1. Bitwarden Community, "Published version update in app stores", posted October 9, 2026 and read October 10, 2026 UTC. A Bitwarden employee states that the next store release will use commercially licensed builds, the GPLv3 build will remain on GitHub, current features are in both versions, and self-hosting is unchanged. These are company statements about current plans.
  2. Bitwarden clients repository at revision df9641824436b65207f393d35b8d07225129797b, read October 10, 2026 UTC. The root license notice, GPLv3 text, Bitwarden License, licensed-code directory notice, and browser build workflow support the two-lane repository and workflow description.
  3. Hacker News item 50033407, "Bitwarden Dual License Model", read October 10, 2026 UTC. The discussion supplies reader reactions about commercial-use limits, source availability, self-hosting, and future parity. It does not verify Bitwarden's builds or predict later licensing decisions.

Artifact boundary: the repository files were read at the pinned revision. No Bitwarden package was installed, built, or compared with a store binary. The interactive reader is a browser-only evidence template. Its route descriptions follow the announcement and pinned workflow, not an inspection of a released store package.