As an open source auditor at Openlogic I have had my fair share of challenges when conducting a source code audit. Tackling your first few audits can seem cumbersome and intimidating; from identifying different open source package versions to being given incorrect information from developers. To help with these issues consider the following.
During the course of providing open source software services--whether for customers, internal work, community contributions, testing, or trials--we sometimes come across surprises. It is not uncommon to discover unexpected open source or commercial components in the code being scanned. The existence of unexpected components means there may be additional or unknown licenses that have not been taken into account for governance or compliance activities. Here is a sampling of such surprises. I have focused on cases that could lead to changes in the codebase in order to eliminate or reduce risk.
Faster development cycles can be achieved by having a strong strategy and a firm set of standard guidelines as to how your company manages open source software. We all know how much everyone loves faster development cycles, but this is just the tip of the iceberg when it comes to the advantages of having an organized open source strategy.
Commercial source code scanning tools have become quite the hot topic for CIO’s, software development managers, in-house counsel, and enterprise architecture teams over the last eight to ten years. The emergence of these new technologies obviously has direct correlation to the maturity of open source software, which is now just as common as commercially-licensed software in medium to large enterprise data centers. Additionally, the distribution of open source into the consumer market is undeniable making source code scanning a critical risk mitigation measure for all companies that are buying or selling modern technology. Today’s article will briefly explain “noise reduction” and the process of using multiple matching techniques in a source code scanning tool.
Scanning for open source software is always about managing risk. You have some software and you want to minimize the risk that there will be legal complications in the future. The situations in which scanning for open source makes sense are quite varied. In this article we will discuss three common situations that might warrant scanning for open source software.
Open source software is everywhere, literally. Unless you write 100% of all the code used in your application from scratch, there is a very good chance you have open source software. And, unfortunately, your use of open source is not necessarily intentional. In 2008 Gartner predicted that by now 80% of commercial apps would include open source software. And more recently, in 2011, Gartner predicted that 99% of the Global 2000 enterprise would include Open Source Software (OSS) in their mission-critical software portfolios by 2016 Read more at Business 2 Community.
At a basic level, OSS scanners, such as OpenLogic's OSS Deep Discovery, analyze software development projects looking for components that come from OSS projects. They tie their results to in-depth information about the open source projects, licensing information and even project support. If you're a developer or a project manager here are some reasons you might want to run one on your project.
So you want to leverage open source software and you want to trust your developers to do the right thing, but you’re having a hard time convincing yourself that it’s safe. What do you do?
Open source software and open source risk management have been widely adopted on the enterprise level since the open source concept’s inception in the 1970s and 80s. In fact, open source has been so widely adopted that many organizations, including yours, may be using it unknowingly. It is not uncommon for organizations of any size to be using open source without any notice, whatsoever.
In spite of increased awareness and education about the use of open source software in the enterprise, lawyers still may find themselves tasked with creating and implementing an open source policy from scratch. Many companies still have not created a tracking process for the use or acquisition of open source software. At the same time, many attorneys lack a thorough understanding of the eclectic world of open source software and its licenses. Intellectual property lawyers may come to the table accustomed to the traditionally protective stance associated with proprietary licensing. Corporate attorneys with a basic knowledge of intellectual property law may find themselves forced into the more nuanced, murky, and uncharted waters of copyright law by open source licenses.
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.