A presentation from Karen faulds CopenHaver of Black Duck Software. Interesting - she brought up Friedman's "Flat Earth" book and chapter 3 (on Open source) straight off. I guess I need to buy the book.

Anecdote - story of a developer that a colleague had to fire, because he wasn't producing software, he was downloading various bits from the web and integrating them - thus increasing the risk of unintentional opening of code based on various OSS (and proprietary) licenses that may have walked in. To be fair, she points out that lawyers copy boilerplate all the time, so it's not an odd thing at all.

Heh - the idea is that our IP laws and licenses should transfer to China (after they translate the various licenses out there). ironically, in "The Birth of the Modern", a book I'm reading now - one of the huge complaints that the UK publishing industry had against the US in the early 19th century was our (then) lack of concern for copyright law. The more things change...

So anyway, she's flogging compliance software that supposedly fingerprints open source software so that you can look up what you have versus what's "out there". I'd like to know how that works, and what assumptions it makes about the software methodology that the code comes from :)

Virtually all companies now work in a "mixed IP" environment. Software is being built evr higher on older layers of previous work. What are the compliance concerns?

• Absence of control over code available for download w/o charge
• Questions regarding code pedigree
• Assumption that licenses are unenforceable

She claims that "everyone" will start shipping source with everything. I think I'll introduce her to Apple and MS sometime :) In any event - the notion she's flogging is that you need to know what you can and can't do with the code combinations you have, which is a valid concern. As to whether this is a real concern? At least for public firms, you have the whole Sarbanes-Oxley madness, so it'll get attention. So - step one is assessing what you have, and then remediating based on what you found.

She's advocating starting small, with a pilot project - and carrying it through from start to finish. Avoid disrupting development, and anticipate employee concerns. For public companies - the ones with SarbOx issues - you need to worry about whistleblower implications. I'd add that this will be a bigger problem if - for whatever reason - you have a demoralized set of employees. For any remediation plan, you need to involve all the players (including developers), or it will get rejected out of hand.

The goal of all this? To understand what it is you are building/shipping, and making sure that any issues are identified early.