> "A different case is when the program talks across a network with > a server running on another machine, and the server is proprietary or > has an unknown license; unless the two pieces of software make a > single program (for example because they exchange complex data > structures intimately), the client does not really depend on the server. > In such scenario the user is not required to install nor run any > proprietary software on per computer, so there's no dependency of > the client on the server, even if the server's responses are needed for > the program's main functionalities; said client program is therefore > eligible for hosting."
This can become dangerous: the free software ecosystem may begin to depend on software that talks with proprietary servers with no documentation about how they work, other than the properly licensed free source code. That is why we avoid using the term "ecosystem" (http://www.gnu.org/philosophy/words-to-avoid.html#Ecosystem) -- software doesn't become able to talk to other software by osmosis, we as programmers must take care so that our software always respsects the users freedom. This may become more difficult if the proprietary server API changes quickly, nearly every day. This becomes a problem: while it does not force the users to run proprietary software, their existing free clients for this server may break easily, and not all maintainers will be able to resolve this quickly. That software changes is not an issue of ethics for, this can occur with free software too. Does this seem similar to "service as software substitute"? How to quantify this or what barriers would need to be added? I do not see what the similarity is, just talking over a network (no matter the complexity of a protocol) doesn't automatically make something a SaSS -- what happens on the other side is what makes SaSS.