The Relicense-or-Archive Teardown: Upstream Change to Ranked Migration List

When an open-source project your buyers run in production relicenses or archives its free edition, some of those buyers have to pick a replacement. Most of that choice plays out over a few weeks of public issue threads. This guide is for founders, account executives, SDR leads, and partnerships teams who sell a compatible alternative, a managed fork, or migration services. It follows one real event, the MinIO Community Edition archive, from first notice to a ranked, dated account list. It shows the counts on record at each cut and the wrong turns that look like progress.

Which date opens the window: the notice, the archive, or the hard break?

For an archive, the evaluation window opens at the hard break, which is the day a pull or install fails. It does not open at the announcement. For a relicense, it opens at the first release under the new terms, because that is the version each account has to accept or refuse.

Two terms first. A forcing event is an upstream change that makes staying put cost something: a new license, an end to patches, or an end to distribution. A hard break is the point where an existing deployment stops working unless someone acts, for example when a registry deletes the images a cluster pulls.

MinIO is a useful case because the archive was not a relicense. The license moved from Apache 2.0 to AGPLv3 in May 2021, years before the archive. What followed was a slow withdrawal of the free edition, and each step was a separate forcing event.

A relicense runs differently. Redis announced its relicense on March 20, 2024, and the new terms took effect with 7.4 in July 2024, about 3.5 months later. A fork, Valkey, launched eight days after the announcement. Redis later added AGPLv3, starting with Redis 8 on May 1, 2025.

The point of the table: an archive has no release under new terms to anchor a deadline. The deadline has to come from something else, either an unpatched vulnerability or a broken pull. You will see claims that relicensing windows usually last 30 to 90 days. That is not established publicly, and the Redis case alone ran longer. Measure the window on your own event from thread dates, as shown below.

Even the archive date is disputed. Some sources say February 12 or 13, 2026. Others say April 25, 2026. One says both, with April as the permanent archive. The last push to minio/minio is dated April 24, 2026, and the dl.min.io CDN binaries were pulled in April 2026. Record every candidate date with its source, and don't treat any of them as your trigger.

Why does the dependents graph miss most production servers?

Public dependents data only covers public repositories and package ecosystems. A server like MinIO is deployed through container images, Helm values, and compose files, and no dependents index reads those. Use the graph as one input, not as the spine of the list.

The specifics:

• GitHub dependents list only other public repositories that depend on a repo or its packages. Private repositories are never reported.
• deps.dev indexes seven ecosystems: Cargo, Go, Maven, npm, NuGet, PyPI, and RubyGems. For Go, it only collects modules fetched through proxy.golang.org.
• Neither one indexes container images, Helm values, or compose files.

So for a server product, the dependents graph mostly returns SDK importers, meaning projects that import a client library such as minio-go. An SDK importer proves that someone writes code against an S3-compatible API. It doesn't prove they run the server, because the same client can point at AWS S3.

The first wrong turn comes even earlier. The only starting number anyone has published for MinIO is its stargazer count, 61,382. That number measures attention. It isn't a count of users, and none of it tells you which stars belong to companies running MinIO in production.

Nobody has established publicly what share of production users public data can find. You can check it locally. Take the customers you already know run the project and see how many of them show up in dependents data or code search. The share that doesn't show up is your blind-spot estimate for this event.

Which exposure evidence proves a production deployment?

The strongest public proof of production is a Helm values file that gives the server a persistent volume and pulls credentials from a secrets manager. An image pin proves the project is used. A compose file usually proves only development or testing.

Exposure evidence is a public artifact that ties an organisation to running the project. Each kind proves something different and misleads in a different way.

Examples from the MinIO case:

• bcit-tlu runs MinIO as a HelmRelease with a 30Gi Longhorn persistent volume claim and Vault-path secrets. That is production-grade evidence.
• RAGFlow's default docker-compose-base.yml pins quay.io/minio/minio:RELEASE.2025-06-13T11-33-47Z. That pin describes what RAGFlow's users run. It says nothing about RAGFlow's own infrastructure.
• One repo calls MinIO "the local S3-compatible test/dev dependency". Read the README before you grade a compose file.
• bitnamilegacy/minio pins get their own tag. Bitnami moved its versioned images to bitnamilegacy effective August 28, 2025, and those images receive no further updates. A bitnamilegacy pin is a frozen deployment by definition.

Terraform modules and job posts are plausible artifacts too, but I found no public evidence of either for this event. Search for them, but don't assume they exist.

"quay.io/minio/minio"
"minio/minio:RELEASE."
"image: minio/minio"
"bitnamilegacy/minio"
"minio" path:values.yaml persistence
"minio" path:docker-compose
"replace minio" is:issue is:open
"migrate from minio" is:issue

How do I find exposed companies whose repos are private?

Use people data. Professionals who list the project as a skill point to employers that run it, including companies whose repos never show up in public dependents. A profile gives you a lead to verify. It is not proof of a live deployment.

Private repos are the biggest structural blind spot in this job, and artifact search can't fill it. What can fill it is the people who operate the software.

