The most attractive aspects of open-source software can also be the most problematic: It's free and it's just a click away.

That means just about anyone in the office can introduce open source code into the company's IT infrastructure.

It's tempting for users to think, "It's free, so no big deal. IT won't be billed for it." But IT still has to manage open-source software -- and that can't happen if IT doesn't know it's there.

"It's never a good idea to have no idea what your engineers or other employees are bringing into the company. The risk might be limited, but if [people start] sucking in whatever they want, there can be issues. Open-source software comes with all sorts of strings attached," says Clark D. Asay, a visiting assistant professor at Pennsylvania State University's Dickinson School of Law, whose research focuses on legal issues relating to the Internet and arising from technological change.

Each piece of open-source software has specific license requirements and possible restrictions. At the same time, the software should be documented and tracked to ensure that it's working properly. The problem is, many IT organizations aren't applying good governance practices to open-source software.

"The overwhelming majority of open-source assets used in corporate IT are either significantly undermanaged or completely unmanaged," says Mark Driver, an analyst at Gartner.

Driver acknowledges that management of open-source software is improving. He says surveys conducted in 2008 found that 75% of Global 1000 companies didn't have policies governing open-source software. Now, he says, 75% of companies reporting to him say that they do indeed have polices in place, although Driver says these polices aren't adequate.

"When I look at those policies, the significant majority are ineffective," he says, explaining that many require voluntary compliance or apply only to certain parts of the organization.

Yet CIOs face real dangers if they're not properly managing their open-source assets. They could get into legal tangles for failing to adhere to license restrictions. They could expose the infrastructure to security threats. Or they could find themselves scrambling to fix glitches in software they can't quickly identify because they have no reliable record of what it is.

Steven Grandchamp has seen companies face serious problems because of lax oversight of open-source software. "It's proliferated so much and so fast that now you have organizations using it and they don't exactly know what they have or where it is. And if you don't even know you have it, then you can't manage or mitigate the risk," says Grandchamp, CEO of OpenLogic, a Broomfield, Colo., company that helps organizations manage open-source software.

For example, one OpenLogic client had problems with a back-end system that processed gift cards for a large retailer. The system crashed just before Christmas, leaving IT rushing to find the source of the glitch. Turns out there was an implementation problem with a piece of open source code that a developer -- who had long since left the company -- hadn't documented.

It's a classic example, Grandchamp says, of IT neglecting to count open source code as a key asset and therefore failing to mitigate the risks that come with it.

"For some reason, it has escaped the traditional management channels. It escapes procurement almost completely because [it's free]. And it escapes a lot of technical evaluation because developers can just download it," he says.

Shaya Phillips, associate vice president for IT at Fordham University, says his IT department knows what can happen when open-source tools aren't managed properly, so it's trying to get ahead of that problem.

He and his colleagues see value in open source -- it's free, flexible and adaptable. But they're also aware of the challenges involved in maintaining it. Phillips, who is active in the Society for Information Management, says it's tough to determine when to contribute changes to the open-source community, when to make updates and patches, and when to pay for support services.

To balance the risks and rewards, Phillips says his IT department has decided to steer clear of open source for core systems, such as those running student registration, financials and human resources, unless the university can buy support contracts for it. On the other hand, Phillips says open-source software supports the high-speed innovation that IT needs for a growing body of applications, such as mobile tools.

And when open source is in the picture, governance is essential, he says. The university's information security office reviews open source code proposed for use to ensure that it's secure and that the university meets the licensing terms. The project management office tracks the code, following the ITIL standards set up by the software development office. Programmers must document what they use where and what modifications are made.

"We use our own protocols. We document what we did, what we used, give proper attribution. We have approved programming standards," says Phillips, adding that staffers are asked to share any new code they write with the open-source community.

Fordham's IT department tracks all of its software using Subversion, an open-source version-control tool. Phillips says he can't point to any specific problem that has been avoided to prove that such attention pays off. "But I'm sure we will," he says. "Already it's proved itself in that we know when people are working on the wrong version of software."

