Subscribe by Email

Your email:

Connect With Us!

Current Articles | RSS Feed RSS Feed

Governing Internal Use of Open Source Software – What Are My Options?


Nearly every company writing software uses open source software (OSS) to some degree, but not every company does a good job of governing that usage.

Open Source Ghosts and Goblins


When I look at the landscape of open source governance and compliance, I am reminded how much fear drives the industry today. We often see the pitch of governance and compliance services as a way to root out unfavorable licenses, especially licenses from the GPL family. Sometimes in discussions, open source scanning is compared to computer virus scanning. Unfortunately, too many people seem to feel this is an appropriate comparison, and approach open source compliance as a search-and-destroy mission. Despite the term "viral," used for copyleft license models, open source is not a virus to be hunted down and exterminated.

What is the Cost of NOT 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.

3 and a Half Reasons You Really Need to Scan for Open Source Software


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. 

4 Keys to a Sound Open Source Software Policy: A CFO's Perspective


Companies can increase the usage of some of the most innovative technology in the world, open source software, and manage the risk that comes along with it by creating policies that effectively build awareness, provide control mechanisms and promote low overhead compliance.

Tags: ,

Open Source Software Compliance: Developing a Risk Matrix


In my last article, Open Source Software Compliance: How Well Are You Rating Risk?, we took a look at the key factors in determining risk associated with the use of Open Source Software (OSS). In this article I will be discussing how you can use those factors to develop a risk matrix to assist you in assessing your overall risk.

OSS Provisioning for Origin, Safety, and Maturity of a Community


A critical consideration of a corporate open source software provisioning strategy revolves around the maturity of the community and longevity of that community continuing to develop their project.

Effectively Governing the Internal Use of Open Source Software


Without an effective internal OSS governance strategy, enterprises both large and small are susceptible to problems and risks that can surface quickly when there is a lack of understanding and acceptance of open source software issues.

Open Source Software Compliance: How Well Are You Rating Risk?


Many organizations have begun to adopt a “risk rating” as part of their open source software compliance and usage discussion.  Some of the information gathering requirements to assess risk will be relatively easy to meet, while others require much more effort.  There are many factors to consider when assessing risk and as you decide which factors are important to your organization you will need to examine the size of the time investment needed to research and obtain the information associated with each factor.

Source Code Scanning for OSS Dependencies and Why


Open source application audits using source code scanning tools are a critical part of a corporate open source software policy management and governance process; there literally is no way around it these days.  Without the use of a scanning tool, organizations may rely on homegrown tools, manual inspection and inventory of source code repositories, and developer interviews to implement the governance process.  In our experience, even with full disclosure of open source usage from very honest and open development teams, things slip through the cracks.  And, lets face it, manual inspection of source code is painfully slow.  Homegrown tools might be a realistic approach for larger companies, but they require the allocation of internal resources, not only to use the tools but also to also maintain and update them regularly.

Most open source auditing engagements are completed in the context of scanning a code base of a product line to confirm that a company has appropriately separated their intellectual property from the third party components.  When third party components are used and distributed all licenses for these components need to be identified and there needs to be confirmation that appropriate license compliance steps have been taken.  OpenLogic’s Application Audit and Certification of Compliance services are one solution to consider when outsourcing to a team of experts as these are a full report of all materials, licenses, and a re-verification of compliance steps being completed.

Dependency Scanning Use Case

Depending on the industry and level of maturity of the open source policy management process, a more granular level of scanning may be needed.   Open source packages often bundle other open source software within the larger or parent project.  Some companies want to know not just which open source projects are included in their code, but also identify and then associate the sub-components or dependencies to a parent project.  Open source communities come in all shapes and sizes with varying degrees of attention to the issue of documenting dependencies.  In fact not all open source communities that build and maintain projects accurately disclose and update the dependent libraries that the project uses.  There may have been significant changes from version to version resulting in an old and previously accurate list of dependencies being partially incorrect in the newest versions. Consequently, what was once a pre-approved version of an open source project to use in a distributed code base, could easily be a policy violation and potential license violation in that next version.

If you are familiar with OSS development and license types a single file can make a very big difference.  For example, in one of our scans the OpenLogic audit and IP analysis team actually found a license conflict between source code components in an open source project.  We contacted the community to inform them of the conflict as they were not even aware this conflict existed.  The community acknowledged someone had in fact contributed code that created this conflict and the community did the right thing for their end users by removing the conflicting code and replacing it.

If you scan and analyze the open source software project code directly, you can then determine all the dependencies that are used by the specific version.  For example, if an organization's states that the most recent version of Zlib must be used, then this organization would complete a scan to find out if anything has changed from version to version.  As a result, the organization can then confidently make the statement to customers, investors, acquiring companies, etc. “Yes we ship the Zlib library with our product, we always ship the most recent version of Zlib, and we can tell you exactly what Zlib is using in the newest version.  Would you like to see it?”  Then obviously the company would introduce the most recent Zlib Bill of Materials and Licenses to the audience.

The OSS Deep Discovery scanning tool has a customizable setting for this exact situation thus reducing the number of false positives found in the initial results.  In other words, by adjusting the settings accordingly, the scanner will identify all the components inside of Zlib instead of simply reporting that you have matches to Zlib.

The real world example for this level of diligence goes back to having and managing an actionable open source policy.  Open source review boards that have monthly, bi -monthly, weekly, or even impromptu daily meetings about what can and cannot be used and under what conditions need the ability to quickly identify and document these occurrences, make decisions, implement critical policy rule changes and communicate all of this easily to the organization.  One new or changed file can make a big difference in protecting millions of dollars of development and intellectual property.

All Posts

Enterprise OSS Blog Policy

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.


Contact Us

Browse by Tag