How to read it:

• US to Germany is 2.5x in Refolk's index. If you sell into both markets, size the effort to match, and don't assume the US list is the whole market.
• Ceph to MinIO in the US is 3.6x. Many more people list the heavier self-hosted option. If you sell a Ceph-based replacement, the people who would run your product are easier to find than the people running the thing it replaces.
• The employer samples start your ICP cut early. Microsoft appears among US MinIO profiles and Amazon among Ceph profiles. Clouds will never buy a replacement from you, so drop them now instead of after you've researched them.

A skill listing proves that a person worked with the project at some point. It misleads when the skill came from a previous job, a side project, or a course. Before the row counts as exposed, confirm it against the employer's own artifacts, a current job post, or a public thread.

Refolk lets you ask for these people in plain English, with the exclusions written into the request. The private-repo gap then becomes a list you can verify one row at a time, not a guess.

The procedure, run on MinIO

The procedure has eight steps, and each one ends with a count written into the ledger. Published playbooks disagree on the order. One detects the change first and then pulls dependents. Another puts ICP fit and human review just before outreach. I do both, with ICP last so that clouds are counted rather than silently skipped. The research-desk time estimates are unverified: about an hour for dates, one to two hours for dependents, and half a day each for code search and owner resolution.

Nobody has published a filter-by-filter funnel for this event, so I can't give you dependents or code-search totals that you could check. The counts below are the ones that exist on record. The ledger template at the end of this section is where you write your own.

Step 1: the timeline and the trigger

The timeline is in the first section. The decision at this fork was which date to time against. I recorded February 12 and April 25, 2026 as candidate archive dates and didn't use either one. The primary trigger is September 11, 2026, when Docker Hub deleted the repos, and September 24, 2026, when anonymous quay.io pulls stopped, is the secondary. December 3, 2025 marks the small early wave.

Step 2: two wrong turns before any real data

Wrong turn one was starting from 61,382 stars. Throw that number out. Wrong turn two was treating the Go dependents of minio-go as operators. Put them on a separate SDK list and keep it only as a pool to cross-check: an SDK importer that also has a server image or chart in the same org moves up, and the rest stay out.

Step 3: artifacts sort accounts from channels

The RAGFlow pin was the tempting miss. It's a pinned server image in a widely used repo, but it lives in a shipped default compose file. RAGFlow is a channel, meaning a project whose users are exposed even if the project itself isn't an account. Note it for partnership outreach, not for the account list. bcit-tlu's HelmRelease with a persistent volume and Vault paths goes straight in. The ulams-dev pin of bitnamilegacy/minio:latest goes in tagged as frozen.

Step 4: owners

In the hand sample of 10 downstream threads, 3 owners are personal or homelab accounts: giocaizzi/rp5-homeserver, peakflames, and ruslancode23. The first one looks like a real deployment until you read the repo name, which describes a Raspberry Pi home server. Drop all three and count them. For ambiguous org handles, asking Refolk for the platform engineers at the company behind the org turns the handle into named people whose employer you can check.

Step 5: depth

bcit-tlu grades as production because it has a persistent volume and a secrets manager. dsx-ai-factory/model-streamer references MinIO in a devcontainer and CI, so it grades dev. ulams-dev stays ungraded until a second artifact shows where the frozen image runs.

Step 6: thread status

ruslancode23's PR merged on October 15, 2026, which makes it a closed account. It was already out as personal, but the check matters for org rows, because an open issue and a merged PR look the same in a search result list. suitenumerique/docs is trialling Versity, so it's deciding. michelangelo-ai and ragflow are undecided. bcit-tlu named SeaweedFS, so before you call it, check whether that change has merged.

Step 7: ICP

Remove cloud providers and storage vendors, which includes the Microsoft and Amazon rows from the index samples. Then a person reads the evidence URL on every remaining row. This is the step that catches a homelab with an organisation-style name.

Step 8: driver and call

bcit-tlu's HelmRelease rollbacks broke when Docker Hub deleted the images. That is a broken-pull driver, and if the thread is still open and the account fits your ICP, it's a reach-now. ulams-dev runs an image that gets no updates, against a release line with unpatched CVEs, so it's reach-now once depth is confirmed and time-it until then. dsx-ai-factory is dev-only, so it's time-it at best. One migration consultancy ranks internet-reachable instances at the front of the queue. I use that as the tiebreaker inside reach-now.

Event: <project> <relicense | archive>
Dates on record: notice ___ | last release ___ | archive ___ | hard break ___
Trigger used for timing: ___  (why: ___)

Stage                        In    Out   Dropped because
Raw dependents               ___   ___
  SDK importers set aside    ___   ___   client only, no server artifact
Artifact search hits         ___   ___   no evidence URL
Owners resolved              ___   ___   personal / homelab / channel
Depth graded                 ___   ___   dev or CI only
Thread status                ___   ___   already migrated (merged)
ICP fit + human review       ___   ___   cloud / storage vendor / off-segment
Final calls: reach-now ___ | time-it ___ | drop ___

