The whole world seems to think that developing software is necessarily a competition. It isn’t — and it shouldn’t be. In fact, cooperation is key to the development and propagation of secure software.

There are problems with a strictly competitive outlook.

The obvious first place to see that is in closed source commercial software development. Of course, in closed source commercial software development, vendors make it a competition. It doesn’t have to be, but by refusing to cooperate with those outside an arbitrarily small group of insiders, the end result is that between these groups competition is inevitable. It isn’t inevitable because it’s software development, or even because it’s commercial, but because competition is the unavoidable consequence of treating everyone else in the world as if he or she were an enemy. A number of businesses have proven, after all, that open source software development can provide plenty of opportunity to profit.

A less obvious example is in the open source world. A lot of open source developers and advocates seem to think that the way to maximize the benefits of an open source development model is to manufacture competition against closed source developers. The argument seems to be:

  1. The only way to get closed source developers to contribute to open source projects is to give them no choice. As such, your open source projects should use copyleft licenses. In simplified form, a copyleft license is essentially a license that forces anyone who distributes modified versions of the software under the terms of that license to release the source for the changes to all the recipients.
  2. The only way to get more people to use open source software is to make open source software appear to be better than equivalent closed source software (regardless of whether it is actually better) — and this requires “punishing” closed source developers by shutting them out of the benefits of open source software development.

There are other arguments that could be made, of course, but none that are particularly relevant to the subject of competitive impulses in software development.

Though half the technical (as opposed to ideological) reason for an open source development model is trust, the other half is cooperation. The cooperative benefits of open source software include things like:

  1. taking advantage of dilettantism in users who are also programmers, for feature development, and for patch development and testing
  2. far greater opportunity for peer review to help with flaw discovery
  3. increased interest in a project by giving other developers the opportunity to incorporate your work into their own

You might notice that none of these things actually requires a strictly competitive relationship with closed source software. In fact, the third item in that list might be seen as implying greater benefits from cooperating with closed source developers than from competing with them.

Taking the position that every time someone improves on your software that person must then “contribute back to the community”, and enforcing it by wielding copyright law as a stick, doesn’t really help open source development very much. What it does do is create a wall of sorts between open source teams and closed source shops, neatly segregating them. Pretty much by definition, a closed source development shop is going to be extremely leery of copyleft licenses such as the GPL, because such licenses ensure that code distributed under their terms “infect” other code that it “touches”.

I know that statement is going to be controversial among GPL advocates that read it, but it’s true — at least from the point of view of developers (and managers, and shareholders) who like to keep their source code closed. Because of this, the result of using a software license that must legally absorb any code that touches it is usually not enhanced by encouraging closed source developers to suddenly see the error of their ways and release their new code under the terms of the relevant license. Instead, the usual response is the opposite: they refuse to use the copyleft-licensed code, and write something from scratch, or otherwise find some way to avoid dealing with the software produced by the open source project at all.

This is not limited to closed source development. Copyleft licenses are almost always mutually exclusive of one another, because each legally requires the violation of the other if code from projects distributed under both licenses is combined and redistributed. Copyleft licenses, being mutually incompatible, make sharing code between similarly (but not identically) licensed projects illegal. Perhaps more ironic is the effect copyleft licenses such as the GPL have on code licensed under the terms of copyfree licenses, such as the BSD license. When code distributed under the terms of a copyleft license meets code distributed under the terms of a copyfree license, the result for the copyfree licensed code is exactly what many copyleft advocates fear from open source code being used by a closed source development shop.

Even cooperation with “the enemy” can help.

The fear is that closed source developers will not contribute back to the “community” if open source software is offered under copyfree terms such as the terms of the BSD license — because the license doesn’t require modifications to be “given back”. A problem with this manner of thinking is that it imagines closed source developers simply cannot (in some sense) succeed without the open source software, and that without the requirement to share modified code they’d never release their modifications. There are other problems as well, including the fact that many people choose licenses such as the GPL out of spite, at least in part; they want to “punish” those who would accept the benefits of open source software without giving back. This motivation is stronger for them than that of actually maximizing their own benefit and that of the open source community at large.

A prime example of how these different styles of licenses affect code sharing is that of the two most popular open source database management systems, each distributed under the best-known example of, in one case, a copyleft license — and in the other, a copyfree license. MySQL is available under the terms of the GPL. Then there’s PostgreSQL, available under the terms of the BSD license. In contrast with the wailing and gnashing of teeth of those who would have us believe the only way to get closed source developers to contribute code to an open source project is to “force” them to do so, PostgreSQL has actually managed to support a number of commercial endeavors that do contribute code to the main project. Among them, for instance, is EnterpriseDB.

EnterpriseDB extends the feature set of PostgreSQL to produce its Postgres Plus product. It also offers additional tools and services that work with PostgreSQL and Postgres Plus. Its entire business model is built upon PostgreSQL — and the company contributes significantly to the PostgreSQL project. It basically has to, not because of any licensing terms that legally require it to do so, but because its ability to build on PostgreSQL and take advantage of the DBMS’s new features necessitates involvement in core development. Furthermore, new core functionality is more easily maintained through new versions if it is eventually contributed to the core project rather than ported to new versions over and over again.

