Free and open source software (FOSS) development has for many years enjoyed an increasingly positive public image. Particularly in the last several years, it’s become recognized as the foundation upon which most of the modern computing world rests. FOSS proponents include many governments, too, including many in Europe and the European Commission itself.

That’s all good and quite appropriate, but it’s worth keeping in mind that FOSS involves the conscious agreement of head to head competitors to work towards a common result – something that would otherwise normally be a red flag to antitrust regulators in the US, competition authorities in Europe, and to many of their peers throughout the world. To date, those regulators do not seem to have expressed any concerns over FOSS development generally. But that can change.

Just this week, for example, antitrust regulators in the US announced that they have opened investigations into certain practices of several Internet giants, likely including Google and Facebook (Facebook confirmed today that it is indeed a subject of the investigation). In part, this has been because companies like these provide services to consumers for free. Until recently, regulators had seemed to believe it would be impossible to violate the antitrust laws by giving something away for free. More recently, that line of thought has been challenged not only externally by academics, but internally within the regulatory agencies as well. In Europe, the regulators haven’t been shy for years about investigating, and at times massively fining, companies like Google for perceived competition law violations. The moral? Providing something for free does not provide antitrust or competition law immunity.

But there’s another aspect of FOSS development that could become a cause for concern, one that to date has not to my knowledge been suggested. Although the emphasis varies country by country, generally speaking the antitrust laws in the United States and competition law in Europe exist to encourage competition. The reasons are several. One is that where multiple product and service offerings exist, consumers have more choices. More choices tend to drive costs lower, too. Competition also drives innovation, leading to more rapid development of new technologies, features, and capabilities as head-to-head competitors strive to come up with ways to differentiate their products.

With open source, however, the opposite happens. Instead of multiple, meaningfully different competing products, there is only one. True, companies will still compete to add services and features on top of the shared code base (a Linux distribution, for example, includes lots of code in addition to Linux itself), but diversity at the core, architectural level disappears. Taken to the extreme, the more FOSS succeeds, the more the technology world becomes akin to an island where there is only one hawk, one songbird, one rodent, one large mammalian predator, and so on.

To my knowledge, the regulators haven’t focused on this trend yet. But that doesn’t mean they won’t in the future in any of a number of conceivable scenarios, such as one company coming to dominate a given niche (Google and Android for example) and then taking advantage of its position to the disadvantage of other vendors distributing the same code, or if a group of companies creates a FOSS project and refuses to allow a competitor to participate. In the latter example, that company could bring a suit on its own, with the possibility (in the US) of gaining treble damages and recovery of its legal fees if it wins.

It’s instructive to see how this process contrasts with standards development, because that process has been around for over a century. Unlike FOSS, which is still pretty much a clean slate when it comes to antitrust and competition law, there are many laws, cases, regulations and policy guidance statements relating to standards development. Together they describe a well understood safe harbor whose boundaries are well understood, with where the supporting rationale for that favored status has been well articulated for a long time.

Consider this as well: unlike FOSS, which seeks to create an entire product, standards seek to define the bare minimum amount of conformity necessary to result in the common good, and then in the least prescriptive fashion possible. Performance standards, for example, only establish numerical benchmarks. Interoperability standards specify only the interfaces between products. Usually this is done in descriptive text. This leaves as much freedom as possible to a vendor when it implements the standard and allows it to build its product whatever way it wants to on its side of the interface.

Standards also increase incentives for innovation. They level the playing field by making it harder for incumbents to lock in their customers, because interoperability allows their customers to migrate away. They also create “network effects,” allowing new markets to emerge rapidly and dramatically, attracting more and more companies to enter those markets. Standards can provide the same sort of freedom from lock in to a specific FOSS vendor or host, but if that FOSS has become dominant, the customer is still stuck with the same basic product.

So, to summarize and compare, standards require the bare minimum amount of conformity necessary to create new markets and multiply the number of competitors, each incentivized to provide meaningfully different products, technologies, approaches and services in an effort to differentiate itself while driving down costs to consumers.

Open source software certainly compares well on price impacts, by lowering the costs of research, development and production for vendors and providing lower costs of ownership for customers, but the more successful the software becomes, the less choice there is in the marketplace at the technology level. That potential endpoint has other dangers I’ll explore in future posts, including the greater security risk of monocultures, the potential for innovative stagnation, and the possibility of abandonment if developers lose interest and move on. Except to a much more limited extent with respect to cybersecurity, standards lead to none of those risks. Those factors may lead regulators tomorrow to decide that FOSS deserves closer scrutiny than it receives today.

The upshot of this comparison is that it would be foolish to assume that regulators will look at FOSS the same way as standards, even though both are collaboratively developed in an open fashion, and at times can even be used to achieve the same goals. Regulators may well decide that traditional antitrust precepts, such as applying a “rule of reason” analysis to standards issues (e.g., balancing the positive market impacts of any particular standards development practice with any negative results) should not apply to FOSS development.

In addition to this big picture concern, it’s very important for projects to be aware that there are serious penalties for violations of antitrust and competition law for garden variety violations of law. In the United States, these include criminal penalties and fines of up to $1 million that can apply to individuals as well as companies. While actions against individuals have been rare for some time, they are still on the books. Penalties against companies, especially in Europe, are not rare at all.

For this reason, well-run projects maintain antitrust policies that educate participants on what they can and cannot do (the Antitrust Policy of the Apache Foundation’s is here, and The Linux Foundation’s can be found here (disclosure: the LF is a client).

The rules found in policies like these apply, and should be kept in mind, by programmers as well as members of Boards of Directors and Steering Committees, and go beyond obvious violations such as price fixing. Liability can also arise from excluding competitors; refusing contributions, approaches, features or other choices for other than meritocratic reasons; or targeting individual companies. It’s fine, for example, to say that a project wants to create the best software possible. A project that says its goal is to knock a specific proprietary product out of the market, though, is asking for regulatory trouble, and perhaps a lawsuit from the targeted company as well.

The moral of the story is that FOSS developers, both individual and corporate, need to be aware that creating a product that is free does not result in immunity from antitrust and competition law concerns. All the usual rules of conduct apply, and the extent – if any – to which FOSS may enjoy a degree of favored status akin to standards development remains to be determined, and if so, defined.

You can find the first post in this series here.