Algorithms Off-limits?
If digital trade law restricts access to source code of software then accountability will suffer

The stated reason why international trade diplomacy cares about source code of software has to do with a practice known as forced technology transfer. It harks back to disputes between technology exporting countries, e.g. EU member states and the US, among others, and yet other countries, such as China [36], among others, that make market access and foreign direct investment conditional upon disclosing commercially valuable information:

“Concerns have been raised about the use of registration, certification and approval procedures by government bodies to request, formally or informally, sensitive proprietary information which does not appear to be necessary, or indeed requirements to disclose source code.” [5]

Such a measure can in particular interfere with business secrets of the foreign company which are often central to business models in high-technology sectors. In that vein forcing a foreign company to divulge propriety source code of software to a government entity or local business partner is considered extortionate.

That is not to say that all technology transfers are necessarily bad. Especially intellectual property law, e.g. patent and copyright law, seeks to strike a balance between the protection of innovation and its release as a public good after the term of protection has expired. There is another important caveat to be made about technology transfers being used to enable developing countries’ economic development and to narrow the digital trade imbalance which is further explored elsewhere [31, 38].

The intuitive link between the risk of forced technology transfer and the inclusion of the source code clause is not always evident. For instance, neither the EU and its member states nor Japan, the UK or the US are implicated to use practices that force technology transfers. Nevertheless, the EU and these states incorporate this particular clause in their bilateral FTAs. To these states and the EU the template on software source code is considered best practice (‘gold standard’) and its proliferation serves to build clout for future negotiations with yet other trading partners.

International trade law thus comes in as an additional layer of protection for software source code that is commonly justified as countering a country's practices that would amount to forced technology transfer. Yet, inscribing the protection of source code of software in FTAs can have unintended consequences for perfectly legitimate public interest objectives:

“On the one hand, it encourages international trade by reassuring foreign software developers that they will not have to disclose the source code underlying their products and services. On the other hand, this general prohibition, even when accompanied by extensive exemptions, places limitations on the powers of governments and their agencies to examine source code.” [12]

This can render a FTA's commitment that protects software source code against government access and transfer a double-edged sword that can be used to contest a country's measure in pursuit of algorithmic transparency, fairness and accountability, as will be argued below.

New clauses on source code of software have come to proliferate in dedicated digital trade chapters of FTAs, however, not across the board. Several countries, notably the Australia, Canada, the EU, Japan, South Korea and the US, actively pursue the inclusion in their FTAs of a prohibition on government mandated access to source code of software. 2018 marks the inception of FTAs that contain a binding commitment on software source code [9, 14, 15, 39]. The actual text of the source code clauses covered in this section are reproduced in the Appendix.

Mega-regional FTAs are set apart from bilateral FTAs by their regional scope of application covering several signatory states. The 2018 CPTPP [9] is a case in point which is a regional trade agreement between eleven countries of the pacific rim, i.e. Australia, Brunei, Canada, Chile, Japan, Malaysia, Mexico, New Zealand, Peru, Singapore, and Vietnam. The CPTPP incorporates by reference the original 2016 Trans-Pacific Partnership (TPP) that had been negotiated with the involvement of the US but was later abandoned by the incoming Trump administration. The CPTPP Chapter on Electronic Commerce, prohibits a party to this agreement to require the transfer of, or access to, “source code of mass-market software or products containing such software” as a condition for the import, distribution, sale or use of such software in its territory. Excluded from the scope is “software used for critical infrastructure”. The prohibition does not preclude “requiring the modification of source code of software necessary for that software to comply with laws or regulations”, however, without requiring access to it [12].

Likewise the USMCA [39] that was concluded in 2018 between the US, Mexico and Canada, features a clause on source code in its Chapter on Digital Trade that is even more ambitious. Hereafter “no Party shall require the transfer of, or access to, a source code of software owned by a person of another Party” to this agreement. In addition, “an algorithm expressed in that source code” is explicitly covered. Algorithm is defined as meaning “a defined sequence of steps, taken to solve a problem or obtain a result.” The USMCA clause does “not preclude a regulatory body or judicial authority of a Party from requiring” access to the source code of software, including an algorithm, for a specific regulatory investigation or judicial proceeding, “subject to safeguards against unauthorized disclosure”.

