Free and Open-Source Software (FOSS) is computer software that can be classified as both free software and open-source software. Anyone who wishes to use FOSS is freely licensed to use, copy, study, and change the software in any way, and the source code is openly shared so that people are encouraged to voluntarily improve upon the design of the software.  The Apache Software Foundation (web servers and other projects), the GNU Project (Linux) and the Android Open Source Project (mobile device platform) are some of the more popular FOSS projects that have been used to build the foundation of other products that are not free, like RedHat Linux.

Software development and licensing can be an expensive proposition: free, open-source projects can offer a tempting shortcut in software development (the code is already there) and an attractive cost-saving alternative to purchasing or licensing expensive “off the shelf” solutions. However, with the use of FOSS comes a serious risk decision: everything is provided “as is.” With a commercial solution you have warranty and support contracts that you can rely on to keep the software as current and bug-free as possible. There is no such assurance with the use of FOSS, where you’re directly responsible for the quality and security of the ‘free’ code.

Before you decide whether or not to use FOSS either as a solution to a technical issue or as part of a software development project, ensure you address the following risk factors – seeking adequate counsel in any area where you don’t feel 100% sure you’ve covered all the angles:

Code review: Open source projects are coded by the public at large. While there is certainly a Wikipedia-like argument that “the more people that work on it, the better the product,” you will still carry the liability for anything you produce/use using open source code.  Be careful that your IT teams apply the same level of rigor reviewing any open-source component of your products as they would to something they coded themselves. If you don’t have the staff for this kind of review I recommend sticking with off-the-shelf business solutions as much as possible.

Change management: Open-source projects are frequently updated – sometimes more frequently than packaged solutions. Going with a FOSS solution might mean a more resource-intensive vulnerability review and patching process than a more developed off-the-shelf product. Be sure you fully consider the operational cost of choosing any FOSS solution (is the “free” nature of the solution cancelled out by increased operational risks?)

Monitoring: Ensure you have network monitoring solutions in place that will detect anomalies with any solutions you’ve implemented, but place an especially watchful eye on the open-source solutions. Make it a specific point to include them in your (at least annual) third-party vulnerability assessments/penetration tests. As with any assessment, address high-risk findings expediently.

Participate in the community: If you’re going to leverage a FOSS solution, become a member of that community and ensure your technical staff participate in the many projects/initiatives that will be set up within the community to improve the end product. You can reduce your risk exposure through participation and awareness – and participation in public open-source initiatives shows you care about ensuring the free product you’re leveraging is continually improved. Very bad press can result if you benefit from the use of FOSS and then try and blame the foundation you don’t participate in for your problems.

Are you covered?: Ensure that your liability/malpractice policies will cover any losses resulting from the use of free and open-source solutions. Take specific care to reduce the risk that the language of your policy might be open to interpretation by your insurer when a claim is filed.