Open Source Risk Mitigation

October 12th, 2007 by mgkimsal Leave a reply »

I’ve been with Open Source Risk Management for about 2 months now, and it’s been quite interesting so far.  The issues and risks that the integration of open source code raises, and how different companies respond to these risks, is probably the crux of the interesting stuff, at least for me.  It doesn’t necessarily seem to be the companies with the most at stake who are necessarily the most demanding about the audit processes we do, either, which surprised me a bit.  One of the things I do in my role is to talk with technical people about their code – how do things link together, where certain bits came from, and so on.

Much of what we’ve been doing so far has been reviews of code before an acquisition, or before a product launch.  The awareness of the risks is a relatively new thing, and we’re (as in the industry) still mostly dealing with the issues after the code is written.  Some new technologies are aiming to help developers address the problem during the coding phase itself, by flagging suspicious code in the developer’s IDE, or by offering libraries of pre-approved code available for integration.

I’ll throw this out there for all of you: do you view integrating open source in to your applications or products as risky?  Does the new GPL3 make any difference that view?  How do you go about keeping track of what components you’re using in your projects and ensuring licensing compliance?

Share and Enjoy:
  • del.icio.us
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati
Advertisement

4 comments

  1. Keith Elder says:

    When you say “integrating into your applications” what are you saying? Like I used an open source DLL to provide some type of functionality? Or I viewed some open source code in a project somewhere and copied it verbatim to provide my app the same functionality? I guess I’m puzzled by this since I’ve never knowingly used open source software in something I write.

  2. mgkimsal says:

    I guess the phrase ‘integrating in’ is somewhat vague, partially because there’s not necessarily enough case law to determine what is and isn’t permissible under many OS licenses. It could mean many things, from taking cut/pasting an algorithm (this in and of itself doesn’t necessarily constitute an IP infringement in all cases) all the way up to modifying something like the linux kernel and redistributing it, perhaps in a cell phone or cable box or something.

    In the .net world, someone might want to build on top of DotNetNuke, for instance. I don’t know their specific license offhand, but as you surely remember :) just *using* most OSS doesn’t indicate any violation of most licenses. Most concern themselves with redistribution of the resulting product.

    It’s hard to give any concrete examples right now without seeming to breach the privacy constraints I’m living in right now, but your examples there spanned the gamut of things I’ve dealt with so far, except all my projects have dealt with linux stuff, so DLLs haven’t specifically come up yet.

    One approach I’ve seen is to use IDE plugins to compare code in development to known open source. I believe Black Duck software has Visual Studio plugins available to integrate in to their product. This would allow developers (or their managers) to be alerted to possible violations as they happen, rather than days/weeks/months after the fact. For people shipping a product it’s probably much more of a concern than those primarily building internal apps.

  3. Keith Elder says:

    Yeah for internal apps I can’t see that being a concern at all. Are you seeing that too though?

  4. mgkimsal says:

    Well, even for internal apps, in some cases it’s a concern. I just spoke with the CTO of a company the other day who recently took on investment. The investors were paranoid about any GPL software being used in the product or any ancillary services. There are still a couple of small GPL pieces used in a few spots, and I believe it’s on their list to remove those soon. What the motivation was wasn’t made clear. My thinking is that they’d like to know they have more options in the future should they want to sell the software in a different form instead of only the currently hosted “software as a service” model. Yet another company I’ve dealt with has the opposite view – they are trying to insist that all vendor supplied code is GPL. Well, it’s not necessarily the opposite view, because I’m not sure that they insist on GPLing all their internally developed code, but they insist that all vendors working with them GPL their code. AFAICT it doesn’t always work, but it’s their initial stance, and any deviations from that position have to be very well justified.

Leave a Reply