Granularity

= Granularity & Freedom: Chasing the devils in the details =

About the author

 * Charles-H. Schulz is a founding member of the Digital Standards Organisation aka Digistan; he's been very active on the OOXML issue and is also a contributor to OpenOffice.org. He works at Ars Aperta and is a member of ESOMA.

Which granularity is being discussed here?

 * This page can be understood as a comment about the Definitions and the Recommendations . In short, the need for more granularity has been demonstrated in the context of Open Standards. The central question is how do you define open standards and openness. There is no easy answer, because the definition may not only vary from one constituency to another, it does also change according to the contexts. The only stable criterion is the lack of barriers applied to any given standard (protocol or format).
 * The need for granularity may also be felt in the context of Open Services and users' data. While a fixed set of criteria can be defined in order to use it against any online service such as the OSD, there may be cases where the definition in question may still apply but could end up irrelevant as the intruments through which the service is being carried and implemented are not actually Free or Open (in the sense of the FSF, OSD or perhaps in other, different ways).

Granularity and the Tunnel
The tunnel here refers to the actual technology used to provide online services to users: protocols, their implementations, technologies, development platforms, languages and formats fall in the concept of tunnel.

The tunnel can sometimes become an issue if the kind of freedoms we usually grant to users are not ensured and allowed. For instance, a service X could satisfy to the requirements described in the OSD but the implementation of this service can only be provided in a proprietary technology or a patent-riddled "open source" implementation.

It is not up to the Autonomo.us team to reinvent the wheel, or in this case reinvent the GPL. What is desired however is to define the granularity of the demands and requirements of the Autonomo.us work so that the different guidelines, definitions and values put forth by Autonomo.us can properly deal with issues that may not entirely belong to the scope of its work but may eventually end up lowering this work's relevance and efficiency.

As such several levels of "granularity" can be discussed.


 * Service and data : that's the core concern and focus of Autonomo.us
 * Code/distribution/rights: also of concern
 * Values: also of concern but values belong to the field of "spirit" rather than letter. It is sometimes difficult to show that a particular value, whose definition is never exactly the same for everyone is being affected or denied to an user of a service.
 * platform, adherence, barriers to implementation: that's as far as granularity may go for Autonomo.us. Example: Service A is a commercial service, personal and associated data belong to the users, permanence is ensured, reuse of information is under a CC-style license. Service B is completely open source, (e.g source code available) personal data is exportable but service needs the MS Silverlight plugin and can only be implemented on the .Net platform (okay, that claim is kind of bogus, but there can sometimes be strong adherence to some particular technology) . Does service B bring more freedom than service A?