Chi consuma una licenza, e chi no
Nel modello GitHub Enterprise una licenza si consuma per appartenenza, non per attività: il fatto che una persona non apra GitHub da mesi non libera nulla. Consumano una licenza i membri di organizzazione (owner inclusi), gli enterprise owner che siano anche membri o owner di almeno un’organizzazione, gli outside collaborator su repository private o internal — contati una sola volta a persona, anche se collaborano su più repository e più organizzazioni — e i dormant users, cioè gli account inattivi che però restano membri di almeno un’organizzazione.
Non consumano licenza i billing manager, gli enterprise owner senza alcuna appartenenza organizzativa, gli outside collaborator sui soli repository pubblici e i managed user account sospesi in uno scenario Enterprise Managed Users. Su GitHub Enterprise Server il criterio cambia: consuma licenza ogni utente attivo che si sia autenticato con successo, più i dormant users, mentre restano esclusi gli utenti sospesi e il setup user integrato dell’istanza. Tenere a mente questa differenza è essenziale, perché i quattro scenari di deployment — GHEC con account personali, GHEC con EMU, GHEC con data residency (che richiede EMU) e GHES — alimentano lo stesso conteggio con regole di conteggio diverse.
Il caso che sorprende di più sono gli inviti in sospeso. Con le licenze acquistate a volume, un invito a entrare in un’organizzazione come membro o owner, e allo stesso modo un invito a un outside collaborator su repository privata o interna, impegna una licenza già prima che venga accettato. Ci sono due eccezioni da conoscere: se l’invitato consuma già una licenza nell’enterprise e l’invito è indirizzato al suo username GitHub o a un indirizzo email verificato, non viene occupata una seconda licenza; e se l’enterprise è su usage-based billing, gli inviti in sospeso non consumano licenza.
Volume licensing e usage-based billing
I due modelli convivono. Con il modello volume/subscription si impegna in anticipo un numero fisso di licenze e si continua a essere fatturati così fino alla scadenza dell’accordo. Con usage-based billing si paga ogni mese per le licenze effettivamente consumate, senza impegnarsi su un numero prestabilito.
Qui nasce una distinzione che l’esame ama: consumed licenses sono le licenze attualmente in uso, billable licenses sono le licenze uniche fatturate in un ciclo di fatturazione. Se durante il mese qualcuno entra e qualcun altro esce, il numero fatturato può risultare più alto di quello che si vede in quel momento a schermo, senza che nulla sia rotto. Confondere i due valori porta ad aprire ticket inutili.
La fattura mensile mette insieme gli utenti unici dell’enterprise, le eccedenze sui prodotti a consumo come Actions o Codespaces e gli eventuali add-on. Fra questi ci sono GitHub Copilot e i prodotti di sicurezza: attenzione al nome, perché la famiglia Advanced Security oggi è documentata come due prodotti distinti, GitHub Secret Protection e GitHub Code Security, con il proprio consumo mostrato nella pagina delle licenze. Sul fronte GHES, infine, il license file che sblocca l’istanza ha una data di scadenza e un seat count calcolato sul numero di licenze Cloud consumate: se scade, l’accesso via browser e via Git si ferma, mentre le command line utilities restano disponibili per il backup dei dati.
Perché il conteggio non torna
GitHub applica un unique-user licensing model: una persona consuma una sola licenza, indipendentemente da quante istanze GHES usa e da quante organizzazioni è membro. Il meccanismo che lo rende vero è la deduplica sugli indirizzi email associati agli account. Se lo stesso dipendente ha un’email su GHES e un’altra sul Cloud, GitHub vede due persone e il conteggio si gonfia.
Perché la deduplica avvenga bisogna sincronizzare l’uso delle licenze fra gli ambienti. Con GitHub Connect si attiva il license sync, che gira automaticamente su base settimanale e si può forzare da Settings > Licensing con Sync now; in alternativa si esporta il file JSON dall’istanza con Export license usage e lo si carica sul Cloud da Billing and licensing > Licensing > Add server usage. Vengono trasmessi soltanto gli user ID e gli indirizzi email degli account, non altri dati.
Il procedimento operativo, quando i numeri non tornano, è quindi: adottare i verified domains, esaminare l’elenco dei membri privi di un’email da dominio verificato, allineare gli indirizzi sugli account della stessa persona in tutti i deployment e — passaggio che quasi tutti dimenticano — verificare che un license sync sia effettivamente girato dopo la correzione. Finché non ne parte uno nuovo si continua a leggere un dato vecchio e a concludere, sbagliando, che la correzione non ha funzionato.
Monitorare consumo e spesa
Il punto di osservazione è Billing and licensing > Licensing, dove si leggono le licenze consumate e da cui si scarica il Download CSV report (il file arriva via email all’indirizzo predefinito dell’account). Il report sulle licenze GitHub Enterprise Cloud è lo strumento diagnostico serio: contiene login e profilo, gli enterprise server user IDs, il license type — comprese le Visual Studio subscription —, i ruoli in organizzazione e nell’enterprise, l’email da dominio verificato, lo username SAML, lo stato di invito in sospeso, la 2FA, il cost center e l’indicazione se l’utente ha una licenza attiva su GHE.com, campo prezioso negli scenari con data residency.
Per i prodotti a consumo si usa la vista Usage, con filtri, raggruppamenti e selezione del Time Frame, e si attribuisce la spesa alle business unit con i cost centers, che accettano utenti, repository, organizzazioni ed enterprise team ma valgono solo per il metered usage, non per la fatturazione a volume o subscription. Chi vuole automatizzare interroga gli endpoint REST di billing usage:
GET /enterprises/ENTERPRISE/settings/billing/usage/summaryServono il ruolo di enterprise owner o billing manager e un personal access token (classic), perché su questi endpoint i token fine-grained non sono supportati.