The biggest downside of open-source security tools is the lack of support. While many tools have very active user communities and/or the option of paying for support, many do not. The problem is particularly bad for newer tools that haven't yet built a large install base. This lack of accountability can turn away some potential users.
Moyle says that when they select software, many companies "want to make sure that there is someone to get support from and that there is someone to hold accountable in the event that there's an issue. In the open source world, these things can be hard to come by."
Secondly, as good as they are, many open source tools are not enterprise-ready without some significant adaptation. In most cases, companies end up cobbling together a number of different open source tools along with some code developed in-house in order to create a complete solution. Many also combine some open source code with some commercial products in order to achieve the results they want.
2. Open Source Model; Download, Deploy, Redistribution, Modification
Requires giving back to the community in most models (your code - proprietary or not) and if not buying it (normal software license)
“Download” and “Evaluate” are often the easiest ones since most technology companies want their “open” or even proprietary technologies to be freely accessible for evaluation. Obviously, all open source licenses allow these two usages.
The “Deploy” is where most misunderstandings come from and where open source differ the most from proprietary software licensing. For server technologies, all open source licenses (1) allow users to freely build and deploy applications on top of the open source server asset without any restrictions on their application licensing. Restriction applies only when redistribution of the asset occurs, and typical end-user usage (over the Internet) does not qualify as asset redistribution. For example, Google is using a highly modified version of Linux (GPL) and has not had to give anything back to the community (Note: Google gave some of its customization back, though). Note that for client side open source components, GPL can be a little bit more complicated (not covered in this post).
Redistribution of an application is where GPL differs the most from other open source license types. GPL is very viral by design, and can be a great tool for an entity wishing to control the redistribution of its open source asset by assuming that many potential customers or distributors will not want to play by the GPL rules. Dual-licensing (GPL + Commercial License) is often used for this purpose by allowing users to opt-out of the GPL licensing restriction if they agree to the commercial terms. There are a lot of caveats to this dual-licensing approach (e.g., open contribution, community uptake, and corporate development opportunities), but it has proven to be working (e.g., MySql). MPL and BSD-like licenses (and in some ways LGPL) are designed to allow free redistribution of the open source asset.
Modification of the open source asset is where BSD-like licenses (Apache, BSD, MIT) differ the most from other ones. All other open source licensing forces modifications to their asset to be submitted back with the same original license, whereas BSD/Apache-like licenses do not have such requirements. I personally think that this is one of the principal reasons why Apache products and assets have been broadly adopted by commercial entities such as Oracle in their commercial offerings.
So, in short, for server-side assets, open source licenses cannot really be used to control deployment, but more redistribution and modification. If there is a good OEM business opportunity, then dual-licensing (i.e. GPL + Commercial) might be an option, but if community and adoption are the principal objectives, the Apache/BSD license types are probably the most effective ones. While GPL might give the most control (in some ironic ways), it might also limit market adoption and business opportunities.
Philosophy is that leadership comes from contribution and not control (i.e. licensing).
3. Takes time and money
IT resources are needed to code to your specifications. Need to understand the code base and/or programming language which may require retraining, tools, etc.
4. Intellectual Property
In most organizations there is a significant need for intellectual property rights for competitive advantage, etc. Open Source is not legally anyones Intellectual Property.
Also, where is the code base coming from are you sure these developers are not collaborating from IP they developed at their "Day Job"
5. Risk
The risk of bad or virus based code, the risk of code-based terrorism, etc. Who knows what's harboring in the code base developed by someone else? Can your company be comfortable with the risk? Who do you sue?
6. Support Mechanism
What is you have an issue, who do you call, what is project is abandoned? Again, are you hiring your own development team to support and handle, etc. Undefined service level agreements.
