Storage outlives the companies that sell it. That makes licensing a durability question, not a legal one — and it deserves the same scrutiny you give erasure coding and failure domains.
Storage evaluations are thorough about the things that are easy to measure. Throughput under load. Rebuild time with a failed drive. Erasure coding overhead. Small-object performance. S3 API coverage. All of it matters, and all of it is testable in a lab in an afternoon.
Then the platform gets bought, and the data goes in, and it stays there for a decade. Storage is the stickiest layer in the stack — you can swap an orchestrator in a quarter and a monitoring system in a weekend, but migrating a petabyte of objects with their metadata, their retention state, and their application integrations intact is a multi-year program with its own budget line.
So the question that actually determines whether a platform was a good decision is not on the bake-off scorecard. Will the thing you are buying still exist, on the terms you bought it, when you are still using it?
Licensing is not a legal footnote. On a ten-year horizon it is a durability characteristic.
There is a well-documented sequence in open-core infrastructure, and it has repeated often enough to be predictable rather than surprising.
A project launches under a permissive license. It is genuinely good and genuinely free, and it builds an audience on that basis — production deployments, tutorials, Stack Overflow answers, a generation of engineers who reach for it by reflex. Adoption becomes the moat. Then, once the switching cost is high enough to be load-bearing, the license changes, or the features move, or the binaries stop shipping.
None of these companies did anything unlawful, and in most cases the commercial reasoning was sound. Engineering has to be paid for, and cloud providers monetizing someone else's work without contributing back is a real problem that these licenses were written to address. The pattern is not a morality tale.
But each of these changes landed on organizations that had made a long-horizon decision using information that turned out to have a shelf life. That is the part worth learning from.
Two things are worth noting about that last sequence. First, it took roughly nine months from the console removal to the repository being archived — fast, by infrastructure standards. Second, the code is still there and still AGPL. Nothing was taken back. What ended was the maintenance, the binaries, the documentation, and the assumption that someone else was going to keep it working.
That distinction matters, because it is the one people get wrong. The risk in open-core is rarely that your license is revoked. It is that you become the maintainer of a petabyte-scale storage platform without having budgeted for it.
The shift is usually visible a year or more before it is announced, if you know where to look. None of these is conclusive on its own. Two or three together is a pattern.
Not "Enterprise Edition" — a distinct product identity with its own website and its own roadmap. Shared branding implies shared destiny. Separate branding is how you decouple them before you diverge them.
Links from community docs land on commercial pages. Feature documentation quietly acquires an edition qualifier. The docs are usually the first artifact to reflect the new strategy, because they are the cheapest thing to change.
Commit velocity on the open repository drops while the company's engineering headcount grows. Issues stay open longer. Pull requests sit. The work did not stop; it moved.
Build-it-yourself replaces a download link. Container images move or lag. This filters out casual production use without any licensing change at all — and it is far less visible than a relicense.
New paid features are normal and fair. Removing something that already shipped is a different act, and it tells you the priority is conversion rather than differentiation.
Ask directly whether the open edition is production-supported and what the commitment period is. A clear answer is a good sign regardless of what it says. Ambiguity is the finding.
This is not an argument against open source, and it is certainly not an argument for assuming proprietary vendors are safer — they get acquired, sunset product lines and discontinue platforms on the same ten-year horizon, sometimes with less warning and no source code at the end of it. The point is that longevity is a property you can evaluate, and almost nobody does.
Ask the question at evaluation time, when it costs an afternoon. It costs considerably more later.
It is not a case that any of these vendors acted in bad faith. Companies are entitled to change their licensing, and several of these changes were a rational response to genuine free-riding.
It is also not a case for buying proprietary instead. Commercial platforms carry the same ten-year risk in a different shape — acquisition, end-of-life, forced migration to a successor product — and when a proprietary vendor exits, you do not even have the source.
What it is: an argument that the license and the governance model belong on the evaluation scorecard next to the throughput numbers, weighted for the actual lifespan of the data. If you are committing to keep something for a decade, spend an afternoon asking who will be maintaining it in year seven, and what you will do if the answer turns out to be you.
Evidence over reputation — in both directions. The vendor with the best story is not automatically the safest choice, and the vendor with the worst quarter is not automatically finished. Look at what has actually happened, and at what is actually written down.