PredictionIO licence cost: free under Apache 2.0, and retired

Most pages in this series ask what a licence costs after an acquisition. This one has the shortest honest answer in the set: nothing, before the acquisition, during it, and now. PredictionIO was open source software that Salesforce bought a team for, and the software stayed open source. There is no seat, no edition and no renewal to negotiate.

That does not make the question pointless. A free licence on a retired machine learning server still has a cost, and a team that inherited a PredictionIO deployment will meet it in infrastructure bills, in the hours spent keeping an unmaintained stack alive, and in the project to replace it. This page separates those costs, shows what each is made of, and prices the replacement paths that have published rates.

#What the licence actually says

PredictionIO is released under the Apache License, Version 2.0, a fact the Apache project's own pages state at the foot of every page. The relevant grant reads: "Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form."

In plain terms, you may use, change, copy and redistribute the software, including inside a commercial product, without paying anyone. The same licence says the software is provided without warranties, which matters for the cost discussion further on, because it means nobody owes you a fix. The licence also carries a patent grant and some conditions about keeping notices intact, and your legal team should read those, but nothing in it creates a fee.

So if a proposal, a spreadsheet or a colleague lists a PredictionIO licence line with a dollar figure, remove it. The right entry is zero, with a note on which licence applies and when you checked.

#What Salesforce did and did not do

Salesforce announced the acquisition in February 2016. The report on the deal included one sentence that answers most licence questions: "PredictionIO’s tech will remain open source and free to use, while the team works on evolving the project into a self-sustaining community." It also reported that Salesforce intended to put the technology to work inside its own machine learning capabilities, specifically SalesforceIQ, which has itself since been retired.

On whether a commercial version would follow, the same report was candid: "There is no word on whether Salesforce will plan to develop and support a paid enterprise edition of the product down the line." That uncertainty was never resolved into a product. There is no PredictionIO edition on any Salesforce price list, no add-on and no migration offer. The software went one way, as a community project under Apache, and the team went another, into Salesforce's own work.

For the deal story, see what happened to PredictionIO. For how a model server connects to a CRM, integrating PredictionIO with Salesforce is the place, and should you migrate from PredictionIO is for anyone running it. The wider history is on PredictionIO and Salesforce.

#Retirement changes the cost

Apache's own Attic page gives the dates: "PredictionIO became a Top Level Project in October 2017, retired in September 2020 and the move to the Attic was completed in April 2021." The project's documentation site opens with a notice saying the project has retired.

Retirement means the volunteer community that wrote, tested and patched the software has stopped. For a team running it in production, that turns a free licence into an open-ended obligation. Dependencies age, the components in the bundle keep shipping their own releases while PredictionIO's own code does not, and nobody is on the other end of a bug report. The Attic page lists the project's resources, including the source repository and mailing lists, under a read-only heading.

Apache does not forbid carrying on. The Attic page says: "As with any project in the Attic - if you should choose to fork outside of Apache, please let us know so we can link to your project." A fork is permitted by the licence, but it makes you the maintainer, and the cost of that is the cost of staff who understand a Scala-based machine learning framework well enough to patch it.

#What running it really costs

The documentation describes the full installation as a stack: "Apache PredictionIO® can be installed as a full machine learning stack, bundled with Apache Spark, MLlib, HBase, Akka HTTP and Elasticsearch, which simplifies and accelerates scalable machine learning infrastructure management." Each of those components is a service to provision, monitor, secure and upgrade, and each has its own release cycle that has moved on since 2020.

No source gives a price for running it, and this page will not invent one. What can be said is which lines make up the bill, so you can ask your own team to fill them in from their invoices.

The first line is the only one that is free. The last is the one that arrives eventually, and the other three tell you how urgently.

#What replaces it on a Salesforce price list

Most readers in this position are asking one of two questions: how do we get predictions into Salesforce, and how do we stop running our own model server. Salesforce publishes rates for the paths it sells.

If your PredictionIO use was lead, opportunity or forecast scoring for sellers, look first at the scoring features inside Sales Cloud editions. The Sales Cloud pricing page lists lead scoring, opportunity scoring and predictive forecasting among its features, with Core at $195 per user per month, Advanced at $395 and Max at $550, billed annually, as at 11 October 2026. That route replaces a custom model with a packaged one, so it suits cases where your needs are standard and you do not need to own the model.

