Open Source Licenses: Greater Rights, Different Responsibilities

There are a lot of misconceptions about open source software among legal, procurement and compliance officers. “Open source” is often equated with “loss of control” by the legal compliance or procurement department, and restrictions on its use may be imposed without a real program in place.

When this happens, the disconnect between the legal compliance department and engineering/development becomes wider, and risks that were manageable become much greater.

This doesn’t have to be the case — open source software is just like any other software — the license defines the rights, restrictions and obligations. Open source software licenses generally grant broader rights than traditional software licenses; however, with greater rights come different responsibilities. Therefore, it is still necessary to identify what rights are granted while at the same time becoming familiar with the obligations accompanying the exercise of those rights.

Develop a Compliance Policy

Does your organization have an open source compliance policy? If not, here are some tips for getting started:1. Get real. The first thing to do is to get past the misconceptions about open source software and your organization’s use of it. If you think your IT or engineering department isn’t using open source in some way, you’re fooling yourself. There are huge numbers of software programs that can be freely downloaded, and younger generations of employees are going to find the tools and software they want and need by looking to the Internet. Open source software is real and is here to stay, so it’s important to come to grips with the implications sooner rather than later.

2. Get educated. There are lots of materials and programs out there to help you learn about open source licensing and development. For example, there are open source software sessions during most software licensing legal seminars, as well as webinars available, such as the series hosted by Black Duck. The Association of Corporation Counsel also has a variety of materials on its website. The Open Source Business Conference (OSBC) is coming up in May 2011, and there are a variety of sessions, including an entire legal track. For an even more in-depth look at the topic, Bruce Perens, an expert in software and open source licensing, will be holding a license compliance course in Ohio this May as well. Getting some knowledge about what you’re trying to address with a compliance program will make things much easier down the road.

3. Get talking (and listening). Go out and meet with the engineering department, the software developers and the IT managers to see what’s really being used and how. Be willing to ask a lot of questions and really listen to the answers. Context matters, so you’ll need to understand the different situations where open source software is being used — and may be used in the future — and be sure your policy addresses these different circumstances. Is open source software being used by employees on their laptops? Is it being integrated into a product your company is selling or making available in a Software as a Service model? Be willing to be educated (and you can then circle back to the materials in No. 2 to validate the things you’ve been told).

4. Get buy-in. Identify stakeholders outside of the legal department and get them involved early and often. Having engineering and IT on board during the definition of an open source software policy will increase the likelihood of implementation success dramatically. Remember the goal isn’t to eradicate open source software from the organization — it’s to use open source software properly in the pursuit of the company’s goals. The legal department should be part of the group that is applying the policy, and assessing and monitoring its effectiveness, but there should be equal stakeholders in engineering/development and IT, so the policy is not viewed as merely an onerous legal requirement. Moreover, a diverse group may make it easier to develop and implement a policy that is realistic while not being too technical or too legal.

5. Get some ground rules. An open source policy should give clear guidance on the ground rules — some scenarios can be identified as permissible while others may require additional review by the open source compliance team. At a minimum, you should consider how your policy should address the following:

• Use of open source components in products for third parties
• Use of open source for internal purposes
• Approved usage models
• Use of open source by third party vendors or contractors, which may depend on whether the software is being used internally or for a product to be sold to customers
• Permitted/forbidden open source licenses
• Rules of contribution by employees to open source projects
• Use of commercial products to audit use of open source code

The clearer you can communicate the ground rules, the easier it is to enforce the policy. Of course, there will always be exceptions to the rules, which brings us to the final tip.

6. Get (and stay) connected. When you communicate the policy to the company, be sure to have an escalation path defined, so when questions come up about particular use cases there is already a process in place to handle them. The escalation team can be made up of the same people you talked to back when you got buy-in for the policy in the first place, which will encourage continued discussion about the policy and any improvements that may need to be made. Publishing an email alias in the policy (e.g., [email protected]) is an easy way to do this — although you should also list the people behind the list so it doesn’t appear you’re hiding behind an alias. And don’t just put the policy out there and go on to the next item on your to-do list — it is crucial to continue to have regular communication between legal and engineering to establish and maintain trust between the different teams, so that issues and questions can be raised and addressed efficiently and effectively.

Open source software is here to stay and organizations need to address how to appropriately use it while mitigating risks. Here are some more resources that can help you define an appropriate compliance policy for your organization:

• QuickCounsel: Open Source Software
• Implementation of a FOSS License
• Black Duck Software Online Presentations
• Best Practices for Creating an Open Source Policy
• Open Compliance Program

Good luck!