The Regional Comprehensive Economic Partnership (RCEP) Agreement [30] concluded among fifteen Asia-Pacific nations in 2020, by contrast, does not contain a source code clause in its Chapter on Electronic Commerce. Neither does the Digital Economy Partnership Agreement (DEPA) signed in 2020 between Singapore, Chile and New Zealand considered to be one of the most innovative multilateral FTAs. The state of play in the ongoing negotiations at the WTO concerning source code is unclear but compared to other aspects where a consolidated draft has been provisionally agreed the issue of source code appears still controversial [45, 46].

From the plethora of bilateral FTAs it will suffice to highlight a few examples. The 2020 Digital Trade Agreement between the US and Japan [2] for instance reproduces by and large the source code clause of the USMCA.

How the EU protects software source code in its bilateral FTAs with Japan, Mexico and the UK is interesting to trace. The EU-Japan Agreement on Economic Partnership [14] and the EU-Mexico Agreement in principle [15] have seen the introduction in EU external trade policy of a novel clause on source code of software. More recently the EU-UK Trade and Cooperation Agreement (EU-UK TCA) [37] inscribes protection of source code of software in its Chapter on Digital Trade. The general prohibition that “a Party may not require the transfer of, or access to, source code of software owned by a person of the other Party” [14, 15, 37] resembles the FTAs mentioned earlier. As compared to the earlier FTAs of the EU with Japan [14] and Mexico [15], the custom-made exceptions in the EU-UK TCA [37] are more layered and also contain new elements. There will be more to say about the evolving language to carve out exceptions to the prohibition at a later stage.

While it is easy to loose orientation in this thicket of FTA provisions it will be important for the remainder of this article to recall that requiring access to source code of software by governments is increasingly governed by FTAs. While the exact language varies between FTAs there is a common core framing a general prohibition, subject to certain custom-made exceptions. The bilateral FTAs with the EU [14, 15, 37] do not mention ‘algorithms expressed in source code’ anywhere in contrast to US-led FTAs [2, 39]. Whether this is significant as regards the application of the general prohibition on government mandated access to algorithmic code will crucially depend on the interpretation of ‘source code of software’ which will be discussed next.

For determining the scope and impact of a digital trade law provision on source code of software the exact meaning of ‘source code of software’ is decisive. This term is not defined in any of the aforementioned FTAs. In this case the rules of treaty interpretation set out in the Vienna Convention [41] would guide the interpretation by the parties to an agreement and ultimately the relevant dispute resolution bodies. It provides that a treaty shall be interpreted “in good faith in accordance with the ordinary meaning to be given to the terms of the treaty in their context and in the light of its object and purpose.” [41]

In the field of computing 'source code’ means “a program in a source language.” [28] In order to be executed by a computer the source code has to be converted first into machine-readable object code. Conventional source languages are text-based and human-readable. Source languages are not static but dynamically connected to the state-of-the-art of programming implying that older source languages become less relevant meanwhile newer source languages are adopted [42]. The ordinary meaning of source code is potentially very broad covering inter alia any kind of computer program, software system and even the software architecture of entire online platforms expressed in a source language [21].

Whether the term ‘source code of software’ can also be interpreted as covering computer and machine learning algorithms will be established next.

“Coding […] consists of two key translation challenges centered on producing algorithms. The first is translating a task or problem into a structured formula with an appropriate rule set (pseudo-code). The second is translating this pseudo-code into source code that when compiled will perform the task or solve the problem.” [24]

The answer is straight forward when it comes to ‘hand-coded’ computer algorithms where human software engineers program the decision-making rules in a source language. What would not be covered by the term ‘source code’ is the more conceptual version of the algorithm before it is turned into a source language.

Machine learning algorithms by contrast are increasingly not ‘hand-coded’ and may no longer use a text-based source language. Predictive models can for example generate source code automatically or they are expressed in graphical languages as opposed to text-based. As [21] stipulates:

“That does not appear to disqualify visual programming languages and machine-generated code from the ordinary meaning of source code since they are listed as latest developments in programming languages.”

It follows that the ordinary meaning of ‘source code’ does not have a clear demarcation that would categorically exclude computer algorithms expressed in source code, be they hand-coded or automatically generated. That certain FTAs [2, 39] explicitly mention ‘algorithms expressed in source code’ does help to clarify but may ultimately not be decisive for concluding that computer algorithms expressed in source code are covered anyway. In practice, the ‘source code’ of computer algorithms is licensed [35], required for reproducibility [20] and also used in official documents on algorithmic governance.

