While I've never seen it defined this way, I think the distinction comes down to this:
An engine deals with assets in depth, and exposes runtime abstractions to them.
A framework does what is necessary to expose I/O and load the assets, but aims to be minimally opinionated about how they integrate into the application.
For example, in an engine you might have abstractions for applying collision, physics, and rendering techniques onto an image asset, so that you can achieve a useful result just by configuring the data correctly. A framework would give you a way to load the image and display it, but leave it to you to add more detailed behaviors by writing new code.
In effect, engines are never totally done until you have a feature-complete application. Often it works out that you need a scripting layer to define a certain kind of asset(e.g. dialogue tree logic), and then what you have is an engine extension; if the asset is defined independently of the scripting system, it can be made portable to another engine.
An engine deals with assets in depth, and exposes runtime abstractions to them.
A framework does what is necessary to expose I/O and load the assets, but aims to be minimally opinionated about how they integrate into the application.
For example, in an engine you might have abstractions for applying collision, physics, and rendering techniques onto an image asset, so that you can achieve a useful result just by configuring the data correctly. A framework would give you a way to load the image and display it, but leave it to you to add more detailed behaviors by writing new code.
In effect, engines are never totally done until you have a feature-complete application. Often it works out that you need a scripting layer to define a certain kind of asset(e.g. dialogue tree logic), and then what you have is an engine extension; if the asset is defined independently of the scripting system, it can be made portable to another engine.