As organizations bring more and more open source software into their IT environments, they are beginning to realize the need for more control. Decisions about whether or not to incorporate open source into their operations involve complex issues that go beyond the technology. With over two dozen approved open source licenses, compliance can be tricky. Requirements are different for code used internally and code distributed to external users. Code contributed to open source projects by employees could have licensing problems, or may not be approved for release. Compliance can be difficult to control wherever development is outsourced. The budgetary impact should also be considered for every possible open source migration. It's time for an open source policy.

There are many factors that will contribute to your overall success in mitigating the inherent risks of open source software use. The size of your organization will play a role, as will the general culture of collaboration and your efforts to educate employees. A mandate from the top to devote the necessary resources is critically important, and a clear definition of roles and responsibilities will prevent confusion and tire-spinning.

Once management agrees that some control is necessary, someone needs to be responsible. Consider appointing someone with a good understanding of the technical, business, and legal issues as the point person on open source policy issues. Bringing in an expert early can help you frame the issues properly and ensure that you've covered the bases.

Compliance is more than simply cataloging usage. Subtle issues must be considered in any internal effort to manage the use of open source software. Will deployment, customization, and support be provided in-house, or will you have outside vendors to consider in the plan? If employees are participating in development on open source projects, then the issues are more complex than if they are simply using software without contributing code.

It is true that larger organizations will likely see more complexity in the use of open source. There will, of course, be installations spread out over the organization, and possibly a wider variety of licenses to understand. The good news is that larger organizations are frequently used to managing complexity across departments, such as for website standards compliance. But smaller organizations can fall into the trap of believing that because they are smaller, the complexity is not there. Your organization will be liable for open source software use, even if only a lone developer knows about it. The key is to develop a policy, then encourage a culture of collaboration and compliance regardless of size.

Compliance starts with education. Open source software has created a new need for technical workers to have a basic understanding of legal issues. In this break from the proprietary software world, employees who previously never needed to understand the implications of licensing and contracts now have an unprecedented responsibility to follow rules that many organizations still don't fully understand.

Education is critical to any compliance effort. Most people using open source software are not well informed about the implications and about their responsibilities. Different licenses have different requirements, too, and many of these subtleties are not well understood. If you're not careful, you can wind up infringing on the GPL because an ill-informed developer used GPL code without anyone's knowledge. The best way to mitigate this risk is by being proactive about making sure everyone understands the rules. Because all open source software can be aquired at no cost, there is a strong culture of "free as in beer" among practitioners. This may lead developers to give away their open source code modifications without thinking about the official policy, if one exists. There are times to make code available, and times to keep it internal, but the point is that developers should not be making the decision.

Cataloging commercial software is difficult enough, and cataloging software (or portions of code) from over 100,000 readily available open source software is nearly impossible. There are two extremes in managing the risk of using software of unknown origin. One option is to limit the allowed software to a list that can be verified by technical, business, and legal sources. There are three difficulties with this approach - the need to create a list that is comprehensive enough for practical use, the potential lack of flexibility when new projects are not added fast enough, and the risk of non-compliance if the process is too cumbersome.

A more realistic and effective strategy is to replace direct control with education. If employees understand the rules, risks, and obligations of using and contributing to open source software, then a significant level of risk can be avoided when they are trusted to make localized decisions based on their day-to-day work. Seminars emphasizing likely scenarios and their desirable outcomes are the best medium for this message. Printed materials from the seminar can serve as a reference to employees who need clarification.

When software deployments or custom software development are outsourced, the picture becomes more complicated. How do you set policy for these sources? Your best best is to make the policy known by extending the educational component to those outside sources. You may even consider adding a section to your contract that states your open source policy and an assurance that the third party will be obligated to comply.

In general, I advise a policy of education and trust over one of strict controls. This approach is more realistic, and therefore more likely to result in higher compliance rates. By developing a policy now, you can set up a culture of respect and understanding of the rules of open source, and save some headaches down the road.