By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Copenhaver, general counsel and executive vice president for Black Duck Software, offers advice about indemnifications, getting support from open source projects and protecting internal software developed on open source code in this interview. In her OSDL Summit tutorial, "Reviewing use of open source software in the enterprise," she offered pointers on these and other aspects of reviewing open source usage and developing compliance programs.
In your presentation, you said that many proprietary vendors are and will be stepping up to offer indemnification against lawsuits for customers using their software. What do businesses need to look for in indemnification offers?
Karen Copenhaver: Look at the company offering the indemnification. The indemnification or warranty is only as good as the assets of the company offering it. Obviously, an indemnification from a large company is different from an indemnification from a very small company.
The second thing is that there are indemnifications that are specifically related to the defense of the claim. That's a very good thing. Look for an agreement that says, 'If there's a lawsuit, I will step in and defend you.'
There are also indemnifications that extend to covering the damages incurred by the [user] company because of the lawsuit. Those are much more difficult to get because of the variables, such as how the [user] company reacts to the claim or what the dependency [on the vendor] is.
The bottom line: What people should be looking for is that they would not have to defend the claim, that the provider would defend the claim.
There are no indemnifications offered by open source projects. Some IT managers are leery of using open source for that reason. Is this wariness justifiable?
Copenhaver: If you really do an analysis of the benefits of open source and the issue of indemnification, then it may or may not be justifiable. If you're using an open source project that many, many people are using, then you know that if anyone in that user group is sued then others will be concerned. You'll get a very powerful reaction to that claim. For example, if it's a patent claim, then there will be an entire community that will be providing prior art for the validity challenge. They will be looking at how to provide an instantaneous workaround, and they will be testing that workaround. You're in a much better position if you face an infringement claim because you have a large open source community actually addressing the infringement issue.
This is different from having a project where there is no community, where you're taking something off a Web site that doesn't have a lot of people using and depending on it. Taking something from a project that has a large community puts you in a stronger position.
In your presentation, you explained the complexities in assigning ownership faced by ISVs using open source to develop software. Are these complexities a barrier to wider usage of open source code?
Copenhaver: We've been through an early stage when there weren't a lot of attorneys and service providers who could assist these companies. Now there are people to help them make decisions.
There are easy questions that can be answered quickly -- about the use of libraries and other very important components. Then there are more difficult questions. It's a matter of making a risk assessment of the thing that you want to do. When making that assessment, the question to ask is, 'Do I want to forego the benefits of using open source just so I can have an across-the-board policy?' I think they need to be taking this on each instance and determining how difficult the decision [whether to use open source)] is in each instance. Some are easy, and some are hard.
If they begin to ship a product that they intend to be proprietary, and they haven't been careful about how that code either contains or potentially interacts with code, that's subject to a reciprocal license like the GPL, then that could be a problem. But if they are actually managing compliance, they're going to know when they've done that. I don't think companies are going to find it commercially viable to be afraid that that could happen and decide to have a broad policy to oppose the use of GPL. There are many open source components that other [ISVs] will absolutely want to use.
What are the risks for corporate IT shops that develop software based on open source for their companies' internal use? Is there a risk that they will have to make public their custom software that gives them a competitive advantage?
Copenhaver: There are different rules that apply to companies that are not distributing the code under the GPL. They do not have to make their modifications available. They only have to make those modifications available to those to whom they actually provide the object code. There are ways to manage that.
But many organizations that are using code internally may also foresee future transactions that might include that code base. So, I don't tell people that just because they are only using the software internally now that they won't run into a problem. If there's an opportunity for using that code base in the future for another purpose -- a purpose that might include distribution [of the code outside of the company] -- then having a compliance program that tells them what is in the code base would be essential for them to be able to take advantage of that opportunity.