Open Source Policies

This Wisdom of the Crowd, compiled from questions and responses posted on the IT, Privacy & eCommerce eGroup,* addresses policies regarding the use of Open Source Software. The issues discussed include:

I. Managing Open Source Software Use and Devising Open Source Software Policies
II. An Overview of Open Source Software Audits

*(Permission was received from the ACC members quoted below prior to publishing their eGroup comments in this Wisdom of the Crowd resource.)

I. MANAGING OPEN SOURCE SOFTWARE USE AND DEVISING OPEN SOURCE SOFTWARE POLICIES

Question:

I'm interested in how other companies - especially on the user side of the IT marketplace - are managing Open Source Software in their enterprises and setting policy on its use.

In the past, potential side effects of so called "copyleft" provisions and the lack of an infringement indemnity in virtually all open source licenses has led us to set up a presumption that a commercial solution - a solution from a commercial provider - is preferred if there's a choice. We're finding that the increasing importance of mobile and web-based technologies (where Open Source is common) and the prevalence of Open Source in commercial solutions are challenging this business model. Where and why are your firms drawing lines, and are these lines shifting due to these recent changes?

Wisdom of the Crowd:

Response #1: If you're strictly on the user side, I don't think you have much to worry about. Typically, restrictions in OS licenses fall more on the development side, e.g., you may not be able to distribute the OS code; if you incorporate the OS code into your own proprietary code, you may be blocked from distributing the combined code, or, worst case, you may be obligated to license the combined code (including your proprietary code) back to the OS community on the same terms as the OS code you obtained. My company has a reasonably small development team so our policy is for the developers to run every piece of OS code they want to use by legal (me), at which point I will review the particular license and either approve or block their use of the code (and, if approved, advise them on compliance with the relevant license). Generally, I'm worried about copyleft and other "restrictive" licenses but, luckily, I find that the vast majority of OS code my developers send me employs one of the more permissive licenses, so I rarely have to block their use of any code. My company's software is exclusively SaaS¹-based so, because we don't "distribute" software, that makes many of the licenses easier to comply with as well. I imagine that, for a large development team, the one-off approval process my company employs may not be practical. Given the multitude and complexity of OS licenses out there, however, I wouldn't envy the person who was forced to develop a standard OS use policy. I imagine such a policy would be necessarily over-exclusive, but I'd be very interested to see it if anyone out there does maintain one and is willing to share.²

Response #2: We are currently following a similar approach: We have a defined process in place for the development teams. Each use of OS (and commercial software) has to be approved by legal. This includes also a change of the way how the software is used (e.g. initial use by linking and new use by integrating or changing the source code). We are also using fact sheets for the most common licenses. Those should help the teams to do an initial evaluation before contacting legal. We also have some general rules like "Don't touch GPL³ if you want to commercialize your product."

It is also helpful if you have people with the technical background who understand the legal issues. We have a consulting team advising clients in technical and commercial questions on OS. In case of an uncertainty if the concrete use is covered by the license I get this team involved also internally.

I know that from a lawyers perspective it is hard to accept the "as is" mentality of OS. But at least if you integrate OS in your products those licenses with no or low copyleft give you much more flexibility in selling your product than a commercial license will ever do. In addition OS allows you to change and maintain the software in addition to using the updates provided by the community.

I am currently developing a firm-wide policy and I would be interested in sharing thoughts.⁴

Response #3: How companies manage their use of open source software pretty much covers the full spectrum - from "not at all" to complete policies with robust tracking and governance from start (development) to end (product shipping), including the requisite training.

I would say that any company that's still operating with a "no open source" mentality (whether in regards to using it internally, shipping products containing it, or requirements for vendors) is not operating in reality. Open source software is being used everywhere. If someone tells you they are not, I would assume they simply don't know/haven't checked.

As for policies regarding possible open source solutions versus commercial - I'd say that limiting yourself to commercial options only is probably going to prevent you from using some of the best stuff out there and probably cost you more money. There are third-party vendors that offer technical support on a variety of open source packages and, in some cases, IP protection, to address the typical IT concerns around the "as is" nature of open source software.

In regards to making policies based on certain types of licenses - there is no way to generalize this, as the right policy for an organization depends heavily on how the software is being used, among other factors. Blanket prohibitions, from my experience, are too often the result of paranoia (at worst) and a lack of thorough understanding (very prevalent) - i.e. if the legal team can't intelligently answer the question "why?" for the prohibition, there is something wrong (and your policy has less chance of being followed).⁵

