IT Employment

Choose the right licensing model for security software

There are three general licensing models available for security software. There's a case to be made for one of them being more suitable than the others, and it may not be what you think.

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".

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

19 comments
santeewelding
santeewelding

Not a casual, relaxed approximation. Pretty damn near airtight.

Dumphrey
Dumphrey

Do you see no possibility for friendly competition? Much like two friends competing in track, they share tips and tricks, yet push each other to greater effort and performance? Or has that become a thing of the past? I fail to see how cooperation and competition are mutually exclusive to each other, but I do see how most models treat them as exclusive. [edit for spelling]

Jaqui
Jaqui

tests done by one of the postgresql devs and posted on their mailing list showed that for a one million transaction query, the performance difference between Mysql and Postgresql was in the microsecond range. same data set. this was just after the release of postgresql 8.2 I would say that performance wise, they can be concidered equal. With everything else in the entry, I am in agreement. As much as I prefer to be able to get the sources for applications, I do not like the viral nature of the GNU-GPL. [ among other issues not relevant here that include most licenses ]

apotheon
apotheon

I've said a lot in this article that is controversial, or even inflammatory, in the right company. If you think you can make a compelling argument to the contrary, I hope you'll present your case.

apotheon
apotheon

I called it a casual, relaxed approximation because the manner in which I presented it was not 100% strictly formal -- but I do endeavor to make a strong argument in cases like this, regardless of how strictly formal the presentation. Thanks for the compliment.

Neon Samurai
Neon Samurai

You can still have two friends on the track, or coding, or playing video games, or playing pentesting wargames but it's at an indavidual level. As soon as it becomes about money and business, that friendly gentleman's competition is gone. "why did you tell the competition how to build a better mouse trap" asks the shareholder. "It was friendly tip swapping to push each other along sir" answers the staffer. "but now we have to build an even better mouse trap and my graphs didn't show the older mouse traps profit margins requirning more R&D for two more quarters." responds the manager. Some companies produce for the love of the product evolution and quality but those companies are few and far between it seems. That's my pessimistic view from the user's side anyhow.

apotheon
apotheon

"[i]Do you see no possibility for friendly competition? Much like two friends competing in track, they share tips and tricks, yet push each other to greater effort and performance?[/i]" That is, in effect, a form of cooperation.

apotheon
apotheon

Show me where that disagrees with what I said, please.

O & G IT Guy
O & G IT Guy

I really enjoyed reading this article. It was so nicely free of blindly defending a point of view and so full of logical arguements. Why can't more discussions be like this, especially when it comes to comparing operating systems?

apotheon
apotheon

It's public corporations that kill it, not business in general. Businesses can engage in friendly competition -- basically a relationship that is fundamentally cooperative, but has the appearance of competition -- and come out better than in a purely competitive relationship. Public corporations, however, have to answer to shareholders who cannot effectively express a single goal to the corporate officers. As a result of that, the corporate officers have to act in the interests of an assumed default set of goals, which include, most notably among them, market share advancement. It's market share advancement that creates the purely competitive relationship between public corporations -- not the mere fact that they're business entities. You kinda made that point in what you said -- but failed to differentiate clearly between "business" in the general sense and public corporations in particular.

Jaqui
Jaqui

postgresql has been equal performance wise [ as in speed ] to mysql for at least two years, your posting implies it's much more recently that such parity was reached. postgresql has, until within the last year, beaten mysql in the enterprise class functionality and security areas. now they are fairly equal in those areas due to mysql's improvements to those areas.

$olution$
$olution$

I agree with what "O & G IT Guy" said,"...free of blindly defending a point of view and so full of logical arguments." This was also a very enlightening article. I'd never looked at software licensing issues this way, and I think that I now agree with you, Chad. Previously, I'd been frustrated with both closed-source and open-source software for many reasons, including those you cited. I've been leaning in the direction of GPL, but your logic in favor of copyfree code is quite a revelation.

apotheon
apotheon

"[i]The approach of companies that view it purely as a set of rules to be "gamed" are where the harm comes in.[/i]" Yeah -- that's pretty much the problem. A free market is self-reinforcing. Where someone else tries to enforce rules imposed from outside, everything gets hosed up -- and you end up with an easily gamed system.

Neon Samurai
Neon Samurai

I see your point. I think I'm having a case of too much posting before morning coffee. Capitalism as a market mechanism seems completely beneficial. The approach of companies that view it purely as a set of rules to be "gamed" are where the harm comes in. It should promote product quality and evolution by prizing the companies that provide the best product too the market. In industries where poor product quality is not tolerated, this seems to be the case. In industries like software, this is the dream more than the reality. Where the customers are experts, it holds to some degree. Where the customers are not experts,.. well, Windows is very popular isn't it. Perhaps it's just my pessimism on the subject of business. Some days, it seems like business is only the practice of finding new and interesting ways to get other's money not continue the evolution of a product category.

apotheon
apotheon

Capitalism doesn't necessarily imply competition. Maximizing profit doesn't necessarily require a strictly competitive relationship with other businesses, and capitalism doesn't necessarily require maximizing profit.

Neon Samurai
Neon Samurai

I was thinking "shareholder" when writing it but did just use the blanket term. I've met a few non-incorporated business folk that are as focused on pure capitalism too though. Nothing can be more important than the mighty dollar beyond the point of even playing "what if" and considering creativity beyond the financial value that may be derived from it. But, as I said, it was more of a pessimistic view. In the city, it seems any business has to be in it for the fight where in the small town or smaller geographical market businesses have more freedom to cooperate.

apotheon
apotheon

"[i]your posting implies it's much more recently that such parity was reached.[/i]" I don't see it that way -- I only said "in recent years" -- but okay. "[i]postgresql has, until within the last year, beaten mysql in the enterprise class functionality and security areas. now they are fairly equal in those areas due to mysql's improvements to those areas.[/i]" Not really. MySQL can't manage to maintain parity with more than a small handful of such functionality areas at a time, because you have to swap out the storage engine it uses to get at the different feature sets. People talk about all the great features MySQL has, without mentioning that you get a few from InnoDB, a few others from Falcon, and a few others from MyISAM. For instance, you talk about how PostgreSQL and MySQL are about equal in speed, but you only get there with MyISAM (and maybe a couple of other feature-poor storage engines like BDB, which is famous for falling on its face and hosing all your data), which means giving up really important functionality like ACID compliance. You get ACID compliance with InnoDB, but to get that you give up speed and advanced replication. You can't do full-text searching without MyISAM -- which, again, simply isn't stable (lacking transactional integrity). The Falcon storage engine is promised to cure cancer, of course. On the other hand, it's in Beta right now, and so far seems to be faster than other storage engines only in select operations, and slower in others. I've seen nothing to suggest full-text indices. It doesn't seem to solve the problem that, as far as I'm aware, [b]no[/b] MySQL storage engine can use multiple indices per table per query. I don't think it does partial indices at all. Et cetera, et cetera, et cetera.

apotheon
apotheon

I'm glad I was able to make my points clearly. My aim is always for ethical -- and widely positive -- approaches to licensing and security. Lucky for me, such approaches to both those issues go hand in hand.

Editor's Picks