Another, often overlooked aspect of protecting source code inside digital trade law is that Application Programming Interfaces (APIs) are also expressed in source code. APIs provide the gateways through which the algorithm receives its inputs and queries as well as produces some sort of output [34]. This matters because API access may turn out to be crucial to carry out non-invasive introspection that does not require access to an algorithm's source code as such.

As initially explained each provision prohibiting access to source code of software comes with different exceptions attached. As a first line of defense, the custom-made exceptions that are inscribed in the same clause serve to counterbalance the general prohibition. A second line of defense is the possibility to justify a trade law violation pursuant to the general exceptions for general interest measures and the security exceptions that are standard for FTAs. As a result parties to a FTA are bound by a rule prohibiting government-mandated access to source code of software, unless one of the custom-made exceptions to this rule applies or the violation of the rule can be justified.

A comparison of the custom-made exceptions to the prohibition of government mandated access to source code of software reveals:

“a shared recognition that source code disclosure may be required to ensure compliance and enforcement of laws, but differences when it comes to the particular legal or public interests explicitly recognised by individual agreements.” [12]

A recurring exception has been inscribed for a requirement by a court, administrative tribunal, or a competition authority in order to meet regulatory and judicial needs. The EU-UK TCA specifies that the prohibition does not prevent “a requirement by a court or administrative tribunal, or … by a competition authority” [37]. Another inroad inscribed as an exception is “a requirement by a regulatory body pursuant to a Party's laws or regulations related to the protection of public safety with regard to users online” [37]. The US-led FTAs [2, 39] are more stringent in that source code must be required for “a specific investigation, inspection, examination, enforcement action, or judicial proceeding”. In spite of the different formulations used this type of custom-made exception is limited to judicial and regulatory powers that are applied on a case-by-case basis in the context of ex post regulatory enforcement or judicial remedies. It implies a recognition of qualified transparency which would authorize regulatory authorities and domestic courts to request access to source code of software for investigations that would selectively override business secrets of developers and providers.

The thrust of this source code clause are general laws that require transfer of, or access to software source code that can't be already excepted under the first line of defense. Legislation that mandates conformity assessments, certification schemes or standardized APIs would be inconsistent with the protection of software source code inside trade law. Besides, the custom-made exceptions exclusively qualify government bodies to make a requirement for software source code, however, subject to requiring safeguards against unauthorized disclosure. In addition to diverting from the important role of independent private expertise for algorithmic accountability, legislation that would enable public scrutiny by academics, media, critical engineers and civil actors would not be recognized under such a trade law clause.

Following the second line of defense, two different exceptions on grounds of security interests and general interests are typically inscribed in FTAs that can be invoked to justify an inconsistent measure. As a rule of thumb, invoking the exceptions on grounds of a party's security interests is less demanding as compared to the more rigorous legal test required to meet the general exceptions. One can imagine the margin of discretion to adopt measures in pursuit of a general interest objective as the hole in a doughnut that is “left open by a surrounding belt of restrictions” [13]. The burden of proof is placed on the party that seeks to justify an inconsistent measure in pursuit of a general interest objective. The contemporary lack of international standards and consensus on algorithmic governance increases a party's legal risk that an attempt to justify an inconsistent measure on ground of the general exceptions does not succeed.

Whenever this new clause is inscribed in a FTA government-mandated access to source code of software becomes subject matter of international trade law, even if this measure does not afford discriminatory treatment or impedes market access. The margin of discretion a government retains to adopt measures that require access to source code of software is confined to the policy space that is allowed by the FTA. New tensions are bound to arise between domestic regulation and a FTA's source code protection:

“The source code clause is too broad for domestic digital policies that need to build on interoperability, accountability, and verifiability of digital technologies.” [21]

Turning to algorithmic governance, the source code clause stands in the way of a legal requirement that mandates independent audits or access to standardized technical interfaces in the interest of auditability, scientific research and public scrutiny. A FTA's source code clause has thus real implications for the domestic policy space at a moment that concepts of and approaches to algorithmic governance are still evolving.

Public policy and regulation has an important role to play in providing incentives for rigorous impact assessments and testing before introducing a new algorithmic system that can affect individuals and society. Supervision and enforcement of compliance with domestic regulations and individuals’ rights continue to play an important role after an algorithmic system has been deployed. Besides, developers and providers have to resume accountability for the predictive outcomes of algorithmic decision-making systems they implement as well as legal responsibility for its lawful operations. Governance of algorithmic systems requires mechanisms that can hold developers and providers accountable with algorithmic audits being the most aspirational solution [40]. While not all auditing types require access to source code, a government can adopt regulation that mandates code audits, especially in high stakes deployments and in order to mitigate individual or collective harm.

