Linux/Open Source and the Government

Background: This document was submitted to the Government of India in response to their request for a position paper, leading up to the (now famous) closed-door meeting on December 23rd, 2002, where the Government and the IT Industry and Academia met to discuss the adoption of OpenSource by the Government. The author was one of the invitees to that meeting.

The original PDF submitted to the government is downloadable here.

The reason why this document has been put up here is because a recent article in the Economic Times that is very obviously based on this whitepaper gave a totally different spin to the subject matter.

Approach Document

for

The Linux India Initiative

by

The Government of India By

Atul Chitnis
Exocore Consulting (P) Limited
http://www.exocore.com

on behalf of

The Linux Community of India

Executive Summary:

The Government of India, through the Ministry of Communications and Information Technology (Department of Information Technology), has requested inputs and recommendations for the the use of Free/Libre OpenSource software (FLOSS) and technologies such as Linux by government agencies, as well as in other spheres of operation in India.

This document, while not not purporting to be a complete guidance document, will attempt to outline the basic thoughts expressed by the Indian Linux/FLOSS community and industry.

Authors:

This document is prepared by Atul Chitnis of Exocore Consulting (P) Limited, and is partially based on a forthcoming whitepaper being prepared by Exocore for submission to the Government of India.

Exocore Consulting is a Bangalore based technology consulting firm that specialises in the identification and deployment of appropriate technologies, and has vast experience in the FLOSS field, having worked with the Linux/FLOSS community and industry for many years. More information about Exocore Consulting is available at http://www.exocore.com.

Parts of this document are taken from various documents and contributions, and are attributed where appropriate.

This document is supported by a collection of documents sourced from governments, community and industry that discuss the use of Linux/FLOSS, which are enclosed with this submission.

Version 1.1

Introduction:

