Really it depends on what definition you give to the terminology. There's probably a lot of different definitions out there.
I think the following are nice explanations based on what I believe this terminology refers to:
Deterministic Library
A deterministic library holds functions that are deterministic based on either a) function input or b) state that is somehow maintained across function calls.
Should logic be dependency-injected into a deterministic library, such logic must conform to a concrete specification such that the output of the library is not affected.
Example: A collision-detection library which for some reason depends on a sorting function to aid in these calculations. This sorting function can be configured for optimization purposes (e.g. through dependency-injection, compile-time linkage, etc), but must always conform to the same input/output mapping, so that the library itself remains deterministic.
Indeterministic Library
An indeterministic library can hold indeterministic functions by communicating with other external indeterministic libraries that it somehow gained access to.
I generally refer to indeterministic libraries as services.
Example: A poker library which depends on a random-number generator service for shuffling the deck. This is probably a bad example, because, for architectural purposes, we should push the indeterministic aspect of this library to the outside. The poker library could instead become deterministic and unit-testable by taking in a pre-shuffled deck of cards, and it's now the responsibility of the user of this library to shuffle the deck randomly if they so wish.
Framework
A framework is in-between a deterministic and indeterministic library.
Any logic that is dependency-injected into a framework must be deterministic for the lifetime of that function instance, but different function instances of varying logic can be injected on separate executions of framework functions.
Example: Functions that operate on lists such as map, filter, sort, reduce, that expect to take in functions that are deterministic but can have varying logic for different executions. Note that this requirement only exists if these list operations advertise themselves as deterministic. In most languages, list operations wouldn't have this constraint. The core logic of such frameworks are deterministic, but are allowed to accept indeterministic logic at the risk of the user. This is generally a messy scenario to deal with, because output can vary widely due to implementation details of the framework.