Thoughts on the White House Source Code Policy

According to this GitHub post by Mark Hopson from 18F, the US Government is considering introducing a policy whereby custom made code should include (some) distribution rights and not only the right of use. In other words, the US Government is mulling requiring developers to grant a more expansive license to the Government, so that the code can be be re-used by Federal agencies other than the acquirer. These are interesting developments, well worth some comments.

I find it fascinating that the policy is open to discussion and comments, even on GitHub as done by Mark. Here are my views on the proposed Policy as well as Mark's suggestions.

1. What is at stake

When someone buys say a license for Windows, that license includes only the use of the programme and not the rights to modify or redistribute the source code. Buying a "off the shelf" license to use Windows is manifestly different from asking a developer to come up with a custom solution for a specific problem. The proposed Source Code Policy targets the latter and not the former, ie new code that is developed specifically for the a need the Federal Government has. In general, I am in favour of making as much source code publicly available as possible under the guise of a public good.

From a procurement perspective, I find the Source Code Policy very interesting as it mitigates two major problems in procurement of innovation, albeit at a cost: (1) IP ownership and (2) State Aid.

2. IP ownership

In the last 4-5 years I have written a few times about the issue of intellectual property as the key problem in public procurement of innovation. When a new idea/implementation/solution is created as a consequence of a public procurement procedure, who should own the resulting intellectual property? Art 31 of the Directive 2014/24/EU - referring to the innovation partnership - only states that intellectual property rights need to be addressed during the procedure. We can get very specific and detailed depending on the type of intellectual property generated,* but on a general note the IP will belong either to the contracting authority or the economic operator(s) who created in the first place.

Mark suggests in its post a change in the draft policy so that it entails an acquisition of all rights to the custom code. In my view, a full blown IP acquisition by the public sector is not a great solution - managing IP is not the core business of virtually all contracting authorities and all the IP generated was a means to an end. In addition, if the contracting authority acquires the IP, it becomes responsible for both for the good and the bad which it may lead to. Case in point, if said IP infringes someone else's existing IP, guess who will be left holding the proverbial can? Sure, we can include back to back liability clauses in the original contract but that regulates the relationship between the contracting authority and the economic operator, without binding the owner of the infringed IP. Plus, if the economic operator goes bust all those nice and shiny indemnity clauses are not worth the paper they are written on.

Another downside of a complete IP assignment to the contracting authority is the loss of said IP from the wider society. Let's be honest as any IP acquired by the public sector would end up as the Lost Ark from Indiana Jones: locked in a "warehouse" of sorts, far from prying eyes and without generating any benefit for the society at large other than the contract where it was deployed. Mark's proposal of making all the code freely available would solve this problem.

The solution proposed by the US Federal Government is particularly interesting as it mitigates both downsides of a full blown acquisition. For the second it even strikes a good balance as it ensures other Federal Agencies can use it for free. As for the first, the economic operator is still on the hook for any infringement since it keeps ownership of the custom code. It may however increase the risk of litigation as more users will be deploying the code potentially raising the visibility of any IP infringements committed in the development of the custom code.

3. State Aid

Coming from an EU angle, The second problem with procurement of innovation in the EU is the potential for it to breach State Aid rules, namely Article 107 of the Treaty on the Functioning of the European Union. State Aid occurs when a an advantage to an undertaking is given by a public authority. Paying for a contract to develop an innovation while allowing the economic operator to commercially exploit the innovation would constitute, prima facie, a violation of EU's State Aid rules.

The problem, however, is somewhat mitigated by the Commission's own assumption (cf para 32) that it will not sue anyone involved in pre-commercial procurement where "an open tender procedure" has been followed, the underlying issue is still present as the primary law has not been changed and only the Commission pledge not to enforce it. In other words, the distortion to the internal market is still present - albeit legalised by the Commission pledge not sue the beneficiaries. Communications of the Commission, however do not constitute a source of EU law and ultimately the power to legislate in this matter remains with the Council (Art 109 TFEU). Do I see the Council meddling in this? Not really, hence my comment in the two preceding paragraphs.

Notwithstanding the above, it is clear that a license for a Government to re-use custom code acquired by any agency reduces the market value of said code. After all, a number of potential customers has just evaporated leaving the economic operator only with the possibility to re-use it with private clients or other public bodies not covered by the license. This reduces the level of state aid involved but does not fully solve this problem. The reduction in the potential number of customers brings me to the downsides though.

4. Other downsides

I suspect one of the unintended consequences of this policy will be an increase in prices. If economic operators know in advance they will not be able to re-sell the code to other Federal Government clients, the logical consequence is for them to jack up their prices. How much, I have no idea. Mark's solution would exacerbate this problem as the only opportunity a developer had to make money directly with the code is in that single transaction.

Ultimately, it may also lead to potential economic operators not turning up in the first place, reducing competition. Unless the code is completely separate from existing code-bases, no economic operator will accept creating a variant/fork of its "crown jewel" to be used for free by all other Government agencies. Unless, that is only the completely new code is covered by the sharing obligation. This, however, would be useless as the rest of the code would not be made available.

Another downside I see with this policy is the risk for the Government - by obtaining a license to share to other Federal Agencies but not the wider world - the Government becomes the custodian of that code. So what happens if after a security breach the code is leaked to the internet, coming from one of those private repositories? Who will be held responsible for the license violation? Mark's approach would solve this issue.

These downsides are valid both in the US (as afar as I can tell) as they would be here in the EU.

5. Bottom line

I do not want to rain on the Federal Government parade nor to chill any similar developments in the EU. If anything, I view this as the right way to go and one which balances well competing interests. Having said that, there are downsides and shortcomings to take into account.

*Whereas the main IP issue surrounding source code are by definition copyright, they do not end there. Out of the top of my head, there can be design rights (patents in US parlance) involved and in specific circumstances patents may be involved (yes, more common in the US than the EU).