II. AN OVERVIEW OF OPEN SOURCE SOFTWARE AUDITS

Question:

Can someone with experience or familiarity with open source audits provide me with a review of the process?

Wisdom of the Crowd:

Response #1: Thought I'd share a few thoughts on the subject and the replies received to date.

1. We've worked with both Black Duck, Open Logic and a number of other tools for Open Source auditing and management. There's a time and a place for each, and it all depends on what you are trying to accomplish (as aptly noted by others).

2. Perhaps it would be useful if we deconstructed the elements of an Open Source audit (from a company perspective), and shared ideas on the best ways to approach each component.

A. What is your goal and objective? There's a lot of good information provided by the vendors and the open source community to help you structure an Open Source audit, and Open Source management plan. Get to know Sourceforge and GitHub. They don't bite. There's simple Human Friendly tools now for searching, and APIs⁶ that can let you do a lot yourself.

B. What's on your systems and networks?

1. At a point in time. For example a due diligence exercise. This task primarily requires an audit of devices and applications and then a comparison of that list (and the exact versions and checksums for the Open Source files your applications depend on) to a master list of known Open Source Applications. Once you find an Open Source application, you then want to compare it to a known whitelist of "good" Open Source applications.

i. Mapping. There are so many good free tools that are available, it wouldn't make sense to list them. Many use NMap⁷ (an open source application) with a GUI⁸, and then enhance the process with scripting or agents to get at more detailed application information. There are even good browser based tools to get you started. But remember, this is just a start. Knowing the limitations of your tools is as important as knowing what they can do. You'll find Open Source lurking in devices all over most companies, and you need to understand your goals and objectives to know how far you should push your analysis and what it takes to get to the information.

ii. White List / Black List (i.e., good and bad apps and versions). Here's where a 3rd party is useful, but much more useful when you couple them with a good hacker in your organization. It's the use that matters as much, if not more, than the app.

2. As part of an ongoing management process. Here's where it makes sense to determine whether you have the skills in-house to actually manage the use of Open Source. I will submit that there's no better way to work with Open Source than to develop an internal competency (a cross-disciplinary IT, business, legal, management team) to review specific Open Source applications, uses, versions, risks and benefits. I don't think any outside company can really do this for you alone. They can provide tools to give you information, or a "stamp of approval" to comfort 3rd parties (or even arguably indemnity protection, but I don't really know how useful that is); but they can't make risk/benefit decisions for you on how you plan to use Open Source software at your company.

C. What's on other systems and networks you connect to (including access via APIs, clouds, SaaS, content delivery networks, data connections, etc.?). Depending on your goals and objectives, you will need to push your inquiry into 3rd party uses of Open Source quickly and here's where the value of the 3rd party Open Source audit providers diminishes to some extent.

Moreover, I'd like to submit that as corporate counsel, we need to make sure that there is a process at our companies for using Open Source software appropriately (i.e., the right code, with the right version, for the right job (an approved use)). There are 3rd party tools and companies to help; but they can't eliminate risks. Just to be a good consumer of Open Source audit services requires some knowledge of Open Source, but more importantly, a knowledge of the systems where it is used and the risks associated with that system. A real-time system at a nuclear facility has a different risk profile than Open Source software used by a web developer at home on their laptop.

From a technical perspective, I'll suggest that you need an Open Source management committee and your own database of approved Open Source software and versions. Depending on the criticality of use and the size of your company, you should consider use of an enterprise file system that would allow you to track both the code and it's dependencies in real time. Less critical uses can rely more on periodic auditing, scripting and workflows.⁹

¹ Software as a Service
² Response from: Michael Cremata, Corporate Counsel, ClosingCorp Inc., La Jolla, California (IT, Privacy & eCommerce eGroup, Aug. 7, 2013)
³ General Public License ⁴ Response from: Sabine Brumme, Chief Counsel IP/Alliances, BearingPoint Service GmbH, Frankfurt, Germany (IT, Privacy & eCommerce eGroup, Aug. 8, 2013)
⁵ Response from: Jilayne Lovejoy, Corporate Counsel, OpenLogic, Inc., Boulder, Colorado (IT, Privacy & eCommerce eGroup, Aug. 7, 2013)
⁶ Application Programming Interface
⁷ Network Mapper
⁸ Graphical User Interface
⁹ Response from: David Baumann, Founder, Counsel and Consultant, TechNexxus LLC, Potomac, Maryland (IT, Privacy & eCommerce eGroup, May 4, 2013)