FSF India's Response to the Proposed Framework by Govt of India
A half day Consultation Workshop on “Framework on Adoption of Open Source Software” was organized at DeitY, Electronic Niketan, New Delhi, on October 25, 2013.
The document is available on eGov Standards portal https://egovstandards.gov.in/Public\_review\_Framework\_on\_oss.
Dr. Nagarjuna G. from Free Software Foundation of India attended the meeting and gave the following response to the draft document.
Not recognizing that citizens are the primary stakeholders of Govt
The document tries to balance the advantages of free software (FS) and proprietary software (PS), and would like to present FS merely as an option available. This neutrality is against the interests of expanding the public wealth of the commons.
Proprietary software companies have an explicit objective to expand their ownership of technology, and industry bodies like NASSCOM explicitly support these objectives. This comes in direct conflict with the interests of the citizens in having control of the actions of the state.
Why should Govt try to accommodate proprietary interest that goes against its own mandate?
eGovt is an extension of Govt, and should not be considered primarily as a platform for commercial companies. The companies can provide services as long they follow the non-proprietary basis of FS. This principle cannot be compromised, and the government must insist.
“OSS” to be replaced with “FLOSS” consistently
“FLOSS” is a more inclusive term because it includes the two broad communities. This is partially reflected in naming the two other Govt of India projects, e.g. NRCFOSS and ICFOSS of Govt of Kerala.
Though in the introductory section (2.4) it mentions that the document considers the term inclusive of both FOSS and FLOSS, it is better to use the widely used inclusive term than an explicit exclusive term to bind the two communities.
If the text says “OSS”, it explicitly rejects the idea that issues of the people's rights and the nation's sovereignty are at stake.
Incompatibility of TCO with Govt agencies and FLOSS models
What is the TCO for running a Govt or eGovt? Govt does not do business with citizens. It provides services that are direclty paid by the citizens. The cost of Govt is therefore granted by the people of India. It is Govt responsibility to grant the ownership to people. Please do not use terms that present the issue in terms of commercial values to the exclusion of civic values. Acknowledging the concept of free/libre software by using the term "FLOSS" explicitly supports and stregthens Govt roles and responsibilities.
To compare TCO for free/libre software meaningfully with that of PS, the government should include the cost of obtaining the source code for that proprietary software, and the right to flexibly use it. Thus, if Govt considers TCO as a criteria to choose between the software, then Govt must procure the source code of a proprietary software and include it in TCO analysis. This should include the entire platform on which an eGov application runs, not merely the customized code of a proprietary software.
Ultimately, the comparison of cost is made meaningless by the fact that PS delivers far less. PS does not deliver the source code. Where FS delivers sovereignty, PS delivers the state into dependence on a company.
Companies can bid with the Govt to create FS based on the need
As and when a specific application is missing in FLOSS, Govt could spend its resources to create FS by hiring the services of companies. Thus companies could have an important role in helping the Govt to create FS as and when necessary. This will enhance Govt ICT capacity. This can also be a role of the proposed center of excellence for FLOSS.
FSF India opines that this document should propose a plan towards eliminating the need for proprietary software in eGovernance.
This section does the analysis of licenses with a yardstick defined in terms of opposition to freedom. The proper yardstick when we talk of licenses should be the freedom that users (such as the government) will have, and how certain they are to have it.
The copyleft licenses – the GNU GPL and the GNU Affero GPL – are designed to make sure that modified versions of a program, if their use is offered to the public, are available to users with freedom. They have requirements, which add up to, “If you let someone use your version of the program, you must let him have it as free software.” This is defense of the public's rights, including the government's rights.
For instance, using the GNU AGPL is a way to tell companies such as Google, ”You can adapt or extend this code to make a service, but then you must make your changed version of the code available, so we can run on our services too.“ The GNU AGPL is specialy crafted to suit the freedom of users such as the government for software that runs on online portals (including eGovernement portals). Therefore, the state has every reason to promote the GNU AGPL for software that is likely to be useful on such portals.
Why would someone call this a “restriction”? Only if what he wants to do is restrict the public. Copyleft licenses say, “You can't use this code to restrict others.” Thus, the government should prefer copyleft licenses when given the choice.
Use of FS by Govt should not follow how commecial companies think about licenses. Using their model of analysis for Government agency will lead to complete conflict of interest. Governemnt needs to protect the software freedom of its users and itself, and not the interests of software developing companies that would benefit by denying that freedom.
The most important stake-holder for the Governement is the people it serves. Further, copyleft licenses do not interfere with commerce, except for unethical commerce.
Therefore, the recommendation at the end of section 5 should be removed and replaced with the following:
Web based infrastructure used by a Govt project should be released under AGPL, so as to maximize the extent to which improvements made by others become available for the Govt to use.
The idea of recommended Stacks
The section 2.5 misses the essential point of the use of free software. The free software community has created certain frameworks (a better choice than 'stack'), one of which is GLAMP (GNU, Linux, Apache, MySQL, PHP). But GLAMP by no means is the only good framework. There are other frameworks such as Django, Plone, Ruby on Rails, Flask, Java based frameworks etc. Each of these frameworks e.g. is based on a single programming language: e.g. GLAMP is based on PHP, while Django, Plone and Flask are based on Python.
The state should not arbitrarily impose a particular framework. The pros and cons of which free/libre framework to use for which project should be left to the chosen on the basis of the function of the platform by the competent developer and maintenance team.
Providing some guidelines such as availability of features, libraries, wider use base, existence of strong developer communities and support groups, established credentials etc. may be given, instead of recomending one over the other.
Therefore the framework could recommend guidelines instead of naming any platforms.
SWOT analysis section needs more clarity, rigor and elaboration. First of all, two important things have to be defined and identified before a SWOT analysis can be done: 1. which is the organization or agency for which this analysis is done? 2. what is the objective for which this analysis is done? Unless the organization and objective are explicitly laid out, SWOT analysis does not help us to give any direction.
Therefore section 3.3 needs an overhaul.