If your use was a bespoke model fed by data from several systems, the platform path is Data 360. Salesforce says on its Data 360 pricing page: "Salesforce customers can provision Data 360 for free with a limited amount of storage and consumption credits." Beyond that allowance, consumption is bought in Flex Credits at $500 per 100,000, or through profile-based pricing, and the page says Data 360 and Agentforce can share Flex Credits. Credits are metered by action, so the cost depends on how much data you process and how often, which you can only estimate from your own volumes.

A third path is to move the model to a general machine learning service from a cloud provider and call it from Salesforce. That is a legitimate choice, and this page does not price it, because its rates belong to the provider and change often.

#Taking stock before you decide

Whichever way you go, start with an inventory, because most of the cost of replacing a model server is discovering what depends on it. The project's own documentation describes two interfaces that will help you find the dependencies. Data goes in through an event server, reached over a REST interface or one of the client libraries, and predictions come out of a deployed engine that runs as a web service, with batch prediction available as an alternative. Each of those is a place to look.

List every system that sends events to the event server, since each is a data feed you will need to reproduce. List every caller of the engine's query endpoint, since each is a consumer you will need to repoint. Then list the engines themselves, noting what each predicts, how often it is retrained, who owns the business outcome, and when somebody last checked its accuracy. In many deployments the last answer is a surprise, and a model nobody has measured for two years is a good candidate for retirement rather than replacement.

Finally, capture a baseline. Save a sample of recent inputs with the scores the current engine returned. Any replacement, whether a packaged scoring feature or a rebuilt model, can then be run against the same inputs, and the differences discussed before anything goes live. That sample costs an afternoon and saves weeks of argument.

#What a sensible timeline looks like

No source gives a standard duration, so treat this as a shape rather than a promise. Inventory and baseline come first and are usually the quickest. A decision between packaged scoring and a custom build follows, and it deserves a short pilot because it commits you to a pricing model. The build or configuration comes next, followed by a parallel run in which old and new scores are produced side by side and compared. Cut-over happens when the comparison is understood, not when it is perfect, and the old cluster is switched off on a date agreed in advance.

Plan the shutdown as carefully as the start. Keep a snapshot of the event data and the trained models for a defined period, in case someone asks why a score changed. Then delete them on schedule, since an archive of customer behaviour is a liability as well as a record.

#Choosing between them

A short test sorts most cases. If a packaged score already answers your business question, buy the seat edition and retire the server. If your question needs your own features and history, plan on Data 360 and a modelling approach, and size the credits from a pilot. If the model is small, stable and the only consumer, the cheapest answer may be to freeze it as a batch job and run it on modest infrastructure until a replacement is ready, with a firm retirement date.

Whichever you choose, put a date on it. A retired project does not get safer with age, and the longer a deployment runs, the more expensive the eventual move becomes, because the people who built it leave and the documentation drifts from reality.

#Comparing offers from partners

When a partner proposes a replacement, ask them to show the licence and the build as separate numbers. The licence is the published rate for the edition or credits, which you can verify yourself on the pages linked above. The build is a services estimate for porting the model, rebuilding features, integrating the output and testing it against the old results.

Ask what they will do to prove the replacement matches the old behaviour, because a model that scores differently changes who gets called first, and your sales team will notice before you do. Ask who owns the model afterwards, where it lives, and what it costs to run each month once the project ends. Ask what exit looks like, so you do not trade one unmaintained dependency for another.

#Who should act first

Not every deployment is equally urgent. The ones to move first are those that feed decisions about customers or revenue, such as which lead is called, which account is flagged or which offer is shown, because an unnoticed fault there has a direct commercial cost. Next come deployments that sit on a network where outsiders can reach the event server or the engine endpoint, since an unmaintained service facing the internet is the highest security exposure. The ones that can wait are internal, low-stakes experiments that nobody has opened for a year, and for those the cheapest action may simply be to switch them off and see who complains.

Give each deployment an owner and a date, and report the list to whoever signs off risk. A short, dated list tends to get funded, where a general worry about legacy systems does not.

#A note for procurement

Record four facts. The licence is Apache 2.0 and carries no fee. The project retired in September 2020. Salesforce has never listed a PredictionIO product or price. The current cost is whatever your cluster and your team cost to keep running, and the replacement is priced on the Salesforce lists linked above, to be confirmed in a quote.

Everything else is a number only your own invoices can supply. Pull them before the next planning round, and the decision usually makes itself.