The Supreme Court’s recent decision in Google LLC v. Oracle America, Inc. has provided the latest word on an issue that many have described as “interoperability,” and it comes at a time when lawmakers around the world are debating a policy called “interoperability” with respect to major Internet platforms. At first glance, these two similarly named policy conversations—copyright protection of software interfaces and interconnection among competing Internet platforms, respectively—have little to do with each other. Yet they are vitally intertwined: the activities and issues featured in Google are so closely linked to the questions of digital competition that interoperability reforms directed to the latter cannot be achieved effectively without also addressing the former.
This close tie between two aspects of interoperability has a perhaps surprising implication: Congress can and should expand upon the recent Google decision as part of its larger efforts to induce competition in the social media and major technology platform markets. Barriers to replication of software interfaces, such as copyrights in Google, can stymie the robustly competitive digital landscape that lawmakers hope to achieve through interoperability legislation. Drawing from history and current policy, this Article proposes ways that Congress can respond to the Google decision, ranging from developing copyright-free government standards to revising the Copyright Act.
Introduction
“You keep using that word. I do not think it means what you think it means.”1 It would not be inconceivable to say such of “interoperability,” a term notoriously difficult to define.2 Indeed, the term is central to two important contemporary issues of legal policy that seemingly have nothing to do with each other and use interoperability to mean apparently different things.
The first of these issues is a matter of computer software and copyright law. In its recent decision in Google LLC v. Oracle America, Inc., the Supreme Court grappled with whether Google, in building its Android mobile platform, was allowed to copy certain portions of computer code from the Java programming language.3 The portions of Java that Google copied were not arbitrary, but were specifically selected to help knowledgeable Java programmers transition more easily to writing for the Android platform.4 Insofar as this copyright question involved the ability of programmers and their code to operate between (inter-) two different platforms, commentators have widely described the case and the related software copyright question generally as a matter of interoperability.5
At nearly the same time, lawmakers and policy experts around the world have debated another idea called interoperability: regulatory requirements that dominant Internet platforms, especially in social media, enable rival firms to connect with those platforms, thereby enabling greater competition.6 A notable example is the recent report from the staff of the House Judiciary Committee, proposing “[a]n interoperability requirement [that] would allow competing social networking platforms to interconnect with dominant firms to ensure that users can communicate across services.”7 Such a requirement, characteristic of other interoperability proposals,8 “breaks the power of network effects” that entrench dominant digital platforms and thus enables greater competition, as the report contends.9
Despite sharing common terminology, these two policy issues have not been recognized as connected in either policy debates or scholarly literature. Recent commentary on digital platform interoperability rarely notes software copyrights as a relevant concern.10 While research on software copyrights recognizes competition concerns at a high level, the connection to contemporary social media and digital platform regulation has not been strongly made.11 Indeed, critics of the Supreme Court’s Google decision claim that it will entrench dominant Internet platforms, apparently setting the first type of interoperability at cross-purposes with the second.12
Yet, I contend they are closely tied. Interoperability in the social media sense, often also called “interconnection,” can only achieve the objectives that lawmakers seek if it is legislated in tandem with interoperability in the Google sense, otherwise called “reimplementation.” The complex relationships among participants in digital markets mean that interconnection requirements alone will not undo—and in fact may entrench—monopoly power; a serious approach to competition requires a digital ecosystem that can only be achieved if reimplementation is permitted unfettered.13
Corollary to the dual nature of interoperability is the perhaps surprising possibility that lawmakers ought to be motivated to expand upon the Supreme Court’s decision through legislation, given their interest in digital platform interconnection.14 History shows that addressing both reimplementation and interconnection is not only possible but in fact common, and legislators have a range of options to do so.15
I. Interconnection: Telephone Networks and Social Media
In the context of communications law and more recently social media platform policy, interoperability generally refers to the ability of third-party services to communicate with an existing, often dominant platform or system.16 I will use the term “interconnection” to refer to this arrangement.17
A. Historic Telephone Interconnection
Interconnection has long been a matter of concern for telephone networks.18 The earliest telephone networks notably did not feature interconnection: the dominant Bell network was not connected to its so-called “independent” competitor networks, and one who wanted service from both Bell and an independent needed to have two separate wires and two separate telephone handsets.19
Dissatisfaction with the duplicative nature of the telephone networks led to the 1913 Kingsbury Commitment, in which AT&T agreed to a limited amount of interconnection where independents could place (but not receive) calls over AT&T’s long distance wires.20 While contemporaries hailed the commitment as a win for competition, the limited interconnection that AT&T offered in fact increased the company’s monopoly control, ultimately leading to the demise of most of the independents.21 Interconnection was subsequently seen as a component of deregulation of the telephone industry in the 1980s, the theory being that opening up AT&T’s networks to calls to and from rival networks would enable competition and reduce the need for monopoly regulation in the industry.22
B. Interconnection and Social Media
More recently, interconnection has become a key part of the debate over social media and Internet platform dominance. In view of widespread perceptions that digital platforms have become extremely concentrated,23 policymakers and commentators have called to limit the top firms’ power either through application of antitrust law or with new legislation.24
Often comparing those platforms to AT&T’s dominant telephone network, many commentators consider interconnection to be a potential solution.25 By way of example, a dominant social media platform might be required under such regulations to allow competitors to send and receive email-like messages between their respective users.26 To do so, the dominant platform would have to open itself up to competitors’ transmissions in much the same way that AT&T opened itself up to telephone call transmissions from competitors.
Governments around the world are giving extensive attention to interoperability. A report commissioned by the European Commission Directorate-General for Competition deals extensively with interoperability policy,27 and E.U. Commissioner for Competition Margrethe Vestager indicated that she would take the report’s recommendations under close advisement.28 The U.K. Competition and Markets Bureau has also investigated interoperability in depth,29 as has the House Judiciary Committee.30 Several members of Congress have cosponsored legislation to mandate interconnection by major social media platforms.31 And the omnibus privacy laws in Europe32 and California33 both include provisions on data portability, a rudimentary form of interconnection insofar as data can flow from one platform to a competitor, albeit slowly in the hands of end users.34 Interoperability in the sense of interconnection is thus high on the agenda of many legislators interested in competition and technology.
II. Reimplementation: Google and Software Interfaces
A seemingly different type of interoperability is at play in the world of software copyrights and the Google case: reimplementation, a particular form of copying in order to enable compatibility. As the Supreme Court defined the term, reimplementation is “the building of a system that repurposes the same words and syntaxes of an existing system,” such that users of the existing system can switch over to the new one with minimal effort.35
A. The Facts of Google
The facts of Google highlight what reimplementation is and, more importantly, why it happens.36 Oracle is the successor in ownership to a collection of computer software programs called the Java API, which is capable of accepting various commands to perform certain useful computations.37 So that third-party programs can invoke these computations, Oracle’s software lays out specific expectations for what those programs must include—names of commands, filing labels called “packages” organizing those commands, what information needs to be given for each command, what the program should expect to get back from the command, and so on.38 These expectations are set forth in a terse, precise, well-defined language, which when written out are what the litigants have described as “declaring code.”39
Google, in developing its Android mobile phone platform, wanted to allow programmers to command its platform to perform computations similar to parts of the Java API.40 To do so, Google also needed to lay out its expectations for how to invoke those computations in declaring code.41 Google wrote its declaring code in parts to be nearly identical to those in Oracle’s software, so that programmers experienced with the Java API could also write for Android with minimal or perhaps no changes to their expectations and preexisting knowledge.42
Google thus built a system “‘that repurposes the same words and syntaxes’ of an existing system,”43 namely the declaring code of the Java API, to ensure that other, external users or programs could switch between the two. The command words, symbols, and syntaxes that enable communication between a system like the Java API and its users are what computer scientists call an “interface,”44 and copying interfaces to facilitate third-party switching is the heart of reimplementation.
B. History of Reimplementation
Like interconnection, reimplementation has a storied history. Coded symbols for issuing commands have existed at least since Aeneas Tacitus described the hydraulic telegraph in the fourth century B.C.,45 and reimplementation of command symbol systems can be found everywhere from naval flag signaling to telegraph ciphers to hospital color codes.46 More recently, modern Internet technical standards are systems of command words that are reimplemented in ways legally indistinguishable from Google’s acts in Google.47 Indeed, Oracle itself has reimplemented interfaces devised by IBM and Amazon, both times to enable users of those firms’ dominant technologies to switch over to Oracle’s competing products with minimal disruption.48
Courts have struggled mightily on the question of whether reimplementation is copyright infringement. Baker v. Selden, the seminal case on the idea-expression dichotomy, is arguably a reimplementation case insofar as Baker’s copies of Selden’s accounting forms enabled accountants familiar with the latter forms to also fill the former.49 Mitel, Inc. v. Iqtel, Inc. involved a system of numerical codes that defined commands to a telephone calling system, which the Tenth Circuit found not copyrightable;50 Practice Management Information Corp. v. American Medical Ass’n involved a system of numerical codes that defined commands for medical insurance reimbursement, which the Ninth Circuit held copyrightable.51 Lotus Development Corp. v. Borland International, Inc. offered an ideal opportunity to resolve the question, as the case involved a claim of copyright to a spreadsheet program’s menu command names that programmers could use to automate data processing.52 The First Circuit rejected the copyright claim,53 but on a granted certiorari petition the Supreme Court split four-to-four and established no precedential opinion on the question.54
C. The Supreme Court Decision and Remaining Questions
Google is the latest word on whether reimplementation is copyright infringement. The case presented two questions based on separate decisions of the Federal Circuit:55 whether the declaring code was proper subject matter for copyright protection in view of 17 U.S.C. § 102(b), as the Federal Circuit held;56 and whether Google’s reimplementation of it for Android was fair use, contrary to the Federal Circuit’s holding that it was “not fair as a matter of law.”57 The Court declined to address the former question,58 and resolved the latter in favor of Google, holding its act of reimplementation to be fair use “as a matter of law.”59
As an initial matter, the majority opinion by Justice Breyer observed that fair use has “an important role in determining the lawful scope of a computer program copyright,” and that fair use serves a “basic purpose of providing a context-based check that can help to keep a copyright monopoly within its lawful bounds.”60 Turning to the four statutory factors for fair use under 17 U.S.C. § 107, the Court found that they all favored fair use, largely relying on the fact that the declaring code’s value lay in programmers’ investment of time to learn the names of commands rather than the expressive creativity of the code,61 the value that Google’s reimplementation created in offering a novel platform for the creation of new software,62 and the public benefits of innovation and competition resulting from reimplementation.63
Although the Court’s holding resolved the case in favor of Google, there are still open questions about reimplementation. Since the Court relied on fair use to resolve the case,64 a future litigant could assert copyright infringement against a reimplementer and argue that Google is distinguishable on its facts, a possibility made likely by the “notoriously fact sensitive” nature of the fair use inquiry.65 And the question of copyrightability of interfaces, which the Court declined to resolve,66 will likely not converge on an answer any time soon, particularly given that the appellate court most likely to decide the issue is one that binds no regional circuit court and yet one that, as a practical matter, is likely to receive every interface copyright case in view of forum shopping strategies.67 While the Supreme Court’s decision cleared much of the air over reimplementation and copyright, the cloud of concern cannot be said to have been fully lifted yet.
D. Other Barriers to Reimplementation
Purported copyright protection of interfaces is not the only barrier to reimplementation. Other intellectual property rights, most notably patents, can prevent competitors from reimplementing interfaces necessary for compatibility with third-party products.68 There are numerous patents on multimedia storage formats, for example, which might prevent competing music players from opening Apple audio files.69
Firms may also use contractual terms or digital rights management technologies to prevent competitors from reimplementation.70 Indeed, companies often assert the Computer Fraud and Abuse Act (CFAA)71 to undermine competitors’ ability to retrieve information otherwise available online.72 One can imagine using the CFAA against reimplementers.73
Between trailing uncertainty in the wake of Google and non-copyright legal regimes, there are plenty of barriers that a firm could put up to prevent reimplementation. To the extent that reimplementation is virtuous in terms of policy, then, legislators have work to do even after the Supreme Court’s decision. But is reimplementation good public policy? It is to that question that this Article now turns.
III. Interconnection Requires Reimplementation
If interconnection is desirable policy, as many legislators and experts believe,74 then removing barriers to reimplementation must also be on the legislative agenda. That is because, despite their facial differences, interconnection and reimplementation are perhaps as the Dread Pirate Roberts was to the farmhand Westley: two components of a unified interoperability whole, such that the former entails the latter.75
Initially, it may seem that interconnection does not require reimplementation. A major social media company could interconnect with all of its smaller competitors without the means of connection being standardized; Facebook could have one set of commands for working with LinkedIn, another set for Twitter, another for TikTok, and so on. Yet while fragmented interconnection is theoretically possible, the need for reimplementation grows out of the overall motivation for interconnection: to increase competition and reduce the influence of dominant firms in information technology markets.76 To see why interconnection policy can achieve robust competition only in tandem with freedom to reimplement, I begin by outlining a framework of interconnection, and then consider how competition policy works within that framework.
A. Horizontal and Vertical Interconnection
Drawing from antitrust law,77 interconnection between any two services may be described as “horizontal” or “vertical.” In a horizontal relationship, the connected services are market substitutes that serve similar consumers.78 The purpose of interconnection is to enable one service’s consumers to access the other service’s resources—enabling users of Facebook to direct-message LinkedIn users, for example.
By contrast, a vertical relationship is present between systems and upstream or downstream users: mobile phone operating systems and the apps that run on them, for example, or a social media platform and its users who produce posts and other content.79 As with the antitrust notion of verticality, the term refers to relationships between producers and consumers.80 But the unusual bidirectional nature of information technology makes it sometimes unclear who is which: users both produce content on Facebook and consume it from the platform, for example.81
B. Reimplementation and Vertical Interconnection
To see where reimplementation fits in, consider first vertical interconnection, say between a social media platform and the apps atop it. Many proponents of interoperability policy favor opening up vertical interconnection as a first step.82
But without a right of reimplementation, vertical interconnection could actually enhance the platform’s dominance. In order to grow, a startup social media platform would need to attract apps on the dominant platform to switch over.83 If the startup uses an incompatible app interface, then the costs of rewriting apps for the startup platform would likely dissuade switching and stunt the new platform’s growth.84 Reimplementation of the app interface thus takes on outsized importance to the competition that vertical interoperability enables.
C. Reimplementation and Horizontal Interconnection
This value of reimplementation for switching vertical relationships over to competitors is reason enough to facilitate reimplementation as a policy matter. But the switching cost problem also shows the need for reimplementation in purely horizontal contexts.
A startup competitor to a dominant platform would want not only to interconnect with the dominant platform but also with other intermediately successful competitors.85 A newly launched social media messaging service, for example, would need to exchange messages not only with Facebook but also with LinkedIn, Twitter, TikTok, and others. If the command names that LinkedIn uses to interoperate with Facebook were copyright-protected, however, someone (either LinkedIn or the new service) would need to devise new commands for message exchange between the new system and LinkedIn. Multiplied over all other systems, the costs of development for new entrants to a “fragmented” ecosystem of incompatible interfaces would likely also defeat competition.86
Accordingly, insofar as the goal of interconnection policy is robust competition, reimplementation must be a part of that policy. Without it, competition on vertical market features such as app stores would be hindered by switching costs and lock-in effects, and horizontal competition would be limited to an oligopoly of a few large firms.
IV. Implementing Reimplementation
To obtain the sorts of competitive digital markets that interoperability-bent policymakers desire, policymakers must consider how to facilitate reimplementation. This Section considers several case studies and options for doing so.
A. Case Studies
1. Power Frequencies
Historically, interoperability efforts have involved both reimplementation and interconnection. One early example involved the changing of the power grid in Southern California in 1948.87 Prior to then, most of the country’s power plants output alternating current at a frequency of 60 Hz, but the Mill Creek plant serving Southern California operated at 50 Hz, and power plants built in the area thereafter used the same unusual frequency.88 Appliances such as electric clocks occasionally relied on the electrical frequency and so had to be built differently for California than the rest of the country; a New York clock brought to Los Angeles would literally slow down.89
When the region finally decided to modernize so that it could receive electricity from the newly built Hoover Dam, it was changing its interconnection expectations—the wires would now transmit at 60 Hz rather than 50—and so it had to deal with a reimplementation problem as well, in the form of updated appliances.90 Southern California Edison exchanged hundreds of thousands of clocks, lights, and refrigerators to ensure that every appliance in service used the standard 60 Hz frequency—essentially ensuring that California appliances were reimplementations of those on other electric grids.91
2. Digital Television
While intellectual property was not of concern in the electric frequency switchover—a single frequency cannot be copyrighted—it would figure prominently in other government interoperability efforts. Around the turn of the twenty-first century, the United States embarked on a massive conversion of the broadcast television system from analog to digital signals, a process called the “DTV transition.”92 As part of that transition, the Federal Communications Commission (FCC) issued regulations mandating that television manufacturers and broadcasters comply with a collection of technical standards promulgated by the Advanced Television Systems Committee (ATSC) for digitizing broadcast signals.93 The DTV transition thus illustrated the close tie between interconnection and reimplementation: at the same time that the FCC was instructing broadcasters and device manufacturers on how to interconnect with each other, it was also requiring those firms to reimplement the commands and signals promulgated in the ATSC standards.94
If ATSC had been able to wield unfettered intellectual property rights over its standards, then the FCC action would have rendered the entire television ecosystem beholden to that one industry consortium.95 Keenly interested in avoiding the monopolization of the television industry, the FCC indicated its intention to scrutinize ATSC’s intellectual property practices.96 The agency observed ATSC members’ promises to license patent rights to its standards on fair, reasonable, and non-discriminatory terms, and reserved power to intervene if ATSC or its members failed to abide by those promises.97 This concern carries over to the present day: as the FCC considers upgrading its regulations to the newer ATSC 3.0 standards, it continues to rely on promises of fair patent licensing and has noted its willingness to step in otherwise.98
3. Electronic Health Records
Probably the most comprehensive recent interoperability effort explicitly recognized and dealt with reimplementation. Electronic health records (EHR) have tantalizingly promised the possibility of a revolutionized health care system, but adoption of that technology has been stymied because EHR system vendors have not made their systems interoperable, instead using technical and legal means to prevent patients and hospitals from bringing records to or viewing them on competitors’ systems.99 In the 21st Century Cures Act,100 Congress directed the Department of Health and Human Services to prohibit these practices of “information blocking” through regulations,101 and also to establish national standards for EHR interchange.102
The wide-ranging “interoperability” rules, finalized last year, address both interconnection and reimplementation in detail.103 The section addressing information blocking strictly limits the permissible reasons for which an EHR vendor may restrict the flow of information to a competing system or to a third-party application, thereby limiting barriers to interconnection among those systems and applications.104 Further recognizing that interoperability may require competitors or third-party applications to engage in reimplementation, the information blocking rule constructs a detailed intellectual property licensing procedure,105 including requirements that royalty rates be fair, reasonable, and non-discriminatory.106
As these examples show, policymakers looking to introduce interoperability into technology markets have addressed not only interconnection but also reimplementation to ensure success in achieving their objectives of greater competition and consumer choice. Lawmakers hoping to achieve those goals today should similarly consider a dual-pronged approach of promoting both interconnection and reimplementation.
B. Legislative Options
Lawmakers have a variety of options for enabling reimplementation in social media and Internet platform markets. This Section considers three such options: mandatory compliance with particular communication standards, conditions upon a class of dominant firms, and general abrogation of legal barriers to replication.
To aid in this discussion, consider an example policy of enabling person-to-person messaging among multiple platforms—a Facebook message, say, being deliverable to a LinkedIn user and vice versa. Obviously other policies for opening up social media and Internet markets will face different considerations, but this example is effective in showing both faces of interoperability: the different messaging platforms obviously must interconnect with each other, and they ought to reimplement interfaces to ensure interchangeability and thus robust competition.
1. Government-Adopted Standards
The case studies show that standardization is often a way of mandating interconnection and enabling reimplementation in tandem. Thus, to guarantee a right to reimplement, the government could devise technical standards of commands and syntaxes and then require or otherwise encourage firms to comply with those standards. For example, a federal agency could draw up protocols for message exchange and require that social media firms accept communications in compliance with those protocols. Since the government cannot hold copyrights in its own works and could otherwise abstain from asserting rights in the standards,107 firms would face potentially no barriers to reimplementing them.
A serious concern with government-developed standards, however, is that federal regulators do not necessarily have the technical expertise or industry experience to know how to craft them effectively.108 As a result, such standards are largely prohibited under current executive policy.109
A better option, widely used in government today, would be to delegate the actual construction of the standard to a private industry consortium.110 Both the EHR interoperability regulations and the ATSC standards adopted during the DTV transition fit this pattern.111 In this case, though, privately held copyrights and other intellectual property interests could hold up reimplementation.112 Contractual arrangements by the standard-setting industry consortia, often called “FRAND obligations,” could alleviate these barriers to reimplementation.113 However, existing FRAND obligations often fail to address copyrights,114 and in any event the scope and effect of these contracts is heavily disputed and uncertain.115 Furthermore, even industry-devised standards may lock in present technologies and limit future innovation,116 and they may favor large, dominant firms that can heavily influence standard-setting consortia.117 Mandatory interoperability standards, whether authored by the government or private industry, are at best a limited strategy for bolstering competition.
2. Conditions upon Regulated Firms
Rather than enabling reimplementation of particular interoperability standards, it may be better to enable reimplementation of any interface that a dominant firm adopts to serve a certain market. For example, Facebook might be required to provide a public set of commands for messaging and allow any competitor to access it without charge. This approach has been used in the past, as a condition of the merger between America Online and Time Warner for example,118 and it is currently being proposed in Congress.119 Under such an approach, the dominant firm would be required to waive or cheaply license any intellectual property rights needed to replicate the necessary interoperability commands or protocols, and otherwise not inhibit reimplementation.120
By contrast to technical standards adoption, a requirement that a dominant firm permit reimplementation does not lock industry into a particular technology, enabling further innovation. But applying policy only to firms after they achieve market dominance essentially fixes that policy one step behind the ball. While interoperability can encourage competition against a monopoly player, other network effects and switching costs may nevertheless still give the dominant firm an edge and keep competitors at bay.121 Better would be policy that encourages interoperability before dominant players arise, thereby achieving the benefits of competitive markets from the start and avoiding the need for remedial, likely imperfect, action after the fact.
3. Legislating on Software Copyrights
Prospective achievement of interoperability and competition might best be achieved by removing barriers to reimplementation entirely. Congress could expand upon the Google decision by answering the undecided question of copyrightability of interfaces, thereby ensuring that reimplementation is not hindered by copyright law.122 It could further review other laws such as the CFAA that can inhibit reimplementation.123
Obviously, these measures would enable reimplementation to the greatest extent. The question is whether they would go too far, perhaps coming at the expense of other policy interests. In particular, one might worry that diminishing exclusive intellectual property rights would diminish incentives to create new interfaces, since competitors can “freeload off of” them.124
This concern is minimized by several considerations. For one thing, incentives to create interfaces would seem unnecessary—a programmer writing software must produce an interface for it if that software is to be used at all.125 It is also not clear that reimplementation of interfaces always harms the creator’s market; many software firms in fact seek to have their interfaces incorporated into open standards to expand their markets and attract consumers.126 And any concern about diminished incentives must be offset by the downstream benefits of compatibility and innovation that arise from reimplementation.127
More importantly, a page of history is worth a volume of intellectual property theory. Despite legal uncertainty about the copyrightability of computer software interfaces, the information technology industry has proceeded on the assumption that reimplementation was legally permissible since the dawn of that industry.128 Even Oracle’s flagship database product reimplemented the commands and syntaxes of IBM’s SQL interface,129 and evidence from public licensing policies shows that top industry professionals and the federal government have long believed that patents were the only intellectual property relevant to reimplementation of technical standards.130
And yet there has been no shortage of production of interoperability interfaces. “Open Internet standards” by the thousands can be “implemented around the world in all kinds of Internet products and services,” which the Internet Society describes as “the cornerstone of the Internet’s success.”131 The success of the Internet, built on unhindered reimplementation of millions of lines of software interfaces made freely available, rebuffs the notion that such interfaces will not be produced absent intellectual property rights.
In sum, an expansion of Google to further remove barriers to reimplementation would likely not affect the production of interfaces, and it will most effectively allow Internet platform competitors to rise without locking in existing technologies in the ways that predefined standards might do. In tandem with interconnection, broad rights to reimplement could create the highly interoperable, competitive digital landscape that many lawmakers and policy experts would like to achieve.
Conclusion
Defining interoperability is no simple task: an extensive study of the subject finds “no one-size-fits-all definition” and exhorts the reader to “explore a broader understanding” of interoperability “in different contexts and at different levels.”132 Toward this broader understanding, this Article contributes a characterization of the relationship between interconnection and reimplementation, two elements of interoperability that at once seem entirely different and yet are closely linked.
As policymakers look to interoperability as a tool for enhancing competition, innovation, and consumer choice, they will need to ensure that pro-interoperability policies address reimplementation. History shows that both can be addressed,133 and this Article has presented several options for ensuring that reimplementation is enabled in tandem with interconnection. In particular, legislation addressing interface copyrights may have a profound effect on overcoming market concentration in the technology industry.134 The confluence between interest in social media interoperability and the Google decision could thus produce, in the words of one impressive clergyman, a legislative “mawidge” that “is what bwings us togevver today.”135