Make sure to read the disclaimers about this page at FreeOpenServicesDefinition. Note that not everyone agrees that source code is necessary, see, e.g., http://www.oreillynet.com/onlamp/blog/2007/08/i_dont_care_about_googles_sour_1.html

• server source code access spans:
  • source not available
  • source available, but with dependency on proprietary technology or techniques
  • source available, including all dependencies (alternately: full source available for an equivalent technology, e.g., for a POP client but not gmail or for Xen but not Amazon EC2.)
  • source available under FSF/OSI-approved license
• client:
  • as above, but may want to evaluate separately so as to consider ramifications of open client/closed server option.
  • standards-based services probably get a pass on this, assuming that the standard has a source-available implementation.
• some other questions to ponder:
  • what about API? possible angles of API analysis include reliability, TOS, and API equivalents of GPL's virality or BSD's permissiveness. Probably deserves its own analysis, as a peer of source access.
  • skills: may also make sense to speak of skills to manipulate source as being a precondition, alongside but distinct from source access.
  • what is the equivalent of the GPL's system library exception in a web context? e.g., if I depend on Oracle, is my service really open? What if I depend on facebook? What if I merely use facebook?