1. What is Open-Source Software?

Open-Source Software is software whose source code is made available under an open-source licence permitting specified rights such as use, modification and redistribution, subject to the particular licence.

Examples include Linux, PostgreSQL, Apache, Python, etc.

The important distinction is:

• OSS is not necessarily “free of cost”.
• There may be expenditure on implementation, customisation, migration, hosting, security auditing, training, maintenance and enterprise support.
• The principal distinction from proprietary software is the licensing and access to source code, rather than simply price.

2. Government of India OSS Policy

The Ministry of Electronics and Information Technology (MeitY) formulated the Policy on Adoption of Open Source Software for Government of India in 2015.

The policy's basic approach is that Government organisations should endeavour to adopt OSS in e-Governance systems as a preferred option over Closed Source Software (CSS). MeitY continues to list the policy among its official Acts and Policies.

The policy is therefore important in procurement because it changes the question from:

“Can the Government buy proprietary software?”

to:

“Has the procuring authority properly considered whether OSS is a suitable alternative before selecting proprietary software?”

That distinction is legally significant.

3. Is Open-Source Software compulsory?

No—not in the sense that every government procurement must necessarily be OSS.

The policy establishes a preference/consideration mechanism, rather than an absolute prohibition on proprietary software.

For new e-Governance applications and systems, the procurement/RFP process is expected to require suppliers to consider OSS alongside CSS.

Where a supplier does not propose OSS, justification is expected for its exclusion. The comparison is intended to consider factors such as:

1. functionality/capability;
2. strategic control;
3. scalability;
4. security;
5. life-cycle/total cost; and
6. support requirements.

Where OSS is unsuitable for a specialised requirement, an appropriately justified exception can be made.

Therefore:

OSS preference ≠ mandatory purchase of OSS.

The correct legal position is closer to:

Consider OSS → objectively compare OSS and proprietary alternatives → record reasons → select the solution that best satisfies the Government's legitimate requirements.

4. Why did Government introduce the policy?

The policy has several procurement objectives.

A. Avoid vendor lock-in

If a department becomes completely dependent upon one proprietary vendor, changing suppliers can become extremely expensive.

OSS can potentially provide greater freedom to:

• change service providers;
• modify software;
• migrate infrastructure;
• maintain the application through another vendor; and
• avoid dependence upon a single proprietary ecosystem.

B. Reduce total cost of ownership

The relevant question should not merely be:

“What is the licence price?”

Instead, Government should consider Total Cost of Ownership (TCO) over the entire life cycle.

For example:

Thus, zero licence fee does not mean zero procurement cost.

5. OSS and the General Financial Rules, 2017

This is extremely important.

The GFR procurement framework applies to government procurement generally. The Department of Expenditure states that its Procurement Policy Division handles public procurement legislation/rules and the GFR 2017 framework for procurement of goods, services and works.

The current GFR compilation is particularly important because the rules have been amended over time. The Department of Expenditure has published updated compilations, including the version updated through 31 July 2025.

Rule 143 — “Goods”

GFR Rule 143 has a particularly important implication for software.

The definition of goods includes intangible products such as software, technology transfer, licences, patents and other intellectual property acquired for Government use.

This means that software procurement cannot simply be treated as outside the normal public procurement framework because “software is intangible.”

6. Fundamental principles of public procurement

Government procurement is governed by principles such as:

• transparency;
• fairness;
• competition;
• economy;
• efficiency;
• accountability; and
• obtaining value for public money.

The Government's Manual for Procurement of Goods explains that the procurement framework was designed around these principles.

These principles are particularly important in an OSS procurement dispute.

Suppose a department writes an RFP requiring:

“Only Product X shall be supplied.”

If Product X is proprietary and the requirement has no genuine technical justification, a disappointed bidder could argue that the specification is:

• restrictive;
• anti-competitive;
• arbitrary;
• designed around a particular vendor; or
• inconsistent with the OSS policy and procurement principles.

On the other hand, if the Government can demonstrate legitimate technical requirements that only a particular solution can presently satisfy, the specification may be defensible.

7. GeM and OSS procurement

Government procurement also has to be examined in light of Government e-Marketplace (GeM) requirements.

