Problems

We should have a clear statement and description of the problems for freedom that network services introduce along with examples, classifications, and necessary context.

Undisputed

 * Copyright holders don't know about AGPLv3
 * Developers have no clear set of best practices for making "free" services
 * Public frequently using services that don't preserve their freedom

Disputed
It's really great that pepole are sharing this information.

Public

 * Generally, users of software as a service have a particularly difficult time gaining the freedom to copy, distribute, or study code. In short, their autonomy is compromised.
 * Users of some critical civic applications (like software running voting machines) have no way to study the code - undermining basic principles of democracy. [While this is a problem, is it really a service-related problem? It seems like the scope of our problem is big enough without expanding it to include embedded systems like voting systems. I'd assumed our focus was on web services. Ditto next statement. --LuisVilla]
 * Agree with Luis
 * As software becomes used in nanotechnology (like health applications), the four freedoms will likely become more and more important in areas that are not generally seen today as domains for software
 * Agree with Luis
 * An otherwise Free service could require a non-Free client, eg if the service renders media or UI such as patent-encumbered formats and Flash. One way to think of the solution is that everything required to deploy and use a Free service should be DFSG compliant. For a Free serivce that is a website, this means the code and data on the server and the code required to interact with the service on the client.

Deployers
These are included kind of for completeness; it's nice (and practical, if we want any adoption to happen) to include the interests all parties in our discussion.
 * "Free" and "open" have different meanings for service deployers. "Free" has come to mean "gratis", and "open" just means "anyone can use it (even if it may requires payment)".
 * Again, is this at all unique to services?
 * AGPL is effectively a Lesser/Library license, in that it provides no mechanism for free-software-oriented deployers to ensure that consumers of networked APIs are themselves open if they so desire.
 * In that case the GPL is a lesser license in that IPC does not necessarily trigger copyleft. Attempting to legally mandate what runs on a client machine (private, not offering services to the public) seems antisocial, if not leading to treachery, and as a practical matter, very few users.
 * We've always taken the position that client software is almost never a derivative work of server software. AGPL *can't* reach the client software unless that position is changed.  Changing that position would be difficult.
 * Typically free software requirements have stopped at the door of one's computer; it's nobody else's business what I do with my own software on my own server(s). Requirements on deployers will definitely give the appearance of being intrusive and asking too much.
 * Education/evangelism problem.
 * Custom software, like for a Web service, often has lots of glue code, twiddles, dependencies and hacks. These aren't often documented internally, much less ready for distribution to the world as Free Software.
 * This is also a leading excuse for not releasing non-networked code under a Free license. Embrace good software engineering practices. Make it easy for users to deploy services from revision control with a vendor branch and republish changes from their revision control system.