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.
Why Am I (Still) Talking About This? In a concise amount of time, mobile apps have become a part of almost everything we do. Android Market (now Google Play) reported 600,000 apps, up from 150,000 just over a year ago. Forty-six million apps are reportedly downloaded each day from Apple's App Store. A recent Wall Street Journal article estimated the number of apps expected to be downloaded worldwide this year to be 136 billion. And it's not just mobile; there are now app stores for web apps, cloud apps, platform-specific apps, and so on. This is just the beginning.
Being that part of my role at OpenLogic includes helping our customers understand open source license compliance issues, I find the question of compliance in apps and app stores to be particularly interesting. This topic involves a relatively new form of distribution with vast impact. The law moves slower than technology, forcing us to swim in murky waters - how exciting! But this subject does not grab my attention just because of my job. I can't avoid the topic even when I'm not at the office. I've run into app developers (and ended up in conversations about development process and the use of open source) on bike rides, in coffee shops, and while getting a facial. Even those businesses that lend themselves to bricks-and-mortar are looking for an angle, as witnessed by a recent conversation with a local business owner who was trying to figure out how a mobile app could drive business to his store.
Last Friday, I wrote about some interesting research OpenLogic did on open source license compliance in mobile apps. This week continues that topic by looking more closely at compliance in terms of who is responsible and what are some of the challenges.
Shortly after announcing an update on mobile app open source compliance research, I presented on the broader topic of "Apps, App Store, and Open Source" at LinuxCon in San Diego. Judging from the number of people who attended the presentation and their engagement, this is still a topic many people are intrigued by. In this post, I'll provide an overview of the research and its potential implications.
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 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.