GFR Rule 149 makes procurement through GeM mandatory for goods/services available there, subject to the applicable rules and exceptions.

The Calcutta High Court has specifically discussed the statutory basis of GeM in Shree Durga Industry v. Union of India.

The Court observed that:

• GFR 2017 is the source of authority for GeM;
• Rule 149 deals with procurement of goods/services available on GeM; and
• Rule 160 deals with e-procurement. 

Thus, an OSS procurement policy does not operate in isolation. A procuring authority has to satisfy both:

OSS policy requirements + applicable GFR/GeM procurement requirements.

8. Important case law

There is an important qualification here:

Indian courts have not yet developed a large body of Supreme Court jurisprudence dealing specifically with the 2015 OSS Policy.

Therefore, most of the useful case law comes from broader principles governing government tenders, technical specifications, competition, arbitrariness and judicial review.

These principles are directly relevant to an OSS procurement challenge.

Case 1: Tata Cellular v. Union of India

Tata Cellular v. Union of India, (1994) 6 SCC 651

This is the foundational Supreme Court authority on judicial review of government contracts.

The Supreme Court established that judicial review is concerned principally with the decision-making process, rather than substituting the court's own commercial/technical decision for that of the Government.

The Court recognised that judicial review can intervene where government procurement decisions involve:

• arbitrariness;
• irrationality;
• mala fides;
• procedural impropriety; or
• unfairness.

The Supreme Court has repeatedly reaffirmed the principles of Tata Cellular in later procurement cases.

Relevance to OSS

Suppose a Government department rejects OSS without undertaking the comparison contemplated by the OSS policy.

A court would not ordinarily say:

“We think Linux is better, therefore Linux must be purchased.”

Instead, the legal question is more likely:

“Did the Government follow a lawful, rational and non-arbitrary decision-making process?”

That is the central distinction.

9. Michigan Rubber (India) Ltd. v. State of Karnataka

Michigan Rubber (India) Ltd. v. State of Karnataka, (2012) 8 SCC 216

This case is another leading authority on judicial review of tender conditions.

The Supreme Court emphasised judicial restraint in matters involving tender specifications and contractual decisions.

The Court recognises that the Government must have substantial freedom to determine:

• technical requirements;
• eligibility criteria;
• specifications; and
• the method by which it procures goods/services.

But that discretion is not unlimited.

A tender condition can be challenged where it is shown to be:

• arbitrary;
• discriminatory;
• mala fide; or
• contrary to public interest/law.

The Supreme Court continues to cite Michigan Rubber as a leading authority on tender judicial review.

OSS application

A bidder cannot successfully argue merely:

“OSS exists, therefore the Government must accept my OSS product.”

But the bidder may have a stronger case if it demonstrates:

“The Government designed the specification around a proprietary vendor without objectively considering OSS alternatives, despite the applicable OSS policy.”

The factual evidence becomes crucial.

10. Afcons Infrastructure Ltd. v. Nagpur Metro Rail Corporation Ltd.

Afcons Infrastructure Ltd. v. Nagpur Metro Rail Corporation Ltd., (2016) 16 SCC 818

This is particularly useful where a dispute concerns technical specifications.

The Supreme Court has emphasised that the author of the tender is generally best placed to understand its technical requirements.

Courts should not ordinarily substitute their own technical assessment for that of the procuring authority.

The Supreme Court has subsequently reaffirmed this principle.

Application to OSS

Imagine a Government RFP requiring:

“A database platform capable of processing X million transactions per second with specified security certifications and integration requirements.”

If the Government concludes after technical evaluation that only a particular proprietary product meets the requirements, courts will generally be reluctant to second-guess that technical conclusion.

However, the authority should be able to demonstrate that the requirement itself is genuine and objectively connected with the project's needs, rather than artificially designed to exclude OSS.

11. Caretel Infotech Ltd. v. Hindustan Petroleum Corporation Ltd.

Caretel Infotech Ltd. v. Hindustan Petroleum Corporation Ltd., (2019) 14 SCC 81

This is another important tender case.

The Supreme Court emphasised that courts should exercise restraint in interfering with tender conditions and commercial decisions, particularly where the procuring authority possesses specialised technical expertise.

