Requires Free Membership to View
Well, the answer to this depends on whether the package is actually CLOSED source or is open source and licensed in that manner. In this case, Swiftfox is not closed source but rather licensed to prevent re-packaging and re-distribution. People can contribute patches and fixes to Swiftfox -- the restriction is that third-parties can't take this source code and re-badge or re-distribute it.
In Swiftfox's situation, this licensing is designed to prevent tainted binaries being distributed. Indeed, the license may make it harder for someone to distribute a malicious copy of Swiftfox they have produced themselves, but only if the user reads the license, works out the package is not legitimate and thus does not install it. Savvy users will probably take note, but users unfamiliar with the variations in licensing probably will not. As the author states, the restriction is a safeguard -- it's not a complete defense.
Additionally, security is more than open or closed source or differences in licenses. Security is a process. Hence, what also must be considered when weighing whether an application is secure are a number of other factors, including:
- A secure design
- Security-conscious developer(s)
- Use of appropriate risk-based controls, such as authentication
- Appropriate auditing and review of the code for security issues
All of these factors contribute to the overall security of an application and should be weighed, in a risk-based manner, when considering the security of a particular application.
This was first published in April 2007
Join the conversationComment
Share
Comments
Results
Contribute to the conversation