But most SaaS companies don’t make protocols, they make web applications. So I’m not really sure what’s implied by these trivial-to-implement protocols. Having a functional and well documented API isn’t a protocol. An open protocol would be more like a situation where any vendor could implement an “iCloud service”, and any “iCloud client” could connect to any vendors service.
I don’t agree here. A web application API, properly documented and exposed to any client a participant wants to use becomes a protocol for that service, there’s no difference between CalDAV and the Google Calendar web app’s API except that one is documented, rarely changes, and if offer by a service provider would generally allow any client that implements it to connect, and the other is undocumented and it’s probably against the terms of service to build your own clients. The goal should be to force every API for these providers to meet some minimal definition of a protocol, not to define government mandated standard protocols or force interoperability between services.
Your definition removes all distinction between the concept of a protocol, and the concept of an API. Google Calendar doesn't implement the Google Calendar Protocol, there is no standards body involved in determining how Google Calendar works, you're not free to go an implement your own Google Calendar compatible service, and Google can change Google Calendar without consultation with anybody. There is no definition of protocol where a single-service API, designed, implemented and published by a single party is a protocol. Google Calendar implements an API.
If your argument is that companies should be compelled to publish good API documentation, and allow any client to connect to them, then aside from creating a completely unnecessary system of regulatory moats, and aside from using the wrong words to describe this idea, you're likely to run directly into a 1A violation.
