Open source software is essentially community developed software.  It is software that is not owned per se by any one entity.

The open source initiative is a governing body or a standards group loosely defined, of course, that manages and catalogues open source licenses.

Open source software is probably one of the most innovative advances in software development in the last couple decades. However, it also is the source of greatest risk for intellectual property, as it has a lot of misappropriations, utilization of other people’s intellectual property, as well as, plain old copying of things that shouldn’t be in the software.

If a company discovers they have an unanticipated open source piece of code in their software, it can raise issues concerning IP and licensing.

As a corporation, you should set policy around utilization of open source software. The inside counsel and compliance group should come up with a list of acceptable open source that have non-locking licenses.

OSS can actually zero-out the value of your software, especially if you’re utilizing licenses that incorporate clauses that require you to distribute free copies of your software and source code to the users that request it.

A lot of the licensing conditions of open source software revolve around distribution, limitations of what you can charge for, what you can do with the software in a charging situation, or ultimately, what sorts of systems you can plug the software into.

When we talk about unlicensed source code, I’m assuming it’s unlicensed proprietary code because with open source, essentially when you utilize the code, you’re utilizing the license.

Probably the most graphic example of how software and open source software merge together is really to envision software code as a series of Lego blocks.

OSS enforcement is sometimes used as a trap by some companies. They have an open source version of their code and they have a proprietary version of their code. And they actively go out and look for people who have actually listed the code as being utilized in a product.

The five components of an open source software policy include survey, active management, commitment to remediate, actively plan, and engagement.