Skip to content

Licensing

Heinzel Pro is sold as a subscription. The installation checks a signed license key offline: the key is never sent anywhere. What an installation does connect to is listed in security.md, "What leaves the installation".

For customers

  • Without a key, the installation runs a 14-day trial with three seats.
  • A seat is any enabled user who can act: operator, approver or administrator, or anybody given a single right to act. Rights to see are free.
  • After the key expires there is a 14-day grace period with a banner. After that, no new sessions or scheduled runs start; everything recorded stays readable.
  • Keys are pasted under Settings, License.
  • The key carries one number of seats for the whole installation. Where the installation holds several tenants, each can be given a number of its own below that, see administration.md, "Seats per tenant". A person counts once against the key, however many tenants they act in. Servers work the same way: the key carries one number for the installation, and each tenant can be given its own below it.

For the vendor

Keys are Ed25519 signatures over a JSON payload. Generate the signing pair once:

mix heinzel.license keygen

Put the public key into the build (config :heinzel_pro, :license_public_key) or set HEINZEL_LICENSE_PUBLIC_KEY on customer installations. Keep the private key offline.

Issue a key:

mix heinzel.license issue --customer "ACME GmbH" --plan team --seats 5 \
  --expires 2027-12-31 --private-key "$HEINZEL_LICENSE_PRIVATE_KEY"

Verify one:

mix heinzel.license verify HPL1....

Plans: team, business, enterprise. The payload also carries an optional server count and feature list for future use.

Source code for individual customers

Heinzel Pro is not open source software. Individual customers get the source code to read and change, under LICENSE.md, and may send changes back as pull requests. What they send back is sold to every other customer, so the rights to it are settled before anybody merges it:

  1. The customer's contract grants the access in writing.
  2. The customer returns the contributor agreement signed (the German text, docs/de/contributor-agreement.md), with the GitHub accounts of its people in the annex. It is kept outside the repository.
  3. The accounts go into .github/contributors. The check contributors fails a pull request while the person who opened it, or the author of one of its commits, is missing there.
  4. The accounts get the role "Read" on GitHub.

Step 4 requires the repository to belong to an organization. A repository of a personal account knows only collaborators with write access: whoever is invited there can push to main, merge pull requests and set a tag, and a tag builds the image and deploys it to the hosted installation. GitHub documents this under "Permission levels for a personal account repository". While the repository belongs to a personal account, no customer is invited.

The check proves who submitted, not who wrote. For third-party code under a named person's name the customer answers under section 6 of the agreement.