The Supreme Court's later decisions continue to identify Tata Cellular, Michigan Rubber and Caretel Infotech among the leading authorities on restrained judicial review in public procurement.

OSS significance

A court will generally not conduct a fresh procurement evaluation and decide:

OSS = better than proprietary software.

Instead, it asks whether the Government's procurement process was legally sustainable.

12. Recent Supreme Court formulation

A particularly useful recent formulation appears in a 2025 Supreme Court judgment, which reiterated that courts should ordinarily avoid interference with tender/contractual decisions unless, among other things:

1. the process/decision is mala fide or intended to favour someone;
2. the decision is so arbitrary or irrational that no responsible authority acting reasonably could have reached it; or
3. public interest is affected.

This is highly relevant to OSS procurement.

13. Hypothetical example

Suppose the Ministry wants to procure a new e-Governance platform.

The RFP states:

“The bidder must provide Microsoft SQL Server Enterprise Edition.”

Assume there is no technical explanation.

A bidder proposes PostgreSQL, an OSS database, and demonstrates that it satisfies:

• required performance;
• security;
• scalability;
• interoperability;
• backup;
• disaster recovery; and
• integration requirements.

What questions arise?

The procuring authority should be able to explain:

Why was the proprietary product specified?

If the answer is merely:

“We have always used it.”

that could raise serious procurement-policy concerns.

But suppose the department establishes that:

• a particular legacy system requires a proprietary compatibility layer;
• the existing application is architecturally dependent upon it;
• migration would create unacceptable operational risk; and
• the authority conducted a documented technical and financial assessment.

Then the decision is much easier to defend.

14. What should an OSS-compliant RFP contain?

A well-designed RFP should ideally avoid unnecessary vendor-specific specifications.

Instead of:

“The bidder must use Product X.”

use functional and performance requirements such as:

“The proposed solution shall provide the following functionality, performance, security, interoperability and scalability requirements.”

Then include an OSS consideration clause.

The procurement evaluation can assess:

Technical

• functionality;
• performance;
• interoperability;
• scalability;
• reliability;
• security;
• standards compliance.

Economic

• licence cost;
• implementation cost;
• support cost;
• maintenance cost;
• migration cost;
• upgrade cost;
• life-cycle TCO.

Strategic

• vendor lock-in;
• source-code availability;
• portability;
• ability to change service providers;
• long-term sustainability.

Legal/IP

• licence compatibility;
• copyright;
• third-party components;
• indemnification;
• source-code rights;
• modification rights;
• redistribution rights.

15. OSS does not eliminate Intellectual Property Rights

This is a common misconception.

Open source does not mean “no copyright.”

OSS is generally copyright-protected software distributed under a licence.

Different licences impose different obligations.

For example:

• MIT;
• BSD;
• Apache 2.0;
• GPL;
• LGPL;

have materially different legal consequences.

Therefore, Government procurement documents should identify:

1. what licence is being offered;
2. whether modification is permitted;
3. whether redistribution is permitted;
4. whether derivative works have licensing obligations;
5. whether third-party components are included;
6. whether source-code disclosure obligations are triggered; and
7. who owns newly developed/custom code.

16. Custom software developed for Government

This is an especially important area.

Suppose a Government department pays ₹50 crore to a system integrator to develop a custom e-Governance platform.

The contract should clearly address:

• ownership of source code;
• copyright;
• licence rights;
• modification rights;
• reuse rights;
• documentation;
• third-party components;
• open-source components;
• escrow, where appropriate;
• security vulnerabilities;
• maintenance;
• exit/migration assistance.

The Government's 2017 Model RFP initiative for software procurement itself recognised the importance of standardising contractual provisions, including intellectual-property rights, service levels, change management and dispute resolution.

17. Open Standards and OSS are different

Another important distinction:

Open Source Software

Concerns the software and its licensing/source code.

Open Standards

Concern the technical specifications/protocols/interfaces that facilitate interoperability.

A Government system can use:

• OSS + open standards;
• proprietary software + open standards;
• OSS + proprietary interfaces; etc.