Auditing an algorithmic system that involves an analysis of its source code requires resources, specialized knowledge and access to proprietary information. This method can be fruitful in a highly targeted investigation to identify the source of an existing concrete problem. This type of code review has for example successfully been used by US academics to identify the offending section of code in the US investigation of the Volkswagen Diesel nitrogen oxide emission cheating scandal [19]. The proposal for an EU Artificial Intelligence Act [16] proposes to introduce conformity assessments before ‘high risk’ artificial intelligence can be placed on the Union market. Under the proposal, designated bodies would be tasked with conformity assessments which will primarily be based on reviewing documentation but can also involve a review of the source code. As a regulatory design the risk based approach to mandating conformity assessments is better attuned to meet the general exceptions in FTAs; however, a broader regulation may not fit the margin of discretion left to the government. Also other public interest regulations will have to cope with the increasing adoption of algorithmic agents that can require updating regulation to mandate independent audits. This covers the entire spectrum of regulatory regimes ranging from consumer protection law to antidiscrimination law, product liability, unfair commercial practices laws, medical regulations and many more.

Access to the technical interfaces of the algorithmic system can be a means to carry out non-invasive introspection that does not require access to an algorithm's source code as such. In order to carry out more sophisticated testing experts must gain access to input and output data as well as to the respective technical interfaces. However, in many situations developers and providers treat APIs just as proprietary as the algorithms behind them. Moreover the trade law protection vested on source code of software does shield APIs from government mandated access too.

Proposals on algorithmic accountability underscore the role of APIs for auditing algorithms, setting up accountability APIs or observe the algorithmic system in a sandbox setting [10, 21, 32]. It is not a coincidence that the potential of requiring access to interfaces of algorithmic systems for accountability purposes is discussed across several domains, such as competition law, antidiscrimination law, online platform regulation and broadly algorithmic governance. Public-facing or internal APIs can be of strategic importance for ensuring the accountability and trustworthiness of algorithmic decision-making systems.

Committing to a trade law clause that would make it harder to engage with AI systems via these interfaces or mandate standardized interfaces in the interest of auditability is counterproductive. [21]

While algorithmic governance would benefit from “regulation towards auditability” [34] digital trade law by contrast curtails regulation requiring non-invasive access to the technical interfaces of algorithmic systems. Consider in this context the EU proposal for a Digital Services Act (DSA) which, if adopted, introduces access to data of very large online platforms for vetted researchers either through online databases or APIs [17]. What could become an important precedent for researchers’ access to an API in order to scrutinize an algorithmic recommender system would be deemed inconsistent with the source code clause. Whether the general exceptions for measures on grounds of general interests can be invoked in justification of researchers’ access via an API is by no means certain.

The protection of source code is a strange guest in digital trade chapters of FTAs. After all, source code of software can be copyright protected and may qualify as a trade secret. For reasons of consistency source code protection would be more appropriately dealt with inside the WTO Intellectual Property (TRIPS) Agreement [43]. Following TRIPS Article 10.1, computer programs, whether in source or object code, qualify for copyright protection. Parties to TRIPS had to align their national laws in order to afford copyrights protection of computer programs in their domestic laws and via its dispute resolution procedures the TRIPS is enforceable.

Next to qualifying for copyright protection, source code can also be protected as a trade secret under the TRIPS agreement. An explanatory footnote in the USMCA [39] for that matter clarifies that “software source code's status as a trade secret” shall not be negatively affected “if such status is claimed by the trade secret owner.” The explanatory footnote aims to ensure that source code of software continues to be treated as a trade secret in the case of disclosure in the context of a regulatory investigation, enforcement action or judicial proceeding, requiring safeguards against unauthorized disclosure.

Last but not least, digital trade law is not cognizant of open source licenses even though they are widely used in practice to share source code and computer algorithms [29]. The clause on source code of software prohibits government mandated access of source code of software; thereby overriding what has been open source by origin. The upshot is that the source code clause in FTAs creates an additional sui generis right that, next to copyright protection and trade secret law governments ought to respect, shields software source code from being interfered with by governments.