Section 4.5. Interesting Projects

4.5. Interesting Projects

I've already mentioned some projects in passing, but no chapter on open source security would be complete without mentioning some of the more interesting projects out there. I'll start with the obvious ones and move on to the more esoteric. This list probably reflects my current obsession with privacy and anonymity:

OpenSSL: Well known, but still essential. This library implements most known cryptographic algorithms, as well as the SSL and TLS protocols. It is very widely used in both free and non-free software, and at the time of this writing was in the final stages of obtaining FIPS-140 certification. http://www.openssl.org.
Apache 2: Of course, we've all known and loved Apache for years . Finally, Apache 2 has HTTPS support out of the box. http://www.apache.org.
Mozilla: A suite of web browser, mail, and news reading software, and related utilities. You probably don't think of this as security software, but it is probably second only to Apache in the number of financial transactions it protects. And it does it with a minimum of fuss. What's more, it isn't plagued with its closed-source rivals' fondness for installing evil software you never intended to install! http://www.mozilla.org.
GnuPG: Implementing the OpenPGP standard under the GPL. Primarily used for email, but also the mainstay for validation of open source packages (using, of course, public key cryptography). http://www.gnupg.org.
Enigmail: Small, but (almost) perfectly formed . This is a plug-in for the increasingly popular (and, of course, open source) email client, Thunderbird, providing a nicely streamlined interface for GnuPG. http://enigmail.mozdev.org.
CVE: Common Vulnerabilities and Exposures. This is a database of security problems, both commercial and open source. The idea is to provide a uniform reference for each problem, so it's easy to tell if two different people are talking about the same bug. http://cve.mitre.org.
TOR: The onion router. Onion routing has been a theoretical possibility for a long time, providing a way to make arbitrary connections anonymously. Zero Knowledge Systems spectacularly failed to exploit it commercially, but now it has come from a most unlikely source: the U.S. Navy. The Navy's funding recently ran out, but the Electronic Frontier Foundation stepped up to take over. Well worth a look. http://tor.eff.org.

4.6. Conclusion

In the end, it seems to me there's little to be sensibly said that, from the viewpoint of security, truly differentiates between open and closed source. The points I believe are critical are my ability to review the code for myself and my ability to fix it myself when it is broken. By " myself " I do, of course, include "or anyone of my choice." What I don't believe inat allis the often-quoted but never-proven "many eyes" theory.

In the digression on threat models, I mentioned that the only person who can really answer the question of whether open source is better for security is you. Leave the camp of people who think security is a good thing that we should all have more of, and join the camp of people who have thought about what it means to them, what they value, and so, what they choose.

Chapter 5. Dual Licensing

Michael Olson

Over the past decade , there have been many attempts to commercialize open source software. One common strategy has been to create services businesses, which offer consulting and support to users of open source. Another strategy has been to build hybrid businesses, which distribute open source platforms with proprietary add-ons, and which make money by licensing the add-ons.

A third strategy, and the focus of this chapter, is called dual licensing . Companies that use dual licensing provide a single software product under two different licenses. One license, which imposes open source terms, is available to a certain class of users. A second license, with proprietary terms, is available to others.