Account row:
account | evidence URL | artifact | depth | status | stated target | driver | call | next date

What do the migration threads reveal about timing and targets?

Threads show when decisions happen and which replacement is winning. In the MinIO sample, most threads opened 13 to 38 days after the registry deletion, and SeaweedFS was the stated target in 5 of the 7 threads that named a committed replacement.

The rest of the sample: michelangelo-ai and ragflow (both undecided), ruslancode23 (SeaweedFS, personal, merged), and Open edX (Garage).

What this tells a seller:

• Timing. Freezes stay silent until something breaks. The archive caused almost no visible activity. The image deletion caused a wave. On your own event, find the cut-off that breaks running systems and expect the threads two to six weeks after it.
• Competition. Thread text is a free win-loss report. Where Garage was weighed and rejected, the reasons given were missing bucket policy and missing object versioning. If you sell a replacement, answer those objections before anyone raises them.
• Drop-in claims. RustFS shipped a drop-in replacement for MinIO data directories in 1.0.0-alpha.89. A data-format claim like that lowers the switching cost, and threads will cite it.
• Fork pull. The pgsty/minio fork passed 1,520 stars by April 2026. Stars measure attention here too, so look in the threads for actual fork adoption rather than counting stars.

How do I grade depth and make the reach-now, time-it, or drop call?

Put each account on two axes: how deep the deployment is, and how live its deadline driver is. Reach out now when both are high. Time it when the deployment is deep but nothing has broken yet. Drop accounts that are shallow with no driver.

A deadline driver is the specific event that forces an account to act by a date. For an archive there are three:

1. Unpatched CVE. Three CVEs affect the open-source line through its final release, and none will be patched there. NVD lists the affected range for CVE-2026-39414 as up to and including 2025-10-15T17-29-55Z, the final community release. The advisory lists only an AIStor-tagged release as patched.
2. Broken image pull. The Docker Hub deletion on September 11, 2026 broke HelmRelease rollbacks. Any account pinned to a deleted image is one rollback away from an incident.
3. AGPL exposure. The AGPLv3 license has been in place since May 2021. It drives a deadline only where an account's own policy restricts AGPL components, and you can't see that from outside. Treat it as the weakest of the three until a thread or a contact confirms it.

Each possible response commits the account to something different, and that decides what you can sell:

A frozen account is not a lost account. It is an account waiting for its next advisory.

New MinIO CVEs kept appearing after the final release: April 22, May 11, and September 25, 2026. Each one is a re-contact date for every time-it row on the list.

How this goes wrong: failure modes and false positives

Most bad migration lists fail the same way: they count attention, client code, or someone else's defaults as deployments, and they keep accounts that have already left. Each failure below comes with what it looks like and how to check for it.

1. Stargazers counted as users. Looks like: a list built from the 61,382 MinIO stars. Check: find a deployment artifact before you count anyone.
2. SDK importers counted as server operators. Looks like: Go dependents of minio-go treated as MinIO operators, when their client may point at AWS S3. Check: look for a server image or chart in the same org.
3. Homelab forks. Looks like: giocaizzi/rp5-homeserver, which has a real-looking image pin and a migration thread but is a Raspberry Pi home server. Check: the owner type and the repo name, before you spend any time on depth.
4. Shipped defaults mistaken for the owner's production. Looks like: RAGFlow's compose pin listed as a RAGFlow deployment. Check: whether the file ships to users. If it does, the project is a channel, not an account.
5. Public-only blind spot. Looks like: a list with no private-repo companies on it, presented as the whole market. Check: add job posts and profiles from Refolk's index, then confirm each one.
6. Clouds and vendors. Looks like: Amazon and Microsoft near the top because they show up in every sample. Check: exclude them at the ICP step and record the count.
7. Wrong trigger date. Looks like: outreach timed to the archive, which misses the larger wave that followed the September 2026 image deletion. Check: plot your thread dates against every cut-off on the timeline.
8. Already-migrated rows left in. Looks like: ruslancode23, whose PR merged on October 15, still sitting in the queue. Check: whether the PR merged or the issue is only open, and recheck before every send.

The two most expensive of these are 4 and 8. A channel mistaken for an account puts a pitch in front of a maintainer who has nothing to buy. A migrated account that gets a pitch learns you didn't read the thread they wrote.

How do I keep the list current after the first pass?

Re-run the cheap checks on a schedule and let upstream events set the re-contact dates. Thread status, new advisories, and registry changes each move rows between reach-now, time-it, and drop.

Triggers to watch:

• New advisories against the final community release. Each one turns frozen deep deployments into reach-now.
• Registry and CDN changes, such as the quay.io cut-off coming 13 days after the Docker Hub deletion. Each new cut-off can start a fresh wave of threads.
• Thread state. A deciding thread that names a target or merges a PR changes the call that day.
• Fork and replacement releases, such as a drop-in data-directory claim. These lower switching costs and pull timed accounts forward.

Keep the ledger with the list. When someone asks why an account is ranked where it is, the answer should be one evidence URL, one driver, and one date.