The licence that never phones home

The channel nobody thinks about

Anyone deploying software in a company today usually accepts tacitly that it phones home regularly — a call to the manufacturer that checks whether the licence is still valid, whether a new version is available, whether the account is still active. For most programs that is unproblematic. For a tool that processes personal data from Jira and Confluence, this very channel is a contradiction in itself: a system that claims to send nothing out without control ought not to open an outbound connection of all things for its own licence check.

JiCo solves this by never letting that channel become ongoing control: outbound connections exist only when a person triggers them, and only to a single, named recipient — the licence portal, whatever the contract tier: for the licence request, for "Check for update" and for setting up the optional remote access. None of them carries anything from Jira or Confluence, only technical data such as the machine code, customer number and signature. Every licence obtained this way is then checked exclusively offline, freshly on every single tool call.

How a licence actually comes about

JiCo produces a signed block of text for this — customer number, machine code, installation key, never anything from Jira or Confluence. JiCo sends this block straight to the licence portal and gets the checked licence back in the same moment; only the very first request of an installation needs a one-time confirmation via an e-mail link for that. That holds for every contract tier: for Team and Enterprise contracts, a point of contact invites the company's authorised addresses in the portal, and each of them then draws their own licence from the shared quota. Up to 200 seats the quota itself is bought in the portal; only beyond that, for Enterprise, does it run through a conversation with the licensing office.

This licence is bound to two things, neither of which can simply be copied: the machine code, a hash of the actual device ID, and an installation key created at the very first request. A fresh installation always has a new key and therefore always needs a new request — a licence cannot simply be copied onto a second machine.

What the licence actually governs

A licence is more than a yes or a no. It always covers Jira and Confluence, allows reading and writing — every write action only with a person's approval — and determines how long it is valid and how many answers from a model it permits per day. (Update 2026-10-04: the former choice between a "read" and a "write" level no longer exists, JICO-D-1745.)

For a first contact there is a single trial licence per customer: after registering in the portal, seven days, reading and writing, no payment details — with at most three executed write operations per day, counted from JiCo's own audit trail, not by a server. That is enough to experience redaction and analysis on your own tickets, plus a proposal and its approval, without a trial account turning into a permanent production system.

What happens if the bill is not paid

A system without an online connection cannot withdraw a licence at the push of a button — that is not claimed for JiCo but stated openly. Instead a block takes effect through three levers at once: a limited term that is only extended against a paid invoice, a signed revocation list that ships with every new package build and rejects blocked licence IDs, and the licence portal, which from the second reminder onwards simply delivers nothing any more. The revocation list itself contains exclusively licence IDs — no customer names, no reasons, nothing that would reveal anything beyond the plain rejection.

The honest qualifier that belongs with it: an installation that never applies an update keeps running until the end of its term, even if its licence ID has long been on the revocation list. That is not a gap somebody overlooked, but the direct consequence of the same decision that shapes the rest of JiCo: no polling channel over which something could be enforced quietly, and therefore no such block either.

The invoicing path stays separate from JiCo itself

The commercial side of a licence deliberately does not run through JiCo either, but through the separate licence portal and the accounting software sevDesk. Ordering happens exclusively on the web, on invoice; payment is by bank transfer or, via Stripe, by card or SEPA. German customers pay the usual VAT, EU companies with a verified VAT ID via the reverse-charge procedure, Swiss companies without German VAT. Invoices themselves are issued in the electronic invoice format that is now mandatory for German companies (XRechnung/ZUGFeRD) — an obligation that applies independently of JiCo anyway, but is observed here from the start instead of being retrofitted. For JiCo itself none of this changes the basic rule: there are no payment codes and no connection to a payment provider inside the program.

Why sales of all things plays a supporting role here

JiCo is sold exclusively to companies, always on invoice — a deliberate decision against the consumer protection duties that a B2C sale would bring with it. Every delivered package also belongs to exactly one sales partner: the request goes to that partner's licence portal, and a package only accepts licences signed with the keys of that one partner. The portal holds accounts and licences, never Jira/Confluence content — and every check takes place locally, on the customer's machine.

What remains in the end is a simple, verifiable sentence: anyone looking at the firewall log during a normal working day will find at most short connections to the licence portal — triggered by a person requesting a licence or checking for an update, never in the background and never to any other destination that was not explicitly configured. Anyone who switches on remote access will additionally see its tunnel for as long as it is switched on. No telemetry, no phone-home, no quiet control.