Below, we have provided the full transcript of the panel discussion, Open v. Closed Ecosystems from an Antitrust Perspective, from the final episode of our series, Antitrust In an Election Year: Challenges Ahead.
Richard SCHMALENSEE:
I believe it’s time to start the panel discussion. Our topic today is closed versus open ecosystems from an antitrust perspective. We have three distinguished panelists to explore this issue, this topic. Maureen Ohlhausen from Baker Botts, Darren Tucker from Vinson & Elkins, and Hal Varian from Google. Those of you who are participating in hopes of seeing Nikhil Shanbhag from Facebook will be disappointed because he had to cancel at the last minute.
This is an area in which there are a lot of buzzwords, and terms are thrown around as if their definitions are well understood, but to paraphrase Barney Frank, while we’re all entitled to our own opinions, we shouldn’t all be entitled to our own definitions. So I want to ask the panelists when they make their opening remarks to say a word or two about what makes an ecosystem open or closed. Is the key the role of open standards? Something else? A number of things? Let’s lead off with Maureen.
Maureen OHLHAUSEN:
Well thanks Dick, thanks for having me. I’m delighted to be here to speak. On the question of what’s an open system or a closed system, I think those are more terms of general description than of falling into any particular bucket. But the way I often think about it is when you go back to the old IBM operating system, which we had an openness, and then Apple had a very different approach, or you might see a different between a standard setting organization where as long as you design to the standard you can plug in and you can be part of the ecosystem versus one where it’s controlled through a single manufacturer, or a single entity. But more important, not more importantly, but as part of that discussion, I think one of the issues that’s really coming to the fore these days is whether open systems or closed systems, one is pro-competitive or one is anti-competitive, and should antitrust be favoring one over the other. And from my viewpoint, both have pluses, both have minuses, and antitrust shouldn’t be picking to say, “Well, we only want one kind of system.”
SCHMALENSEE:
Okay. You have more time should you wish to take it.
OHLHAUSEN:
Oh, okay. So I wasn’t sure if you just wanted me to answer that one question to start off.
SCHMALENSEE:
No, no, no, no, no, I thought you might preface your general remarks with a discussion of that issue. Sorry.
OHLHAUSEN:
Great. Well, talking about a recent, the House Judiciary Committee Staff Report. It kind of critiques, I think, both open and closed systems if they created some complaints by some other businesses because they like how that particular system included them, or what terms they included them, or if they excluded them. And I have some concerns, certainly, about basing an antitrust analysis simply on the idea that there’s some business out there who’s unhappy about the way he, or she, or it was treated. And as I said, antitrust shouldn’t favor either open or closed systems. We should let the market evolve, let these choices… Because sometimes we’ve seen consumers want one, or consumers want the other, or there’s a lot of innovation in one area, or sometimes it swings to the other area. What antitrust law should really be focused on is whether there is some exclusionary conduct going on. Something that is not competition on the merits that keeps out another player from the market, not by having a better system or better options for consumers, but somehow closing down, not through being the better competitor, access to the market.
So while I wouldn’t say it was an open or closed system case, one of the ones that I like to think about in this area is a case that we brought when I was at the FTC, the McWane case, which had to do with a dominant player who locked up the distribution channels for a particular product, and it had a requirement for the distributors. It happened to be for certain types of plumbing supplies, but they had a very high market share in there, and what they said through their contracts to these distributors is if you carry a competitor’s product, you can’t carry any of ours. And so they weren’t adding anything like “because we’re giving you supports” or “we’re sharing in the marketing,” or something like that. It was just a “If you carry them, you can’t carry us.” And so the FTC brought a case and ultimately the commission, it had a lot of counts, but it just upheld on that count. And then the 11th Circuit actually upheld the FTC’s approach there. So just to say that focusing on exclusionary conduct is, I think, the right approach, rather than saying, “We favor open systems over closed systems.”
One of the other things that I want to mention is that the House Judiciary Report talks about we want to allow more entrance into the market, so we’re going to require access to facilities. Essentially, they don’t quite say it this way, but it’s essentially the essential facilities argument, the idea that well, these facilities, these platforms, these capabilities have become so important that antitrust should, or regulation but I think it’s antitrust, what they’re talking about, force access to these systems. And then of course you have to then do equal terms, and at what cost? Because all the things that would be required. And I have big concerns about the idea of an essential facilities doctrine.
As we know, it’s never really been accepted in US antitrust law, at least at a Supreme Court level, it’s been danced around quite a bit. But it seems to have regained some currency as an idea that, that is how we create more competition. We let more competitors into the market by forcing others to share their facilities. And I have large concerns with that. I’ve dealt with that mainly in the IP space, but I think some of these, learning in the IP space is applicable to the idea of sharing facilities more broadly, and in two ways.
So I, when I was an FTC commissioner, went to China quite a bit and dealt with the Chinese agencies there, and they would often say, “You tell us we should have competition, but for competition you need competitors, and our companies want to enter the market and the American companies have the IP that we need to enter the market. So shouldn’t they have to share that IP to create more competitors because that’s what leads to competition?” And what that whole idea really misses is the impact on investment and the impact on dynamic competition.
So yes, you might say today forcing people to share creates two more competitors where there was only previously one or two, but the impact on the incentives for an entity to invest, to create that better product, or the IP in the cases that I was talking about, really gets reduced when they… They have to share all the risk, right? Their next invention doesn’t work out so well, no one’s going to be knocking on the door saying, “That’s essential. We’re going to share in the costs of that investment that didn’t work out.” They only want to share in the winners, right? So that reduces the incentive to invest, and I think that hurts innovation and dynamic competition down the road.
So I actually did a study that looked at the relationship between the strength of IP protection and the investment of R&D over time, over different countries, and found that there really was a strong, can’t say causation but a strong correlation between stronger IP laws and more investment in R&D, which can be a rough approximation for innovation. So that is one of the main reason why I am so concerned about putting forward the idea that we’re going to make companies share their facilities just because a competitor wants them to get through the door because they think it will have that suppressing effect on investment, and ultimately the innovation that leads to more competition down the road
So I will conclude there, and look forward to the discussion.
SCHMALENSEE:
Thank you Maureen. Darren, you want to unmute yourself? There you go.
Darren TUCKER:
Thanks Dick, and thanks to CPI and CCIA for organizing this, I think, very interesting program, for organizing the panel. I’m going to talk about how competition policy should look at open versus closed software models, and talk about one case in particular where an enforcer was critical of an open source business model in a way that I think raises some concerns for the future of open source software development.
But let me just start with a little background so we have a sort of common understanding of terminology. So software platforms all rely on different types of business models. On the one end, some software platforms are released under an open source license, and there’s a variety of these but in general they allow software to be used, modified, and shared with minimal conditions, and usually for free. When most people think about open source software they think about lots of programmers volunteering their time to collaboratively develop the software in a very decentralized approach. In other words, a volunteer model. And that’s certainly the case with some open source software, although we typically do see a nonprofit foundation provide some degree of coordination, such as the Apache Software Foundation.
So Linux is an example of very successful open source software. By many measures, it’s actually the most successful operating system in the world today. It powers the majority of smartphones, servers and supercomputers, and is also used in a range of other types of devices like automobiles, game consoles and smartwatches.
On the other end of the spectrum is proprietary software. I think most people are quite familiar with this, Microsoft’s Windows, Apple’s iOS are prominent examples of that type of software. For proprietary software, the publisher retains the IP rights to the code, and typically licensees are not permitted to modify the code. They have defined redistribution rights and usually don’t have access to the source code. There’s usually payment of a license fee required, although that’s certainly not required.
And then there’s also different hybrid models in between the two. One example would be where a for-profit company develops the software, thereby providing an organized governance structure and compensation for the developers but releases the code under an open source license. But since the operating system doesn’t generate any income to the developer, the developer has to find a way to monetize its investment, typically by selling complementary software, services or hardware. So Red Hat is an example. Red Hat claims to be the world’s leading provider of enterprise open source software and they make money by charging for support and other services running on top of its open source software.
Dick asked a question at the outset of what is open versus closed, so I’ve been focusing at this point on the type of license under which a platform is offered, but I think there’s other ways to think about the degree to which a platform is open or closed. Some other ways to think about it would be does the platform provide open access to the APIs? To what degree does the platform sponsor have degree of control over what apps are available on the platform? To what degree does the platform sponsor control the hardware that the ecosystem is available on? And what degree of control is there in terms of who the distributors are? Is it going to be vertically integrated? Is it licensed out? If it’s licensed out, who gets to offer the product to end users?
So I think whenever we’re talking about open versus closed it’s important to explain what dimension we’re talking about. Certainly, you can compare platforms in terms of whether they’re more open or less open than the other, but we have to clear on terms of which of these dimensions we’re talking about.
So just to give you one example, when Apple launched the iPhone, Apple did not permit third party developers to distribute apps on the platform, so relatively speaking, that was a fairly closed approach. But Apple then changed course and later allowed developers to access these APIs and to distribute software through the Appstore. So it switched to a more open approach early in the iPhone days.
So there’s benefits and downsides to each of these approaches. Open source, closed source, something in between. And it’s important to recognize, of course, that software platforms are multi-sided markets whose success depends on attracting participants to each side of the platform, facilitating interactions. So for on smartphones, for example, this means attracting app developers and users, among other groups. And fully proprietary platforms have a much greater degree of control to facilitate these interactions. So they can specify standards for software developed for the platform. They can even exclude participants that are causing problems, whether it’s the end users, the developers, or other participants in the platform.
But open source software platforms have far less control and far less ability to minimize these negative externalities. But on the other hand they may be able to attract more adopters because of the attractiveness of a more open model and because of the ability to facilitate innovation by incorporating ideas from a wider community of developers. But a downside of open source models is the well-known potential for fragmentation, and I’ll talk a little bit more about that in a moment. And I think something that people often forget about is companies don’t just decide to just pick one model. Many, maybe most, software developers rely on a mix of open source and proprietary software. Microsoft, Google and Apple all offer a pretty wide range of proprietary and open source software.
So what are the implications of all of this for antitrust policy? My comments here, I think, are going to be consistent broadly with Maureen’s comments on this. I think it’s important for antitrust enforcers to keep in mind that all these different models, open, closed, hybrid, everything in between, they’re all trying to achieve the same thing. They’re trying to make the platform attractive to each group of users, trying to minimize negative externalities between these groups, and they’re trying to grow the platform. And we’ve seen each model be successful. Windows and iOS are successful examples of proprietary, Linux for open source, and Red Hat for a more hybrid type of approach. So in some markets, we might see the one model is superior, or appears to be superior based on market performance versus others. Other markets we may see a different model being more successful. Yet in other markets, we may see successful models actually change over time as the different participants’ needs change.
So I think for these reasons, again consistent with what Maureen mentioned, I think it’s really important for antitrust policy not to favor one model over another. Instead we should allow for, and actually encourage, competition between platforms, specifically on this basis. Now, that doesn’t mean any particular business model gets a free pass in terms of antitrust enforcement, but enforcers and policymakers should be careful they’re not adopting policies that would put a thumb on the scale in favor or against any particular model.
Let me turn next to the case I mentioned at the outset. So the European Commission’s Android case is an example of an enforcement action that appears to depart from my suggested approach of trying to keep a balanced approach at looking at each of these different types of models. There’s two aspects of the decision on which I want to focus. First just a little bit of background for folks that aren’t familiar with that case.
Google released Android under an open source software license, which meant that anybody can access, modify and redistribute Android without Google’s permission and without payment. Google apparently viewed this as offering a competitive advantage when it was released over the leading mobile platforms at the time, most of which took a more closed proprietary approach. But a risk of Google’s strategy was fragmentation. Different adopters had modified the operating system to such a degree than an app written for the version released by Google might not run on devices offered by some Android OEMs or carriers that modified the code, which again was permitted because it was an open source license. And this wasn’t a hypothetical concern. Several other open source platforms around the time, like Unix and Symbian, died in part because of fragmentation. And you can think of fragmentation as essentially opposite of compatibility or standardization. Software developers would greatly prefer to develop for non-fragmented platforms because of lower costs and ability to reach more users. Users prefer devices running non-fragmented platforms because they’ll have access to more apps and there’s less risk of an app breaking.
So Google’s solution to this problem was to offer Android under open source license but to introduce a compatibility program. So companies that wanted to license a separate set of Google’s proprietary software would agree not to fragment the platform by following a set of publicly available technical standards. So any OEM that followed these standards would be assured that apps written with the Android SDK, that’s the Software Developer Kit, would run on their Android devices. And an important part of the compatibility program I think is sometimes lost is that partners could still add capabilities to Android, they just couldn’t omit features the developers expected. In other words, the key benefits of open source software remain. So the ability to harness a wide pool of developers to facilitate innovation, the potential for wide adoption, and the ability of adopters to see exactly what they were getting in the code. There wasn’t going to be any surprises.
And notably, many other open source software developers have adopted similar means to control fragmentation. This was not a unique strategy on Google’s part. Nevertheless, the European Commission found that Google’s Android compatibility program violated EU competition law. The commission found that the anti-fragmentation obligations were capable of restricting competition for smart mobile operating systems. In other words, the European Commission actually thought fragmentation of the Android platform would promote competition.
And this strikes me as a clear thumb on the scale in favor of more closed proprietary platforms. That’s because all successful platforms must find a way to control fragmentation. It’s relatively easy for proprietary platforms to do this. They can do it by denying access to the source code, they can prohibit modifications to the code by other means as well. But open source platforms generally can’t do this, and as a result fragmentation is a much more difficult problem for open source platforms to control.
The unintended consequence of the EC’s decision alive here is that the next time a developer has an idea for a new operating system or platform, he or she is going to be less likely to adopt an open source model. Without the ability to control fragmentation, there’s a serious risk of an open source platform splintering into a thousand pieces, driving away developers that are critical to any software platform.
So that was the first problem with the decision. Another part of the decision actually compounds that problem. So recall that Google licenses Android for free, and therefore needs a way to generate revenue to support its investment in the platform. And again, this problem’s not unique to Google. As I mentioned, Red Hat’s solution was to sell support and services for its open source operating systems. So Google’s solution was similar, but a little bit different from Red Hat’s, and so Google’s approach was to offer OEMs a suite of free optional proprietary apps that would run on top of the Android operating system. So these included well-known apps like Search and Chrome, and users’ exposure to these revenue generating apps is actually what funds Google’s development of the Android platform, which of course is more than just keep writing the code, but also provides support to OEMs and developers.
Still, the EC condemned the inclusion of Search and Chrome in Google’s suite of proprietary apps as a form of tying, and importantly, the EC rejected Google’s defense that including these apps benefited OEMs and users by providing a high quality experience out of the box, continued investment in the platform, continued OEM access to a free platform. And the result of the decision was predictable. According to media reports, Google now charges OEMs for the suite of mobile services that it used to provide for free. In other words, Google was forced to change its business model in a way that made the platform less attractive to its partners and less differentiated from other mobile platforms.
Fundamentally, I think the EC’s error here was to fail to recognize that the use of open source software is part of the company’s broader business model. In other words, it’s a way to generate income. Finding ways to generate income from open source software should not be viewed negatively, but rather as key to ensuring continued investment in the development of open source platforms. Corporate sponsors of open source software invest their money in open source software because they expect the project will stimulate demand for other products or services sold by the firm. And of course, I should have mentioned that when Google launched Android and the compatibility program almost 15 years ago now, Android had no market power at the time, which strongly suggests there was no anti-competitive intent in selecting this particular business model.
So in sum, I think the EC’s decision, by condemning Google’s efforts to minimize fragmentation and to generate the income needed to invest in an open source platform, it creates a clear disincentive for software developers to choose open source proprietary models going forward, which I think, in the long run is likely to reduce software innovation competition to our detriment.
SCHMALENSEE:
Thanks Darren. Hal, your turn. Feel free to disagree with this defense of global strategy if you’d like, or to make more general points.
Hal VARIAN:
All right, first of all I’m going to start with your question about open and closed. So I have to say it’s not an open and shut question. In fact, there’s a whole range of alternatives. For example, you could have a completely open software system, where there were no obligations of any sort. You could have something where, not only that, you provide documentation and support. You could have a formal standard setting operation to describe the input, output, APIs, et cetera. Or it could be something that’s informal or negotiated among a consortium.
And then there’s compatibility we just heard about, and I want to emphasize, compatibility is used throughout computer science. It’s a very standard thing, not just for commercial products but for non-commercial products. Like, for example, TeX, or LaTeX, which is a typesetting language. There’s a full compatibility suite. You can only call a product LaTeX if it actually works on that software input and produces the right output. Open APIs. Again we might look at some of the issues involving APIs and whether they are, in fact, protected automatically by copyright or not. The Oracle and Google cases before the Supreme Court at the moment.
And finally, there’s the proprietary system, where there’s no promises of openness, and there may or may not be documentation, and there may or may not be compatibility issues, and so on. So I think there’s a whole range of choices to examine. Now, I should say that 20 years ago, Carl Shapiro and I published a book called “Information Rules”, and we discussed exactly this question 20 years ago. There’s a chapter on cooperation and compatibility. How do you build an ecosystem? How do you make sure all the parts are working smoothly together? And then also what happens when things break down and you have a standards war, where you’ve got one or more parties competing with the proprietary standard?
And I think it’s really useful to go back and look at that, because the same problems that Darren referred to have been around for some time. And one of the most important lessons from looking at the history of standard setting, both formal and informal, is that open standards are endangered if they lack a sponsor. You need to have somebody who’s trying to herd those cats and get to the situation where you can have a truly open ecosystem. So let me give you an example from history that was the Symbian consortium. That was a group of mobile phone makers that created an operating system for ARM processors. It was the most popular mobile operating system in the world up until the end of 2010. Now, that was originally started out as proprietary at Symbian but Nokia bought the consortium in 2008, set it up as a non-profit, Symbian Foundation, with an open source model in order to create an industry standard that all smartphone manufacturers could use. But if fragmented quite rapidly, over a course of a year or so, and pretty much disintegrated by 2010.
So the industry realized, everybody would be better off with a unified operating system but nobody wanted to move unilaterally, and a player like Nokia, who was a very important player in that industry was not necessarily trusted to be a neutral manager of this standard. And in fact, it was abandoned. They abandoned Symbian in February of 2011. Instead, they used Windows Phone OS going forward, and of course, that gave a big boost on the Windows side. So the industry had no unifying OS at all. And meanwhile, Apple was gaining strength because they had a very good system, they had a fully operational system, they allowed for apps, as we heard from Darren, and it was really a problem.
Now, Symbian was hopelessly fragmented. People tried to revive it but it really never worked. Microsoft Mobile OS, that was a closed system but it had an existing ecosystem from the desktop world, and it had a strong sponsor, Microsoft. But what were the OEMs worried about? They were worried about what Microsoft would do because they’d seen how they were able to commoditize the hardware on the desktop, essentially, and get all the value through the operating system and software, and they didn’t want that to happen in the mobile world as well. Well, along comes Google. It had its first Android phone back in 2008, just a year after the iPhone was released. It was still relatively new, relatively unproven. Was Google really going to support this non-proprietary software?
And so, in part to assuage those worries, Google made the software fully open source. It was not only free to everybody, but it was in fact open source and you could do what you wanted with it, subject to the kinds of restrictions that Darren already alluded to. So I would encourage you to go to Wikipedia, read the article on Symbian. See what was at stake, see how it was resolved, because it’s a very good lesson for understanding the juncture, the point we’re at right now.
And in a way, I will say, Apple did the world a favor by having a highly proprietary system. Not just proprietary on the device side, but also even the carriers who could offer the iPhone at that time. They kind of drew a line in the sand and everybody on one line would say, “We’ve got to deal with this problem in some way.” And Android was the solution in that case. And unfortunately, as Darren described, that solution has been weakened to some degree by these recent developments.
Now, Android isn’t the only open system that Google offers. And by the way, before we leave the Android topic, I should mention that Android has been forked by various other parties. Just as an example, Huawei recently came up with its operating system based on the open source Android. Amazon Fire, that’s… in fact, that’s a really quite compatible operating system. They’ve just never applied for the anti-fragmentation agreements. Samsung Tizen, that’s another example. Raspberry Pi, that’s another example. Lots of Internet of Things devices are all running Android. Forked versions, not necessarily fully interoperable the way it was described, but nevertheless it was a huge advantage not to have to write your own operating system for you device.
Then there’s Chromium. So Chromium is the open source version of Chrome, essentially. That’s the basis for Opera, Microsoft Edge, Brave, Amazon Silk. They’ve all taken the Chromium open source and created their own version of it, which had different variations of one sort or another. There’s Kubernetes, which is really quite important, although maybe not so widely known as the others. That’s a way to make applications portable across data centers, essentially. So if you adhere to this standard, build your application on, let’s say Google, you can pick it up and move it to Amazon, or from Amazon to IBM, or from IBM to Microsoft. So that’s very, very important because it makes the cloud applications portable and avoids lock-in. All the problems associated with lock-in. TensorFlow, that’s on the machine learning side. It looks like there’s two standards emerging, TensorFlow on the one hand and PyTorch on the other. Pytorch more for development, and Tensor more for deployment. That’s a very important open source initiative.
Then there’s something called Flutter, which most people don’t know about, but Flutter is a way to do user interfaces for applications. You can write one set of code and it will run on Android, iOS, Linux, Mac, Windows, Fuchsia, and also on the web. So that’s a case where you’ve got extreme portability if you develop using this open source Fuchsia model.
And I think a lot of the issue surrounding open source comes down to this point, that it’s very hard for companies, or even individuals for that matter, to commit themselves to future behavior. You can’t say, “I’m going to maintain this product forever.” So what do you do? What you do is you make it an open source model and people will adopt it because, even if something goes wrong down the road, like the problem that Huawei faced, even if something goes wrong down the road then the OEM, the developers have access to the operating system and can still utilize that existing source code. So it’s a way of doing commitment to a model in a way that’s, I think, very compelling to potential adopters.
So I think will stop there and turn it back to you, Richard.
SCHMALENSEE:
Thank you Hal. Maureen or Darren, would you like to react to anything somebody else has said? Hal’s already reacted. If not, I’ll pose a question or two. Okay. I want to then ask about another buzzword. As you’ve all said, open/closed is not simple and it’s not yes/no, and it comes in various dimensions. Another buzzword which certainly is on many pens these days is interoperability. And interoperability, I think, comes in flavors, too, and seems to mean different things in different contexts. But it is sometimes treated, or sometimes alleged, not quite that sharply, but that requiring interoperability is a magic pill to erode platform dominance. It may also raise privacy issues, privacy concerns. And, as a former person concerned with privacy, I’m going to ask Maureen to react to interoperability and then we’ll go down the line.
SCHMALENSEE:
But, is it a magic pill? Is it a threat to privacy? Does it mean very different things in different contexts?
OHLHAUSEN:
Much like open and close, I think interoperability can be a very good thing. It can help expand… You’re trying to sell phones and it’s great if there’s a lot of apps, right? Because it drives demand for phones, but you may not want to be forced into interoperability if its not part of your business model. But if often comes up, the House Judiciary Report talked about it, but it also comes up with the idea of reducing lock-in, reducing the ability of an entity to, once you’ve committed to them that you’ve got to stay with them forever, that other systems should be able to feed into that and then compete.
One thing I really wanted to talk about was data portability, which is also often referred to as a way to reduce lock-in, to overcome dominance by allowing… And there’s two flavors of it, and as a former privacy enforcer, I’m more sensitive to one of the flavors than to one of the others. So there are these ideas that, well, because data is so important, and I have some questions about the all magic power of data, but particularly about consumers, is the idea that, well, the way to reduce this lock-in is to have portability of the consumers’ data. That they have invested a lot in a platform, they’ve got a lot of information on the platform, and so it’s going to be sticky, they’re going to stay with that platform. But if they can easily extract that data that they’ve provided and then plug it in, so that’s kind of the interoperability part, to another service, platform, what have you, product, that that will mitigate these effects.
So as a privacy… Wearing my privacy hat in addition to my antitrust hat, where I get concerned is where this idea is not so much that it is the decision of each individual consumer to take that data and to port it somewhere else. That what the response is going to be is to make companies have to share that data. Have to share their data about consumers. So I have concerns about that on a privacy level, because generally what privacy law is supposed to do is to help consumers control where their data, who has access to the data and how it’s being used, not to open it up and just say, “Well, it’s out of your hands, consumers, you’re going to give it to someone else for competition reasons.”
But this is really an issue that’s coming to the fore. I wrote an article last year for CPI called “Competition and Privacy: Friends, Foes or Frienemies”, because sometimes competition on privacy can be a good thing. Sometimes locking down data can impact competition. We saw that when Europe enacted the GDPR and it restricted the flow and access of data and created a lot of regulatory complexity, and it ended up having competitive effects because smaller companies couldn’t have access to data, and they didn’t get investment and they left the market. So it actually helped entrench big players.
But then the idea is that, should companies have to share their data? And there was an interesting case in the Ninth Circuit where LinkedIn… LinkedIn has its profiles of users, and LinkedIn has made certain promises to those users about how their data would be accessed. And there was another company called hiQ that was scraping the data from the LinkedIn site, and then using it to create products, one of which was to notify employers… Because people tend to do certain things when they’re starting to go on the job market, and one of them is to update their LinkedIn profile. So hiQ was creating this report from this and then selling it to employers and saying, “This person’s a flight risk for you.” So LinkedIn tried to enforce its terms against hiQ and say, “You can’t scrape that data that way. It violates our promises to our users.” And the lower court, and the Ninth Circuit upheld that they weren’t able to get an injunction to stop that because of the antitrust concerns. And they didn’t, at all, look at the privacy implications about individual consumers who shared their data with LinkedIn, based on certain promises. So this idea of a loss of consumer sovereignty over their data based on antitrust concerns is very antithetical to privacy law, where we’re seeing in privacy law much more push towards giving consumers more control over their data.
One of the other issues that really comes in there is there’s federal privacy legislation being considered, and I have testified on that, and one of the provisions it has is to allow consumers, if they want to, to be able to have access to the data that they gave to a company, and then to be able to port it over to another player. And so that keeps the sovereignty in the consumer’s hands. But going back to this other issue of investment and what will companies do, is there is this question… There is the data that a consumer gave to whatever company, product, platform, what have you.
But often times the value for the holder of the data is not so much, “It’s Maureen Ohlhausen and she lives here, and she does that,” but it’s what they infer about you. What they infer what your typical purchase behaviors are going to be. And so then there’s this question about whether, when consumers pull that data out, is it just the data they put in? Or does the inferred data, what was inferred about the consumers have to go, too? And I think that is a little bit of an underappreciated issue right now because I think that raises the same kinds of issues as an essential facilities doctrine. To say for companies, they’re creating value out of this data using their own analytics, and do they have to share those analytics with a competitor?
So it’s a pretty complicated area where antitrust and privacy are sort of coming together at awkward angles. So stay tuned. But there are some fine points that really need to be worked out, and I think, again, the hiQ/LinkedIn case was very, very interesting case that discussed that issue. And it was in the Ninth Circuit, which California’s supposed to be really sensitive about privacy, and the court didn’t talk about consumer privacy. They just didn’t include that, really, as a concern. Or they didn’t give it credit over the antitrust concerns.
SCHMALENSEE:
Thanks Maureen. Darren, did the House Judiciary Report, which did talk about interoperability, did they get it right? Did they discuss privacy?
TUCKER:
They did discuss this issue. Not sure they quite got it right. As your question suggests, the House Judiciary Committee did look at this issue. They looked at data portability, looked at interoperability, and recommended both of these approaches to try to address some of the concerns that they found in digital markets. Just a little bit of background on the report in terms of what led them to that conclusion. They looked at digital markets, in particular social networks was kind of the main area of their focus in this respect, and found that certain digital markets have characteristics like network effects, switching costs, high entry barriers, that make them prone to tipping in favor of a single firm, which makes things difficult for new entrants.
And again, they focused on social networks, but also pointed to mobile platforms and e-commerce. That’s two other areas where there’s a particular concern. So the report recommended that Congress consider mandating interoperability and portability, which they viewed as potentially lowering entry barriers for competitors, and also lowering switching costs for consumers. And they cited to a consumer survey where most consumers said that they wanted it to be easier to for the ability to a new platform without losing their important data or connections.
I thought what was sort of interesting was that the report took the position that doing this, mandating interoperability and implementing it, would actually be low cost, the term they used was relatively low cost, to do this. But offer no data in support of that very provocative claim. So in terms of what do we take out of this report? I’m probably going to echo some of the comments Maureen just mentioned. But again, I think we need to go back to Dick’s initial comments at the beginning of this program. Definitions matter.
And so, maybe it’s helpful to start with what do we even mean by interoperability? It’s actually a term that’s been around for a long time, and from a computer science perspective, I think there’s a relatively well accepted understanding which refers to two components or systems that work together without errors so that you can send data from one to the other without loss. When we’re talking about interoperability in the current context, it’s a little bit broader than that and I think it’s evolving. I’m not sure that this is actually even static for what the proponents are calling for here. But, as Maureen described, advocates such as the Judiciary Committee Report are calling for digital platforms to open up their platforms to allow, facilitate, or even mandate greater competition against the platform sponsor. And typically, we see calls for a new federal regulator that would dictate the terms of this interoperability.
And what’s the relationship between interoperability and data portability? I think, in general, interoperability should be thought of as a more advanced or powerful form of data portability. That’s because data portability requires, typically, affirmative steps by the users who then tell one service, “Please export my data to this other service.” And it’s a one time operation. And then, if you want to do it again a month later to a different service, you have to go through the steps again.
And so critics see that type of data portability as potentially insufficient, to really get at the lower switching costs, the entry barriers that they’re trying to achieve. And so, what interoperability, in this context, is trying to achieve is by forcing kind of a permanent interconnection between different services, which would usually be through a open API, or some kind of interconnection like that. To give an example of this, if I’m on Facebook but I decide to leave, to go to some other social network, but my friends all stay on Facebook, what interoperability would mean is that the two services could connect so that my friends’ posts on Facebook, I would still be able to see on my new service, and my likes and other posts, they would be able to see on their service without having to say, “Please export my data.” It would just happen automatically, in largely real time.
And there’s two components of data portability. At least, some would describe it this way. There’s a horizontal and a vertical approach. So horizontal is sharing data, or interoperability with a horizontal competitor. So that was sort of my example. It’s Facebook sharing with another social network. And when you think about this, what’s the antitrust theory for this? To the extent there is one, it’s really refusal to deal. And so, to the extent that there’s any case law to support this, you might look at Aspen Skiing. So here you might need a pre-existing course of dealing before you could have potential liability here.
And then you have vertical interoperability. That’s again, providing a connection, APIs or some other way, with services in adjacent markets. So this would be Facebook providing its data to, say Pandora, a music service. And so this is probably where the Essential Facilities Doctrine would be relevant, to the extent that, again, an articulating antitrust theory to require this sort of thing. Obviously, neither of these have a lot of support under US case law at this point, but I think that’s where you’d look for case law support, if any. From either of those, horizontal or vertical approach.
So getting back to the Judiciary Committee Report, I think the report does do a good job of highlighting the benefits of interoperability and data portability, at least at a high level, but it fails to acknowledge a lot of the complexities here that Maureen already touched on. It doesn’t engage in any kind of cost benefit analysis, it only points really to the benefits and just kind of brushes aside costs.
So you don’t see a recognition of the significant privacy and security issues with interoperability. You don’t see anything in terms of do these things effect companies’ incentives to invest in data driven products and services? And you don’t see even really any recognition, much less attempt to take on, the really difficult practical issues here. Who has an obligation to inter operate? With whom must a company inter operate? Again, horizontal versus vertical interoperability, and within that, does everybody in the industry get access to your open APIs, or can you limit it in certain respects? What data should be available to the other service? Should somebody be responsible for setting certain development standards? To facilitate interoperability? Or is it just going to be kind of a wild west of every set of companies are going to develop their own standards in terms of how they’re going to share data? And who is responsible if something goes wrong? If there’s an unfortunate privacy problem, personal data is leaked, who is responsible in that situation?
I think the other thing, too, we ought to keep in mind… I wouldn’t be surprised if Hal was going to touch on this. But the industry is already taking a lot of steps here, and there’s frequently not a recognition of this. And just to give you sort of three examples. So there’s the Data Transfer Project, and this is a group that consists of a lot of the big tech companies, Apple, Facebook, Google, Twitter, Microsoft, and these are working on an open source data portability system. So it’s designed to make it very easy for a consumer to say, “I want to move my data over to this other service,” in a very easy wat. So that is underway, there’s, I think, tens of thousands of lines of code have already been developed. Which I think is an illustration of actually how challenging this can be, that there is that much work that’s involved in doing this. But the industry is responding to consumers’ concerns.
Even before this, a lot of these companies already provide ways for consumers to export their data. And then certain types of apps, where it’s relatively easy to do this data portability or interoperability, it’s already there. So, for example, health and fitness apps are a great example of this. Most, if not all, of the most popular fitness apps allow for not only data portability, but open APIs that allow real time sharing of data between fitness apps. So, for example, if I’m using a Fitbit device but I like to use Strava, which is a popular fitness app, you can go to each app and say, basically, “I want the two of you to talk to each other, and share data in real time.” This is a widespread feature of these types of apps, and the reason I think for that is that it’s pretty simple to do. You’re not dealing with a lot of different types of data. You’re looking at number of steps, distance traveled.
It’s a fairly defined set of data types, and so it’s relatively easy for companies to share this kind of data, and in fact, there are a couple of standards that have developed in the industry in terms of data types, specifically for fitness apps to facilitate this sort of exchange. So I think industry is actually doing a really good job here in trying to respond to consumer demand for greater portability of their data, but I think we just need to be cognizant of the significant costs to do this in terms of facilitating this access, as well as the obviously very real privacy concerns.
SCHMALENSEE:
Darren, I realize as moderator I’m not supposed to say anything, but I do remember the telecommunications era when local companies were required to provide access, and there was a little bit of debate about the terms on which they would provide access, reminding us that requirement to provide access does not actually solve problems, it makes good work for lawyers. Hal?
VARIAN:
Yeah, I was going to mention one important issue that was touched in Maureen and Darren’s discussion, is that what happens when there are multiple parties involved in the data that’s exchanged. So I have photos of me and many other people. Presumably, I own those photos, but do they have any rights to those photos at all? And if I move my photos from one service to another, do they have any say in that? I think the logical answer has got to be no. This is like, look at 150 years ago when photography was first developed, there was this whole issue of whether you had to get permission to photograph a crowd and the answer had to be no just because of the transaction costs that are available. But the same thing goes for email. Email is a thread now, and that thread could involve many different people. Do each of the people in that thread have a right to that data? So that’s going to come up sometime in the next few years.
And, as Darren said, we have this Google Takeout, which allows you to download all of the datasets that Google has about you. I think there’s about 50 of them now. And you can do what you want with them. There’s also this Data Transfer Project, where companies have agreed on a common standard for saved photos, and so you can actually seamlessly exchange them from one to another. So that is being tackled.
There’s a very interesting standards body that’s working now to standardize data schema, that is the way data is organized. So I direct you all to schema.org, where you can see a number of attempts to standardize how recipes are described, or how photos are described, or how products are described. These have actually been very, very successful in terms of making more seamless transfer of data among different devices, different operating systems, different databases, et cetera because they’ve got that standardization pipe in the middle that allows them to do that.
So, industry is working very strongly on this set of issues.
SCHMALENSEE:
Thank you Hal. I think we’ve just about run out of time. We could clearly explore these complex issues at some length, but perhaps our audience wouldn’t stay with us for the next five hours. So I think I will, on everyone’s behalf, thank our distinguished panel and draw this session to a close.
Thank you all.
OHLHAUSEN:
Thanks.
SCHMALENSEE:
Bye.
