KDE's Project Silk

The idea is indeed to create interfaces for service-types (think of social-networking, web-shopping) as examples. Those APIs are independent from the service they interact with. Applications use these APIs to offer integration with webservices.

These APIs are backed by plugins. So a social-networking API would have plugins for facebook, opendesktop, linkedin, for example. The application developer doesn't care about which particular service is being used. The plugins that are backing the task-specific API are written using script languages, or are generated from webservice descriptions (if possible). The API also doesn't discriminate between free and non-free services. Using scripted plugins makes it easy to update these plugins whenever the web service interface changes.

Which services are offered depends on what plugins are provided. Of course it's easier to write such a plugin for a well-documented interface (think of a REST API like openDesktop) than for a closed service -- it'll become easier to use the service from silk-enabled applications if the service makes its content and interaction available in a documented, machine-readable way. Those plugins could also do screen-scraping as a last resort for less friendly web services.

The question how we, as a Free software project protect our Freedom is only loosely connected to this. The idea is to have three categories: open, free and ugly.

- "free": Free web service implementation (such as identi.ca, openstreetmap)
- "open": Documented interface, service is not necessarily free but has a stable, machine-readable API
- "ugly": closed and no openly documented interface

Obivously, we prefer and actively encourage "free" and "open" services, but there's nothing that stops people from implementing backends for "ugly" services.