Mitigating the technical risks posed by open-source software is one reason IT has to do a better job of governing it. Making sure the organization complies with all licensing and legal requirements is another, Asay says.

Asay says some developers might still think that "open source" means "in the public domain" and that using open source code won't infringe on anyone's intellectual property rights. But, in fact, open-source software comes with copyright protection, and licenses specify how the code can be used.

There are numerous open-source licenses, with the GNU General Public License being the most widely used. The licenses generally specify if or when you have to publicly disclose the code's use, attribute it, and/or contribute changes and modifications back to the community from whence the code came.

Asay explains that restrictions and requirements most often come into play when the entity using the open source code distributes the final software package to someone else.

"If people are just pulling it in and there's zero chance it will make it out the door, no one will know about that use, so you don't have license obligations. Distribution is the trigger that makes the license obligations real," he says.

But in this day and age, when so many IT organizations develop apps for customers to use when interacting with companies, developers may cross that distribution threshold more often than they realize, Asay says. And that could mean legal trouble.

"You have this culture [that thinks] 'Hey, we're free to use it. We can avoid having to reinvent the wheel.' But if you don't follow the license conditions, then the copyright holder can bring an injunction and get statutory damages," Asay says.

Ramaswamy Nagappan, co-CIO at Pershing, says such risks are why open-source software needs as much management as -- if not a bit more than -- commercial software. And that's why Pershing has detailed protocols for when and how it uses open source.

Those protocols first require that the open source code proposed for use undergoes a legal review to check its licensing terms and contribution requirements, and to determine if there's any threat of IP or patent infringement. (Nagappan notes that commercial software also goes through a legal review, but that happens later in the procurement process.)

"Then we do a small pilot. A small team downloads it, they make sure it's working, then goes into the development cycle -- they test it and make sure there's no bug. It's like a proof of concept," he says, noting that IT also looks at the total cost of ownership and compares it against the TCO of comparable commercial products.

If it passes all those checks, the code then becomes part of the company's catalog of open-source options, which are tracked in Pershing's own free and open-source software management application. That ensures that "people don't download something that does the same function as something we already have," he says.

Karim R. Lakhani, an associate professor at Harvard Business School who has extensively studied the emergence of open-source software communities, says more organizations are developing strong management policies, aided by evolving tools and service providers. But more organizations still need to take up the charge.

"IT executives do need to pay attention to this and create an inventory of code they've brought in, with what the licenses are. But most organizations don't have good control over what their obligations are, both to the commercial sector as well as to the open-source sector," he says. But they should, he adds, noting that "software, both open source as well as commercial, comes with a lot of encumbrances."

"Remove the 'open source,' because open-source software is just software," he says, adding that the best practices that IT uses when managing commercial software apply to open source code, too.

But Grandchamp and others say open-source management protocols benefit from other strategies too. He and others recommend the following:

• Start with a detailed policy. "You have to make some statements about what you're willing to do and not willing to do," Grandchamp says. "The big thing about the policy is understanding the risk tolerance of the company, because it really should be a risk-based policy."

• Understand the licensing terms of the various open-source tools that your organization is using or might consider using.

• Conduct a sample scan or audit. As is the case with financial audits, it's impossible to conduct a comprehensive check of everything that's done using open source, but you can look at a sampling of uses and make sure they meet all the applicable guidelines, says Grandchamp.

• Use a compliance checklist. Sources such as Apache Software Foundation or the Linux Foundation have examples that you can follow.

• Check applications you distribute externally to see if they use open source code. As Penn State assistant professor Clark D. Asay points out, many open-source license requirements are triggered when code is distributed to users outside of your organization.

• Develop a system to identify open-source software that could be of value to your organization. This system should take into account your needs, the software's capabilities and license requirements and restrictions, Driver says. "Sometimes you have a good fit for code but not a good fit on the license," he says. "Not all open-source licenses are created equal."

• Devise a strategy for how your engineers will work with and engage the open-source community.

• Communicate policies throughout your entire organization. "It can't be just in IT, because you might have people in other departments downloading it," Driver says.