Therefore, an RFP should not automatically treat “open source” and “open standards” as synonymous.

India separately has a Policy on Open Standards for e-Governance Applications.

18. Can a Government department completely exclude proprietary software?

The OSS policy does not mean that every proprietary solution is unlawful.

There may be legitimate reasons to select proprietary software, including:

• specialised functionality;
• security requirements;
• existing infrastructure compatibility;
• regulatory certification;
• performance requirements;
• lack of mature OSS alternatives;
• availability of specialised support;
• migration risks;
• total cost considerations.

But the procurement authority should be able to document the justification.

This is particularly important because an unexplained departure from a Government procurement policy can become evidence in a judicial review proceeding.

19. Can a bidder challenge a proprietary-only tender?

Yes, potentially—but winning the challenge is another matter.

A bidder might challenge a tender under Article 226 where it can establish, for example:

Ground 1 — Arbitrariness

The specification has no rational connection with the actual requirement.

Ground 2 — Vendor favouritism

The specification appears tailor-made for one vendor.

Ground 3 — Violation of procurement policy

The authority failed to undertake the required OSS/CSS comparison contemplated by the applicable policy.

Ground 4 — Discrimination

Technically equivalent OSS solutions are excluded without reasonable justification.

Ground 5 — Public interest

The specification unnecessarily increases public expenditure or creates substantial vendor lock-in.

But the bidder faces the strong judicial-restraint principles established by Tata Cellular, Michigan Rubber, Afcons and Caretel.

20. Important legal principle: “Best technology” is not the court's decision

This is probably the most important point for an examination or legal research paper.

The court generally does not decide:

“Which software is technologically superior?”

It decides:

“Was the Government's procurement decision lawful, rational, fair and non-arbitrary?”

Thus:

Technical superiority alone ≠ right to tender award.

And:

OSS status alone ≠ right to tender award.

The decisive issue is the legality and rationality of the procurement process.

21. Practical legal framework

For an Indian Government OSS procurement, the hierarchy can broadly be understood as:

Constitutional principles
↓
Public procurement law/rules
↓
GFR 2017 and applicable amendments
↓
GeM/e-procurement requirements
↓
MeitY OSS Policy and e-Governance policies
↓
RFP/tender conditions
↓
Contract and software licence

The exact applicable framework can differ depending upon whether the procuring entity is:

• Central Government;
• State Government;
• PSU/CPSE;
• autonomous body;
• statutory authority; or
• another publicly funded entity.

22. Key case-law principles in one table

The Supreme Court itself continues to cite Tata Cellular, Michigan Rubber and Caretel as the leading framework for restrained judicial review of public tenders.

23. A strong legal proposition for an answer/examination

You can formulate the position as follows:

The Government of India's Open-Source Software Policy does not create an absolute statutory obligation to procure OSS in every case. It establishes OSS as a preferred option and requires its consideration in appropriate e-Governance procurements. Consequently, a procuring authority selecting proprietary software should be capable of demonstrating an objective and reasoned basis for that choice, having regard to functionality, security, strategic control, scalability, life-cycle cost and support. Nevertheless, the ultimate procurement decision remains within the Government's contractual and technical discretion, subject to the constitutional limitations of non-arbitrariness, fairness, transparency, public interest and absence of mala fides.

That proposition reconciles the OSS policy with the Supreme Court's tender-law jurisprudence.

24. Conclusion

The Indian approach is best described as “OSS-preferred, but not OSS-at-all-costs.”

The legal framework attempts to balance two competing interests:

Government's interest in technological freedom, interoperability, reduced lock-in and long-term value
versus
Government's legitimate need to obtain technically suitable, secure, reliable and supportable technology.

Therefore, the strongest legal objection is generally not simply that a Government chose proprietary software. The stronger argument is that:

the authority failed to objectively consider OSS, used unnecessarily vendor-specific specifications, failed to record reasons for rejecting OSS, or adopted a procurement process that was arbitrary, discriminatory, mala fide or contrary to applicable procurement rules/policy.

For actual litigation, however, the particular RFP, applicable departmental procurement rules, GeM conditions, policy version, technical justification and reasons recorded by the procuring authority would need to be examined.