|
Product Liability and Open Source |
|
|
|
Tuesday, 28 October 2003 |
I've been particularly uncomfortable with the idea of tying product liability to the author(s) of open source software and I think I've finally figured out why:
When source code is available the author enables the user to make a more informed decision about how flawed the software is.
When Microsoft tells us the next version of windows less flawed, the only way to validate their claim is to use it and see. With an open source product, we can at least read the code and have some idea how accurate the claims of the author are before ever running the software even once.
Expecting all users to read the source code of all the software they use isn't rational, but we can expect security minded administrators and developers to do so to at least some extent.
Less sophistocated users can rely on the findings of a public network of experts to help them decide what products are safe enough for their purposes. And for applications where the assets being secured are valuable enough they can pay experts to audit the code before using it.
The BSD family of operating systems (NetBSD, FreeBSD, and OpenBSD) have benefited tremendously from the improvement of the security of the source code rather than relying on waiting for obscure exploits to be found. SELinux, sponsored by the NSA, is another great example.
This helps illuminate one of the claims that Microsoft has often made, that open source software is inherintely more dangerous because all the flaws are there for everyone to see. That may be true, but for a product as critical as a widely used operating system lots of folks have an interest in finding and fixing those problems. I don't think it's an unreasonable assumption to assume that eyeballs on the code is positively correlated with popularity.
As open source projects grow, they become more and more secure (sendmail and BIND are good examples). Conversely, I think it's also safe to assume that security decreases with product complexity and size. These two trends combined mean that as closed source products grow in size and complexity the number of flaws will increase at a faster rate than an open source project of similar size and complexity. The same number of flaws get added, but fewer get found and fixed.
This is a dramatic simplification, but I think it reveals important realities about closed and open source software. A closed source project with a strong emphasis on security, a secure development process, and security trained developers will probably be more secure than an open source project that emphasizes a fast schedule with developers don't have a clue about security. However, all other factors being equal, open source software will tend toward fewer flaws than an equivalent closed source project of the same complexity, especially as the size of the project grows.
Open source also includes an implied contract regarding liability. You can share in judging how risky the software is so you must also share in the risks of using the software.
Ahoy,
Jason
Powered by AkoComment 2.0! and SecurityImage 3.0.4 |
