Open Source Provenance

It seems like common sense.  In order to analyze potential risks for consuming a particular open source component or application, it is necessary to understand who owns the copyright and under what terms the owner has licensed it to the community.

However, as anyone who has delved into the OSS world knows these questions more often result in muddled answers than crystal clear ones.  Several reasons for the confusion become obvious once you step back and understand the nature of open source software:

• OSS often begins with an individual who was simply trying to solve a particular problem or need and thought others might like to try their solution and perhaps improve upon it.  Such informal circumstances mean not much attention is paid to the OSS license chosen, and of course as is a copyright holder's prerogative, subsequent iterations of the same component are often released under different licenses over time.
• OSS components are often bundled together into derivative works which taken as a whole address some larger problem, business or academic need.  These derivative works are sometimes assigned licenses without regard for terms applicable to the base components or downstream compatibility.
• Communities which manage an OSS project will often have contributors acknowledge a contribution agreement before submitting a new feature or bug fix.  Most agreements I have reviewed contain all the basics one would expect but does the community carefully research the provenance of all the code submitted to ensure license compatibility?
• Automated tools which scan code for license hints or even snippets of previously licensed code through sophisticated text comparison algorithms can often reveal a plethora of resulting "hits" and false positives to weed through.
• It is becoming a common business model for companies to purchase the underlying copyrights for a popular open source project.  This often results in a roadmap where certain versions or features are retained in an open source community edition while the newest capabilities are only provided via traditional proprietary licensing.  And the line between the two is often shifting by design to maximize adoption and exploitation of the intellectual property.

Given all these potential concerns, how best to advise our clients?

How does your organization address such issues?

My approach is outlined next time.