The first section 1.1 through 1.5 is roughly what the EU law would have you do anyway, 1.6 is a good way to tell your users that you don't intend to use the service as a pre-text to harvest more data on them than you need.
The second part has some issues that would come up in an acquisition, but think about it, if you are placing the wants and needs of an acquirer ahead of those of your users then you should have never started that company to begin with, after all, it is more than likely that your users are what gave you the platform to get the acquirer interested.
A 'pure' team acquisition that kills the product post acquisition is about as bad as it gets from a user point of view and if you intend to do that then maybe you should clarify that up-front instead of when it is two minutes to twelve.
Killing off APIs willy nilly is a very bad nono imo, you basically create an avalanche of fall-out the consequences of which are probably hard to envision, especially if your API becomes important enough that people will start to build commercial services around it.
I think you are being unrealistic about acquisition. I hear way too many discussions on HN about monetizing your products, and people looking for their big exit/payday. People are not going to give up their exit plan because of an idealistic "code of ethics" for their users.
I think we all speak for ourselves here. Maybe it is true that not many companies would require an acquirer to continue to run the service as it was at the moment of acquisition (or better!), but I think those that do want to make such a commitment to their end users should get a leg up.
If someone offered to buy out the sites that I run in order to shut them down I would refuse.
Actually I think it would be cool to ask ~10 big acquirers, both of talent and of products/tech, to see how they'd feel about deals with these terms.
Google seemed ok with Etherpad running in parallel for a while. The concerns seem to be:
* Acq wants to be able to develop their own products with the tech, less competition -- shutting off system supports that, but so does disabling new account creation on it, and making your own product superior. Some changes seem ok, some seem borderline (flickr -> yahoo login), but just shutting down a service is different.
* Wanting full resources of the team -- running the old site on autopilot
* If the old service is inherently unsustainable (patent/IP issues, negative marginal income, ...); the former might be a big deal (although YouTube won by having the Google lawhammer on their side), and the latter might not be a big deal if the absolute dollar value involved is low relative to the deal.
Even if a deal ends up being 5% less due to the requirement that the service stay operating after acq, if it makes user acq easier so you get 2x more users and thus a 2-10x higher valuation, it's win/win/win/win (acq, founders, investors, users).
in the early stage you are required to build extra features....and in the later stage you are requiring the acquirer to agree to this