Some thoughts about Bulgaria's law demanding open source software

Bulgaria has apparently passed a law recently demanding all software purchased in the future by the country to be open source. This raises a couple of procurement related questions which are worth covering here.

Art 58 of the E-Government Act states that:

Art. 58a. (New - SG. 50 of 2016, effective 07.01.2016) Upon preparation of technical and functional assignments for public procurement to develop, upgrade or implementation of information systems and e-services administrative authorities must include in the job following requirements:
1. where the subject of the contract includes the development of computer programs:
a) computer programs must meet the criteria for open source software;
b) all copyright and related rights on the relevant computer programs, their source code, the design of interfaces and databases whose design is subject to the order should arise for the principal in full, without limitations in the use, modification and distribution;
c) Development should be used repository and revision control maintained by the Agency in accordance with Art. 7c pt. 18;

(Translation via Google Translate)

It appears this law mandates Bulgarian contracting authorities to only acquire open source software from now on, although that not extends to licensing agreements. In other words if the contract calls for software to be developed, then it needs to be open source whereas if the contracting authorities wants to simply license commercial software it can continue to do so. Effectively, the open source mandate only kicks in for the creation of new software.

By demanding open source to be used, Bulgaria is taking steps to owning the software outright, instead of paying to a contractor to develop the software and then keep the underlying intellectual property which is a more common model and one that may have State Aid implications.

I think this is a good and reasonably balanced approach taken by Bulgaria. In addition to what has already been said by others (and here), one can think about added benefits from this measure. First, it avoids the lock in of the contracting authority to a piece of software which is fundamental to its operations (or else it would not have gotten it developed in the first place) and whose control lays in the hands of the contractor. I think this is probably the biggest benefit from a public sector perspective and it is worth nothing the ownership of associated IP is also demanded by the new law. Out of the top of my head I can remember a case where a Government had to pay an outgoing contractor to get data out of a database as said contractor owned the underlying source code and refused to play ball without being paid. It is important that contracting authorities understand the relevance of "owning" the underlying custom code they use, even if it is just for the purposes of making it available in open source.

On the long run, by making the code open source and having it in a central repository which is easily accessible ensures that Bulgarian future contractors can easily re-use the existing code, ensuring continuity of service and pushing costs down over the long run.

There are, however a few procurement related potential downsides to this approach.

First, it may be perceived as violating the rules demanding technical specifications not to be discriminatory, as any economic operator developing commercial software would potentially at a disadvantage. I do not see this as a real problem since any economic operator can still take part in the procedure nonetheless and the demand of open source can be seen as a requirement to own the software outright instead of just its use (which is pretty much the model for commercial software). As a comparison its like the contracting authority buying a vehicle outright instead of leasing it - the leasing companies are also at a disadvantage. At their core all technical specifications are discriminatory.

Second, there may be extra costs associated with the open source approach (at least at the beginning). The usual suppliers may try to increase prices since they will not be able to re-use the code at profit in other projects down the line. However, the added competitive pressure may actually put a lid on prices quite quickly. Even if it makes contracts more expensive now,  over time I suspect the fact code is open source and can be iterated by different economic operators will lead to lower prices overall.

Third, it is important to ensure liability is correctly allocated on each contract, especially if existing code is being re-used or re-purposed. This, however, is a problem for all software contracts or in procurement of innovation in general.

Links I Liked [Public Procurement]

1. Why is so much ICT procurement not appearing on ContractsFinder? SpendMatters reports on some research carried out by Innopsis on this topic. The smoking gun - which I agree with - is framework agreements. As argued here before, framework agreements are a black hole in what concerns contract data.

2. MOD publishes a refreshed SME policy.

3. The Public Contracts Regulations 2015 has been amended by the Public Procurement (Amendments, Repeals and Revocations) 2016. Great to see the that section 1 no longer refers to the Europe 2012 strategy, but one has to wonder - again - why the rush to ge tthe PCR2015 out the door in February last year.

4. Slovenia reforms its public procurement law, right before the deadline to transpose Directive 2014/24/EU.

5. Not all is good in Bulgarian public procurement. Further examples here.

Links I liked [Public Procurement]

1. "Don't give contracts or grants to companies without women in the boardroom" 

Once more, tying to use public procurement to solve problems not directly connected with it.

2. "Fence at border with Turkey to be built without public procurement"

Who needs public procurement anyway!

3. Guide on consortium building (Ireland)

Interesting take on do's and don'ts of getting consortia of the ground to bid in public procurement.