Why Fluxora isn't open-source

licensing product

Fluxora used to be MIT-licensed. As of 20 May 2026 it isn't — the source repository is closed and the binary is governed by an EULA. A day later, on 21 May 2026, I locked in the other half of the model: a Fluxora server now signs into a Fluxora account at first launch, then runs on a 30-day cached licence after that. I'd rather tell you both of those out loud, in one place, than have somebody piece the wrong story together from a changelog. This is the right version.

What actually changed

Two things, one week apart. First, the LICENSE file flipped from MIT to a proprietary, all-rights-reserved licence; the public showcase repository was rebuilt from a small allow-list of marketing files and the rest of the source is now confidential to me. Second, the runtime got a cloud-attached front door: to activate a Fluxora server you now sign into a Fluxora account (email and password; email verification required; two-factor optional and actively recommended), and the server caches your tier locally for the next 30 days. The binaries you install on your hardware — server, desktop control panel, mobile clients — are governed by the new EULA; the surrounding service surface is covered by the rewritten Terms of Service.

What did not change: the Free tier is still free, the download is still free, the desktop and mobile clients are still free to install on any number of devices, and your media still lives on your hardware. LAN streaming, internet streaming, transcoding, pairing, playback — none of that ever touches my infrastructure.

Why it's closed-source

Six weeks of public-repo metrics: zero stars, zero forks, zero clones, zero issues, zero discussion posts. That isn't a tragedy — Jellyfin has a four-year head start, a real community, and an excellent product. The honest read is that nobody was using the source. Open-sourcing it was a side-bet on top of a product designed from day one to be paid; the side-bet didn't pay off, and keeping it in place was costing optionality I'd rather preserve.

There's also solo-maintainer math. Running an open-source community — triaging issues, reviewing PRs, writing contributor docs, moderating discussions — and shipping a paid product people trust enough to swipe a card for are both real jobs, and they can't both come out of one person's weekly budget without one of them quietly starving. I'd rather pick one and do it properly than do both badly. I picked the product.

Why it's cloud-attached now

The original plan was a self-validating HMAC licence key — paste it into the server, the binary checks the signature locally, no phone-home ever. That model is elegant on the day you ship and slowly painful afterwards. There is no way to revoke a leaked key. There is no way to push a tier change without a binary rebuild. There is no way to notice that the same key has been quietly running on six unrelated servers for a year. And the fraud-mitigation lever is "rotate the signing secret in the next release," which punishes legitimate paying customers more than it punishes whoever leaked the key.

The cloud-attached account model fixes those four things at once. If an account misbehaves I can revoke it in days, not in some five-year cert expiry window. If you upgrade from Plus to Pro mid-subscription, the change propagates on the next refresh — no re-issue, no re-paste, no "ah, can you uninstall and reinstall." If a complaint about a specific account lands in the inbox I can act on it through the right lever (the account) instead of a release cycle. And if someone runs the same account on two unrelated servers in two different countries, I can see that, ask politely, and escalate only if asked is ignored.

The thing I deliberately did not copy is Plex's model. Plex signs you in every launch and gates every play. Fluxora signs you in once. After activation the server holds a cached tier record that's authoritative locally for the next 30 days; every successful monthly check-in rolls that window forward. A normal home with monthly internet will never notice the cloud is there. A server that goes offline for a fortnight will not even blink. A server that goes offline for more than a month reverts to the Free tier on the next start and is one sign-in away from being back at full tier.

What the trust trade actually is

Source visibility is the obvious thing I'm taking off the table, and I'm not going to pretend that's nothing. For a self-hosted product the source has historically been the trust artefact, and removing it shifts that load somewhere else. Here's where it shifts to: behaviour, fully enumerated, packet-verifiable.

The commitment is no silent phone-home, not no network at all. The legitimate calls the binary makes are all written down in EULA §5.4: TMDB metadata with your own API key, your own Cloudflare Tunnel if you set one up, opt-in Sentry, the Polar handshakes for paid-tier activation and lost-key recovery, the Firebase Auth refresh that keeps your session alive, the Firestore read that returns your current tier, and an optional Firebase Remote Config fetch that tells the server a new release exists (opt-out under Settings → Updates). That's the whole list. If you point Wireshark at the binary and see something else, that's a bug, not a policy — please tell me.

The trust artefact stops being "read a couple hundred thousand lines of Python and Dart and convince yourself nothing is fishy" and starts being "run tcpdump for an evening and confirm the documented list is the actual list." Narrower, more concrete, easier to actually test.

What about continuity if I disappear

This is the part where the architecture used to overpromise and now tells you the truth. The earlier framing said the binary would "keep working indefinitely under your existing key" if the project disappeared — which was technically correct under the HMAC model and rested on a single critical assumption (the signing secret had to live in the binary, which is fragile). The cloud-attached model trades that promise for a smaller, more honest one.

If I disappear tomorrow, every paying customer keeps full paid-tier features for up to 30 days — the remaining TTL on the most-recently-refreshed cached tier record. After that window expires, the server reverts to the Free tier and keeps running indefinitely on your hardware. Recurring charges stop. No remote kill switch ever reaches into a running server within its cache window — that's preserved as a structural property in EULA §7.4 and TERMS §13, not as a marketing line.

I'm being explicit about the trade because it's a real one. Lifetime Ultimate purchasers in particular need to know: your binary stays yours forever, but the paid-tier features need an internet connection at least once every 30 days to stay refreshed. If you spend three months on a boat without internet, your server will be in Free-tier mode when you get back, and signing in once will restore it. The justification for accepting that trade is the same as the justification for going cloud-attached at all — tighter revocation control, faster fraud-detection cycles, a simpler product to support.

What you pay for

The pricing model is unchanged and stays deliberately simple. One account, one server, unlimited paired devices in your household. You pay for concurrent streams, not for seats. Free is genuinely free; Plus, Pro, and Ultimate unlock internet streaming over WebRTC, hardware-accelerated transcoding, and progressively higher concurrent-stream caps. The exact numbers live on the pricing section; the rules live in TERMS §5.2.

Your account is the licence holder. There is no "paste your licence key here" UI anywhere; the server already knows what tier you're on when you sign in. The account is only the licence holder — your media stays on your hardware, your library stays on your hardware, your playback history stays on your hardware. The cloud knows your email, your tier, and which server you activated against. That's all.

Reversibility, one more time

Closed → open is always reversible: I can release the source under any licence I want, any time I want. Open → closed isn't reversible the same way — anyone who cloned an MIT-era snapshot keeps those rights to that snapshot forever, which is fine and correct, but the future work doesn't carry that licence forward.

Cloud-attached → fully-offline is reversible the same way. If, two years from now, the cached-tier window is causing more friction than the revocation lever is worth, I can simplify back to a longer-lived offline credential and bake the existing fraud-mitigation lessons in from day one. Doing it the other way around — shipping fully-offline first, then trying to bolt revocation on later — would have meant retrofitting the harder thing under pressure. I'd rather start narrow, ship the product properly, and re-evaluate from a position where there's actually something to evaluate.

Thanks for reading. If you spot something in here that doesn't match the EULA or the Terms, that's a bug — please tell me.

Have a question or pushback? Open a GitHub Discussion, or email marshalgcom@gmail.com. Back to all posts.