Run That By Me Again?

The Senate hearing last Monday on the MassGov OpenDocument policy betrayed the glaring misprision by some people of the lingua franca of our open standards conversation.

Whether or not state Senators and other representatives have a sincere interest in understanding the subject at a basic human or technical level, the responsibility falls to the cognoscenti to fill in the blanks.

Here's a tiny sample from Massachusetts Senator Pacheco's interrogation of Peter Quinn:

Q: Why did you correct yourself about "open source?"

A: Open Standards can be implemented in open source or in proprietary software.

Q: So let me see if I understand. Isn't ODF distributed under something called the GPL?

(Andy Updegrove provided the full transcription)

Below, here's a little FAQ which I have already submitted to the OpenDocument Fellowship and which I hope people will generally feel free to improve, duplicate or extend to their own contexts.


1. What is the difference between a software license (the GPL, LGPL or EULA, for example) and a software standard specification (OpenDocument, for example)?

A license states the terms of distribution and use of a certain organization of code (software product), whereas a standard specification is a document which lays out the design rules and interface characteristics of a common data format, language or communications protocol (some kind of standard) and how other code can interact with it.

A standard specification like OpenDocument is not code, it is a document (OASIS holds the copyright to the OpenDocument Specification document itself) and is not distributed under a license. It is a design plan that is implemented by software. Nor is the license of a standard-deploying software application relevant to the standard itself. [Note: I amended this paragraph when David Berlind's excellent annotated transcript of the Massachusetts Senate hearing pointed out that I was roughly as clueless as Senator Pacheco about the relationship between standards and software. -SH (11/7/2005)]

2. What is the paradox of the GNU General Public License ("the GPL"), the most widely used of the so-called Open Source or Free Software licenses? Why is it so hard to understand from different points of view?

The paradox of the GPL is that while it indicates sharing behavior (which is generally considered to be a liberal or open type of behavior) it simultaneously offers strict limitations and rigorous precision as to the degree of the sharing behavior permitted.

The GPL for example is known for enforcing the free sharing and collaborative improvement of software code; however, the GPL does not permit anything but sharing. That license therefore is considered highly restrictive.

The language one chooses to describe the GPL, for example -- i.e., 'open' versus 'restrictive' -- will depend upon the dominant relationships the speaker may have to interests in software development and objectives in design and dissemination of the software; that is, it will depend on personal attitude, political persuasion, wind direction and context of the conversation.

3. What is the difference between the GPL and the Lesser GPL?

The thing about software code is that people like to reuse old code to do new things by attaching pieces together (old with old, old with new, etc.) to perform new or expanded tasks. Code reuse is one of the attractive labor efficiencies in the digital life.

Roughly speaking the GPL is "unfriendly" to proprietary software code because it would cause any proprietary code that is attached to some set of GPL code to become free, to be implicitly attributed a new free license that the proprietary code could never "shake off" after the fact.

The LGPL permits non-free code (code which has restrictive distribution characteristics) to be included with GPL code (at compile-time) without requiring a new free license to be attached by implication to the proprietary code.

Individuals or companies which own blocks of software code and who wish to preserve their own set of certain distribution limitations on that code are attracted to using the LGPL to distribute the combined code because it allows them to retain control of the code they attach -- perhaps for other purposes on another day. OpenOffice is a good example of a product that uses the LGPL; this is done to attract proprietary extensions to the free code-base with the goal of enriching the market of product options and vendors competing on their ability to add value to a common base of open source code.

Value judgments get attached to GPL code as being 'open' or 'better' and proprietary code as being 'closed' or 'having weakness.' While quality is always intrinsic to the code itself, the sense of 'open is better' exists because broadly collaborative code development methodologies have been demonstrated in the recent decade to produce some powerful results including GNU Linux, Apache, Firefox.

This particular value judgement has been substantiated in certain prominent examples in recent history in which open source code which has "proprietary dependencies" becomes suddenly unusable because the entity owning some part or parts of the whole changes its behavior in some way (not always of its own volition). Thus, proprietary dependencies are ceteris parabis to be generally avoided with discipline. Yet there remain instances in which GPL code is impractical or impossible to implement due to the realities of legacy systems which are intolerant of GPL-based systems.

4. What is the difference between OpenDocument and OpenOffice?

OpenDocument is a technical specification for the design of a group of file formats while OpenOffice is an office suite application such as which is installed into an operating system to enable a user to create, read or edit files.

A file (and the format of that file) is physically distinct from the application which creates it, opens it, saves it, adds things (text or other such elements) to it or takes things (text or other such elements) out of it.

This is the difference between a file (data, the thing created, altered, sent or manipulated) and an application (the organized code, the software tool which acts upon the data).

Confusion may arise in the minds of the general public because in the present circumstance with which many people are most immediately familiar there is no distinction made that is obvious as to the separateness of file and application.

Perhaps you can see in this context that OpenDocument is pioneering, forcing, a natural progression toward data being handled independently from applications. It's the way it should be: access to data in documents should be analogous and equivalent to the level of free access we enjoy today to all the data contained in the many Web pages on the Internet. The wide popular deployment of OpenDocument would right the present restriction of access in the document field.