“OpenSource Software (OSS) is software whose source code is openly published, is often developed by voluntary efforts and is usually available at no charge under a license defined by the Open Source Initiative (http://www.opensource.org) which prevents it from being redistributed under a more restrictive license.” — OpenSource Software Policy, UK Govt.

This means that software and technologies developed under an OSS license are available in source code format, allowing the modification by anyone who finds a need to do so, as well as the redistribution of OSS without financial or legal ramifications (provided this is done within the scope of the applicable OSS license).

An example of an OSS license is the “General Public License (GPL)” (http://www.gnu.org/licenses/gpl.html), authored by the Free Software Foundation (http://www.fsf.org), that today governs the use of a huge proportion of all OSS released today. In brief, its states that software licensed under the GPL will remain free under any circumstances, and that it cannot be appropriated by anyone in a closed/proprietary manner. It also mandates that anyone is free to distribute the software, and may modify it as required, provided that such modifications are given back to the community so that others may benefit from the modifications.

An actual in-depth discussions about OSS licenses is beyond the scope of this document – readers are encouraged to visit the referred websites for more information.

“Linux” is a term used to refer to the following:

  1. As the “kernel” (or core) of an operating system, around which an entire operating system is built. This is known as “The Linux kernel” as developed originally by Linus Torvalds and the development community.
  2. As an Operating System (or OS distribution) that is based on the Linux kernel, incorporating many OSS components to provide a complete computing platform. Though the correct terminology would be “Linux+Gnu+Apache+…..”, the most common usage in public mouth (and the best understood one) is “The Linux OS” or just plain “Linux”. (The actual definition is subject to innumerable debates, and is beyond the scope of this document).
  3. As term representative of the OpenSource movement in general. Linux is the most visible “poster child” of the movement, and has gained instant name recognition, with enviable “branding”.

“OpenSource” is a term used to refer to the following:

  1. The class of license used to license the software
  2. The development methodology used in the development of software.

In this document, “Linux”, “OpenSource” and “Free/Libre OpenSource Software (FLOSS)” are sometimes used interchangeably. While this may not be correct technically, it does provide a certain amount of convenience to the authors.

Issue 1: Government Stand

The government is considering the adoption of OpenSource for its IT operations, as well as for the use in IT operations it influences, such as education.

However, a question arises whether the government should mandate the use of OpenSource software and technologies, locking out other sources of software.

As expected, this move would be completely contrary to what is expected of a Government, which can (and should) offer recommended guidelines, and naturally follow them itself, but not create a monopoly situation that does not differ from existing proprietary software monopolies.

Recommendation:

The Government could indicate its preference of OpenSource software in its procurement process, but not at the cost of functionality.

Instead, it should mandate a software/technologies evaluation, selection and procurement process that clearly includes OpenSource software and technologies, comparing it on functional and financial basis to other offerings. The most important part here is “functional” – it would be illogical to reject a solution for which no functional equivalent OpenSource offering is available.

However, this is a favourite hunting ground for proprietary software vendors. It is easy to lock out an OpenSource solution by specifying a functionality that is proprietary.

An example of this would be “ability to read Microsoft Word documents without loss of formatting or content”. This is a trap, since only Microsoft Word actually knows the structure of the documents it creates, and this structure is a closely guarded trade secret.

Instead, a requirement specification should read as “should be able to store documents in an open and well-documented format that makes it easy for other applications to access information contained in the document, without interaction with the original developer of the software that created the original document”.

Issue 2: Adoption of the products or the process?

Let us consider some of the tangible benefits of Linux:

  • No cost
  • Increased stability
  • Enhanced security
  • Better functionality
  • Adherence to published standards
  • Interoperability

I would postulate that no operating system would possess these benefits unless it met the following criteria:

  • Source available for all to view (increased security, better stability)
  • Source available for all to modify (better functionality)
  • Worked on by a large, diffuse team (Standard adherence, Interoperability).
  • Source and binaries free for all to distribute (No cost)

In other words, Linux offers the listed benefits precisely because it follows a Free/Libre and Open Source Software (FLOSS) development model. Without that model, Linux is just another also-ran in a long list of also-ran operating systems.

It is a great mistake to separate out the benefits of Linux (listed) from the causes of those benefits (the FLOSS development model) and tout Linux itself as the ultimate solution. The solution keeps evolving to meet the needs of different environments and entities; sequestering the development model from the software will ultimately result in another operating environment that mirrors the (to take an example) Microsoft set of products and their inherent weaknesses.

– Raj Mathur in a posting to the Linux-Delhi mailing list.

The above text clearly shows the inseparable connection between products (such as the Linux OS) and the development model that creates these products. While Linux does represent the most visible of such products, it is the public development model (that includes the creation as well as review of such code) that is actually at the heart of matter.

It would be insufficient for the Government to consider and adopt specific FLOSS products without using the development process as criterion.

Why is this so important?

Already a huge number of products have started appearing that “run under Linux”, a measurable proportion of them are just another manifestation of the closed source model of development. This does not provide the government any benefits of the FLOSS model.

Recommendation:

While selecting products based on FLOSS, the Government should specify that “OpenSource products indicate products or technologies that follow the OpenSource methodology of development, and not just operate on an OpenSource platform.”

Issue 3: Support Services

A favourite “weapon” against OpenSource software is the concept of “support by the vendor”, and an implied “someone you can sue”.

It has been implied that OpenSource software does not enjoy the kind of support provided by proprietary software vendors.

This impression is completely wrong, and its propagation should not be encouraged. Almost all software support for proprietary software is a charged process. In fact, proprietary software vendors create commercial “training” and “certification” facilities for their products that have now become an entire industry of its own.

However rarely (if ever) do these “support services” exceed the quality and availability of support for OpenSource software, as evidenced by the incredible growth and adoption of FLOSS in India.

Recommendation:

The Government can change the face value of “support services” in a very simple and effective manner – provide resources (and possibly funds and recommendations) that will ensure that support services for OpenSource software in India. This can be done by encouraging the growth of technical and vocational training services in Universities and even schools, thereby providing greater scope for employment to students at all levels, without the financial penalties normally associated with the “training” in support for proprietary software.

Issue 4: Adoption and Policy

The Government will face an incredibly difficult task (made difficult by many commercial interests at stake for proprietary software vendors) formulating a fair policy that includes the use of OpenSource software.

Luckily, much of the hard work has already been done by governments of countries such as Germany, France, the United Kingdom, etc.

Enclosed with this document are actual policies and guidelines postulated and mandated by the government of the United Kingdom (uk*.pdf). Since the functioning of the Government of UK is very similar to that of the Government of India, adaptation of these policies and procedures should considerably ease the process of formulation.

Also enclosed are documents prepared by Dr.Gurunandan Bhat of the University of Goa, and published by Synapse, Goa, that clarify many aspects of OpenSource as well as the use of OSS in eGovernance.

Issue 5: Resources

The single biggest advantage OpenSource enjoys is availability of resources. Whether in the form of modifiable and usable source code for every OSS product, or support material – there is no dearth of such resources.

Also, over the past few years, India has witnessed a tremendous growth in awareness of (and technical competence in) OpenSource products. Pioneered PCQuest (whose Linux Initiative has been running since 1996, and has been responsible for the distribution of more than a million Linux CDs in India), many IT-related publications have made available vast amounts of technical information and other material to their readers over the years.

Disclosure: The author conceived and created the PCQuest Linux Initiative in association with the editors of PCQuest, and was a consulting editor of the publication between 1998 and 2002.

OpenSource Conferences, such as India’s premier annual Linux/OSS conference Linux Bangalore (http://linux-bangalore.org/2002), which was sponsored and endorsed by the Government of India, have grown from small regional get-togethers to huge national and international prime events, recognised for their professional execution and content, and hailed for their usefulness to people interested in OpenSource technologies.

Many premier training institutions across India now offer Linux and related OSS courses.

But most important of all:

India’s technical education system is built entirely around the concepts of Unix, which Linux embodies today. In fact, most computer science subjects, as well as technical and vocational courses, use Linux and Unix as a base for their curriculum, resulting in vast numbers of technically competent and qualified Linux & Unix savvy engineers emerging from universities every year.

By recognising OpenSource Software as a desirable platform for Government and related IT operations, the government will prevent a situation where students graduating from our universities will have to spend a fortune in getting training in a proprietary technology before they become “employable”.

Summary:

In summary, the vast Linux and OpenSource community of India applauds the desire by the Government of India to adopt Linux and OpenSource as a source for its technology fulfillments, and looks forward to working with Government to help it in this endeavour.

However, the community does caution the Government that it is a rocky road ahead, given the number of policy and commercial issues that need to be considered, and it urges the Government to make use of the community’s support and participation in surmounting these obstacles.

Because just like OpenSource products and OpenSource development processes, there is only one way to work on this project:

Together.

Comments are closed.