In my last post, I discussed where we came from and where we are now in regards to knowledge and understanding of open source software and licenses. I talked about how, not too long ago, there seemed to be a fair amount of denial when it came to the use of open source software in the enterprise. Today, open source software has garnered enough attention that the term "open source" is found far outside the software world. Yet, misconceptions and misunderstandings prevail. Why? How did we get here? And how do we get to the point where there is accurate and consistent knowledge around FOSS? More specifically, how do we get to a point where FOSS use in the enterprise incorporates a thorough and appropriate understanding that backs a FOSS policy that is tailored to the realities and practicalities of that particular business?
How did we get here?
To give this journey context, I did a bit of research on theories of change. One theory - the five-phase, transtheoretical model - seemed relevant.1 Usually applied to drug abuse, this theory of change also begins with a state of denial, punctuated by no recognition of the need or interest in change. Next, one begins to think about change and then prepares to change. This is followed by action and then maintenance. Applied to the use of open source software in the enterprise, it would look a bit like this:
Unfortunately, a couple steps are sometimes skipped. Companies often go from denial to taking some kind of action. They know they need to do something, but they lack the thorough understanding (or time) to properly assess and plan what action needs to be taken. Often this may be from outside forces:
- A customer asks for a software bill of materials, particularly in regards to FOSS
- A audit is required as part of the due diligence for an acquisition
- Tracking and reporting open source software is a new mandate from the parent company or executive team
Regardless of the how or why, many companies are not tracking their use of FOSS and do not have an open source policy. When suddenly an external reason forces the issue, there is often little time to think through and plan out a comprehensive and forward-thinking solution. Consequently, some form of action is taken, which leads to more questions instead of clarity.
As a company that provides services and solutions for managing the enterprise use of open source software, customers come to OpenLogic because they need to do something. Helping them meet their needs is the easy part; determining exactly what those needs are and how to best meet those needs in a sustainable way requires a longer conversation. It is during these conversations that misunderstandings can be revealed.
Maybe it’s not surprising many mainstream references are wrong, because there remains a fair amount of misconception and lack of understanding about open source. Below are some examples of the knowledge gaps I've come across myself or heard of from others in the industry. The point is to show how easy it is to think you are starting from the same point of understanding and then realize some back-fill is needed to arrive on the same page.
Common Knowledge Gaps, Misunderstandings, and Misconceptions
Are we speaking the same language?
|"Do you understand the difference between source and object code?"
(after claiming to have a basic understanding of open source software)
|"Do we have any GNU licenses?"
(after using "GPL" during the lengthy previous discussion)
I was under the impression that it was enough to ask if someone had a basic understanding of open source, it's not. Just because someone uses familiar terms, doesn't mean they know the rest of the lingo. It is essential to ask the right questions to determine where to begin the conversation, if not the customer may be left behind or bored with elemental concepts they already understand. Sometimes that means asking a variety of questions and never making assumptions.
|"All open source licenses require code contributions back to the community."
|"If I use GPL, I have to release the code for the entire product."
|"Most commercial products do not include any GPL code."
It comes as no surprise that misunderstandings about license compliance abound, especially when it comes to the GNU licenses. We still hear the perjorative terms "viral" and "contamination" used as if this is a useful or accurate way (it's not) to describe the complex legal interpretation that goes along with determining what is a derivative work. A common form of these myths is blanket statements that do not take into account analysis as to how the software is being used (i.e. is it being distributed?) or simply assume all open source licenses are the same. While compliance is not difficult, it is specific to the license and requires analysis--just like any license. If you find yourself making these broad statements or assumptions, pause for a minute and ask a question instead.
A slightly different category of “a little knowledge does not go a long way” is more process related. Meaning, the company is taking some form of action, but it may not be entirely thought-through or there are gaps in the process itself (maybe due to gaps in knowledge or again, the need to hurry due to an external force.)
|Company receives software bill of materials for its own code)
"What needs to be fixed?" (and other questions regarding compliance)
While this may ultimately be a question of concern, talking about how to comply with the licenses before understanding the licenses, their conditions, and how those conditions apply in your specific use-case is putting the cart before the horse.
|(Company is using FOSS for a critical system... and something goes wrong...)
"Who's providing technical support on this?"
Or the opposite: a complete ban on FOSS due to “as is” nature of licenses (without realizing there are multiple options when it comes to obtaining SLA-backed technical support)
When it comes to using open source software in the enterprise, we often focus on the licensing issues. Equally a part of a robust open source policy is addressing support and maintenance. If you are using FOSS for a critical internal system, license compliance is not your main concern because you are not distributing the software. But you might want to consider what happens when there is a problem; do you have the internal expertise to fix it?
|(Insight from an in-house counsel regarding how open source licenses are reviewed in his company)
"I require my developers to submit for review all open source, even under MIT License..."
This was some advice offered by one attorney on a forum. The gist was that every open source package and every license needed review before being used. It was everything I could do not to write back and say: 1) Your developers hate you; and 2) This policy is not being followed. Your engineering department works hard and often under tight deadlines. Your FOSS policy--whether formal or informal--needs to reflect that reality. Pre-approved lists of certain licenses and use-cases can help lighten the load for both engineering and legal factions. If all the impacted people are armed with the right knowledge and understanding of a policy that is realistic and appropriate, then development can march on with little disruption.
Why is this a problem?
What these examples show (I hope) is that you cannot assume a certain knowledge and understanding when it comes to FOSS. It's not that it's hard, but open source software breaks the traditional mold of licensing, acquisition, and development model. Sometimes that takes a little time to get one's head around; in the meantime, there are blind spots. If your goal is successful use of FOSS in the enterprise, then everyone needs to be speaking the same language and on the same page.
Stay tuned for the final installment discussing how to mind the gaps...
Jilayne Lovejoy is corporate counsel at OpenLogic. In addition to traditional corporate counsel responsibilities, Jilayne helps develop OpenLogic's repository of open source licenses and obligations and ensures that OpenLogic's scanning and compliance software meets the needs of legal users. Jilayne participates in open source industry groups as a co-chair the SPDX legal work group; chair the special interest group on app stores for the European Legal Network facilitated by the FSFE; and member of the editorial committee for the International Free and Open Source Law Review. Jilayne is also a frequent speaker and writer on topics related to open source licensing and compliance.
View Jilayne Lovejoy's profile