And then there is the question of support. Normally when you purchase a commercial product, the organization you buy it from provides some level of support, or you can purchase a support contract, according to McLoughlin. With open source, the question is where that support will come from. Organizations need to look at open-source code and understand whether or not they are going to be responsible for managing, fixing and supporting it internally; if they should outsource support to a third-party; or if the author of the code will be updating the code.
Developers who scour the Internet looking for open-source software shouldn’t have to consider things like security, support and compliance every time they want to look for a piece of code. Organizations should have open-source policies in place that answer those questions.
“An open-source policy captures the considerations around adoption of open-source software (OSS) in an organization. The policy ensures that the benefits of OSS are maximized, while OSS adoption risks at legal, operational and business levels are managed,” said Protecode’s Koohgoli.
Each open-source policy should be tailored to an organization’s culture and objectives, but there are some key factors they should consider incorporating.
“The key is not to approach compliance with the aim of ‘What can I get away with,’ but rather ‘How can I meet the expectations of the developers who gave me this software,’ ” said the OSI board of directors.
According to Black Duck’s Weinberg, open-source policies should include what licenses are permitted or blacklisted, the context of how a license is used (for instance GPL is okay for Linux kernel code, but not applications), who is going to take ownership of particular OSS components, and under which licenses will the company publish its own open-source code.
In addition, Rogue Wave’s McLoughlin said that policies should talk about how the organization is going to acquire open-source software, how the code is going to be tracked, how the organization is going to support open-source software and the community, and how the open-source software is going to be checked for compliance.
After building a policy, organizations also need to figure out how they are going to enforce it. According to Koohgoli, an open-source review board is often put in place who is responsible for getting input from the software life-cycle teams, making sure software satisfies the license requirements before it is released, and educating their developers on the policies.
Linux’s self-assessment open-source compliance checklist
Linux’s Zemlin recommended organizations take a self-assessment checklist to understand whether or not they are in compliance. “We recommend that there be a set of processes for reviewing the code you’re using, making sure you understand what all of it is and what requirements for each of the different components are, and then being able to make the process of complying very simple,” he said.