Open Source Security
Coffee: The culture of disclosure and the idea that all bugs should be discussed as completely as possible in the open is certainly part of whats been generally labeled the open source communitys attitude toward development. Ed, Sun recently announced that its going to provide a degree of support for open source operating systems, in addition to its own Solaris operating system, that it previously had not. Do you feel that theres any difference in your ability to deliver and maintain a secure and reliable product based on the open source process, compared with the process by which youve been producing your own branded operating system thats sold into largely similar applications over the years?
Glover: I dont think there will be much of a difference there, no. Its going to be a challenge for us, but I think well be able to provide what our customers need.
Coffee: Mary Ann, Oracle products also run on the Linux operating system. Do you feel theres any difference in the level of security that can be achieved in an open source environment compared with the more traditional way of producing and selling operating systems in other platform software?
Davidson: I think it depends on what open source youre talking about. There was actually a discussion, I think, about some open source security software, and, for us, the issue wasnt so much robustness but things like liability and supportability. Not to go too much off on a tangent, but we use licensed crypto libraries from vendors, and its not that the algorithms arent well known and you cant get open source crypto, but we felt that the fact that there was no third-party indemnification and the fact that we had excellent code and good supportability from vendors, rather than using open source, is why we went with a licensed toolkit.
Coffee: That really elevates an important issue surrounding open source. Its been widely said, quoting Eric Raymond, if I remember correctly, that given enough eyes, all bugs are shallow, and therefore it makes sense to believe that bugs will be found and fixed more quickly in that community. But, at the end of the day, the real question, I think, as Mary Ann has just elevated, is that risk is a business decision and that you want to deal with people with whom you have a business relationship. And you cant have a business relationship with an anonymous community of people who are essentially doing things on a volunteer basis.
Is open source a model in which people can buy and rely upon products, or do people want, if I may be vulgar, someone they can sue if what they get doesnt do what its supposed to do? Is there still a need for traditional identifiable ownership of key software properties so that you can have that kind of relationship?
Davidson: The other issue for us was the cleanliness of the code. We looked at the libraries and said, in the open source equivalent, there were 400 libraries. It wasnt well implemented, particularly. It wasnt bad, but it just wasnt mature. The license libraries we had had been optimized for Oracle since we worked with this vendor, so we had 40 nice, clean libraries that worked on our mission-critical software really well vs. 400 libraries. So there were liability issues.
Even if patches are issued quickly in open source, that can actually be a problem. You dont want to be putting security patches or any kind of patch into your code base every week or two and having it ripple through your entire product stack. Youd like to get nice, clean patch sets that have been tested and regressed at fixed points.