It’s a successful business model for EnterpriseDB, and it’s a successful development model for PostgreSQL. It is so successful, in fact, that while at one time it could be claimed that one should use PostgreSQL for scalability, standards compliance, and a more robust feature set, while MySQL was the best choice for speed, in recent years PostgreSQL has arguably leaped ahead of MySQL on almost all fronts. In cases where it lags even a little, those advantages for MySQL are typically bought by sacrificing other important capabilities. For instance, last I checked, one can still eke out very slightly better performance benchmarks for MySQL, but only at the price of ACID compliance. Of course EnterpriseDB is not the sole cause of PostgreSQL’s successes in substantially bypassing MySQL, but the company is an important contributor to PostgreSQL development.

As a result, it seems obvious to me that the increased cooperation from developers who would otherwise solely work with closed source software outweighs any perceived detriments to letting them “take” code without “giving back”. This is especially true if your interest in affecting the way closed source shops use your open source code is to try to entice more people to use open source software. As I already mentioned, there’s a perception among many that to “win”, open source software must hamstring its “competition” — namely, closed source software — by prohibiting closed source developers from using open source software to improve what they can offer unless they agree to become open source developers in the process. By contrast, however, it might be worth your while to consider how you came to start using open source software (assuming you, in particular, did so at all).

By far, the majority of you reading this probably started out using closed source software pretty much exclusively. I’ll take myself as a particularly dramatic example: I went from using closed source software exclusively to using open source software almost exclusively. The road I took to get where I am now was long and winding, but it started with an open source application that I ran in an otherwise closed source software environment. I gradually increased the ratio of open source software to closed source software that I used. The moral of the story is that you get people to use open source software by letting them use it. You don’t get people to use open source software by prohibiting them from using it, even in a closed source context, nor by prohibiting people from using closed source software in an open source context.

If you let people use whatever they like, in combination with whatever they choose, they will eventually gravitate toward the better option — barring a basically unassailable, perceived, vested interest to the contrary. On the subject of security software, that means gravitating toward software that is subject to peer review, among other things. If, on the other hand, you try to force people to choose one or the other, you’re most likely to succeed in convincing them to stick with what they already have.

What does all this have to do with security?

Being my readers, you’re surely very perspicacious, and have already caught on to at least one way this relates to security. I refer to the greater opportunity for flaw discovery and harnessing the power of dilettantism to help with patch development and testing, of course.

Another (perhaps less obvious) hint was my reference to one of two technical benefits of an open source development model: trust. It is a lot easier to trust code that is open to the world. The common argument in favor of closed source software is that access to the code does not mean you’ll read it, or that you’ll have the time to read it, or even that you’d know what you’re reading if you did. Of course, that misses the point — which is that when anyone in the world can pick up your source code and read through it, you’re less likely to try to hide something nefarious, or even dubious, within the code (the NSA’s supposed proclivities with regard to recommended elliptic curve cryptography algorithms notwithstanding). If you do so, somehow convinced you are immune to discovery, someone out there is likely to discover it and make knowledge of it available to others (the NSA’s supposed skill at hiding back doors in elliptic curve cryptography algorithms notwithstanding).

There’s (at least) one more security related implication at issue here:

Security is not just a matter of battening down the hatches and bailing water (i.e., closing up ingress to your system against unauthorized users or code and running intrusion detection and integrity auditing software). Security is also an ecosystem. The security of others is your security as well. The more people’s computers get infected, the more subject you are to attacks launched from those computers unbeknownst to the people who own them, the more spam will be sent to your inbox, the more often you’ll receive infected files and dangerous links from friends who pass them on to you without realizing it, and in general the more dangerous a place the Internet becomes. Helping others become more secure also helps your own security.

That’s not all. Have you ever wondered why encrypted communications are not more common? Part of the reason is compatibility. You can’t really send encrypted messages to someone that doesn’t have the means to decrypt them and reasonably expect it to do any good. It’s kind of a Catch 22 situation: you need them to have cryptographic software to be able to communicate with them through encrypted channels, but they’re unlikely to start using cryptographic software unless more people use it.

What really gets my hackles up is running across someone who in one breath laments the lack of widespread encryption use, and in the next argues that copyleft licensing is the One True Licensing Scheme because closed source developers shouldn’t be able to benefit from the efforts of open source developers without “giving something back”. Of course, what copyleft licensing often means is that closed source software vendors are not willing to take advantage of open source cryptographic software to provide encrypted communications capabilities to their customers, especially since the GPL is the best-marketed open source license in the world and many people outside the open source world aren’t even aware it isn’t the only open source license.

If you really want encryption everywhere, you should follow the PostgreSQL model rather than the Linux kernel model.

In short, using a very casual and relaxed approximation of a formal argument:

  1. Premise — Your security depends on more than just yourself. It also depends on the personal security of everyone else within your security ecosystem.
  2. Premise — The more people use your open source software, no matter how it’s licensed, the more development support it is likely to get. Thus, the better it will likely be.
  3. Premise — If you want maximum security throughout your security ecosystem, the most effective way to achieve that is to ensure that any security related software you develop is available to everyone, regardless of the development model primarily used to produce the software they use.
  4. Conclusion — If you want to maximize the security benefits of a piece of software, forget copyright and copyleft; insist on copyfree, whenever possible.

Obviously, you shouldn’t boycott software that improves your security and that of others just because it’s produced under a different licensing model than the ideal. Just make sure you understand it’s not ideal for the purpose of improving security overall, and look for opportunities to make a lateral shift to a better licensing model.

It is also important that you don’t forget that pretty much all software is security software in the end. Security starts with the foundations of your software choices — such as the OS kernel or even the bootloader — and is a part of every layer of software over it, all the way to the user interface. As such, the importance of choosing the right licensing model for your security related software doesn’t just apply to applications that bill themselves as “security software”.