"1. the ability to use the software for any purpose, any field of endeavor, with no discrimination, for any business model. By your own admission, your license would be incompatible with such a contract."
I said they could use, fix, or extend it with new versions shared with paying customers. I don't see how I've admitted it would be limited to anything you stated. The only limit is you have to pay to use it unless a free license was granted. Now let's move onto other points as you had some interesting ones.
"you say you'd allow "fixes" and "local extensions", yet restrict redistribution to paying customers, but well, you clearly have boundaries in mind for derivate works, as you clearly only want to allow small improvements."
The boundary is more clear than it appears: if the code is in your product or service, you are paying a license for it. That simple. You can always clean-slate an implementation of whatever subset of the features you need if that's too much. I should modify it to say the API can be used in compatible clones given Oracle's activities.
"Can those improvements be redistributed as source code, for the benefit of others?"
Yes. The software itself is distributed as source code with optional binaries for convenience. Any paying customer can receive it in this model.
"For example what happens if these clients hire contractors to provide those improvements?"
Then contractors provided the improvements. The user is still a paying customer. What's your question?
" first of all, what's a "paying customer"? Do money need to exchange hands?"
A paying customer is almost always formed in business by one party giving another money in exchange for some good. So, a paying customer is... someone who pays.
"Are trial versions permitted?"
Didn't think about that. Shareware was a big thing... a good thing... back when I started in computers. Gave us a taste of what the software was like with little to no money. I'd consider doing a trial period so long as the software was for a long-term, use case. With one-offs, they could just use the trial software. If no trial, then getting good reviews and a sales team would be solution like with most profitable software.
"First of all, this implies that ownership over such software is achieved by anybody that wants it. And it's an important right, especially if things go wrong."
Last I checked, the copyright situation for ownership of OSS software was more complicated than that. Has a lot to do with whether copyright was assigned by a contributor or something. Way better than proprietary situation with hardly anyone going after forks in practice. I give you that much.
"Oh well, what is abandonment?"
I thought you'd say that but don't have a good answer yet. As I wrote it, I remembered the record labels and others that do one minor thing with the copyright just to maintain it. Last time I thought through this, I figured the contract could be amount of developer time that goes into adding features, adding documentation, or fixing bugs. Project is abandonware if it goes under a certain amount for a certain period of time. Idea being owner is incentivized to keep improving it or drop it when investments no longer make sense. As others have stated, one can still charge for it even if it's free. There's many companies that do. So, money will come in at lower rates over time for any given project.
"You could also steer the project in a direction that people don't want, you could intentionally cripple it, you could raise prices so much as to make it unfordable and when you get bored of it, you could simply sell it to another company."
Prior discussion dealt with the selling part. I speculated these kind of deals would be best in nonprofits, public benefit companies, and so on whose charter maintained fair pricing, no acquisitions (or GPL on acquisition), perpetual licenses for each shared-source version (to avoid crippling), etc. I'm still wondering how much can be handled at that level. Far as steer in bad direction, that's a possibility that OSS has an advantage on. So, trust in the team is a pre-requisite for this model to work if you're worried about that. It's also a risk in FOSS in practice, though, given most software accumulating crud doesn't get forked, forks can break things in one way to improve in another, and forks might need critical mass of contributors to develop at similar pace. They're harder in practice than just pushing a fork button.
"our product can survive and flourish as proprietary, but stop with the bullshit and call a spade a spade."
Who is bullshitting? I'm calling it shared-source, paid software with certain benefits similar to OSS. I've also found tricks for approximating new advantages or dealing with new problems as you bring them up. I can't call a spade a spade if it's not a spade. I think OSS vs proprietary isn't a spectrum of benefits and tradeoffs instead of binary decision. So, I'm investigating new models. Definitely not saying they equal open-source: just can have many of same benefits for a proprietary product.