In my last two posts, I discussed the evolution of open source knowledge: where we came from, where are we now, and how did we get here. I provided some examples of common misunderstandings and knowledge gaps and suggested that such gaps may be due to the need to take action without taking as much time to prepare and plan as is optimal. The sum total is that misconceptions and misunderstandings about open source persist both within and outside the software industry.
On a practical level, companies that have not been tracking use of open source software--whether via internal development, out-sourcing, or software acquired from vendors--may suddenly find themselves being held accountable, for example, by being asked for a software bill of materials listing all open source software and applicable licenses. Such a situation then sets in motion some amount of scrambling to answer the request, which may not allow time to think through a thorough and pro-active solution for the future.
There should be no question that this is a problem. The result is that business decisions are being made and action taken based on perceptions, assumptions, incomplete information, or even incorrect information. Business decisions should be made based on facts and a well-rounded understanding of the given situation. But open source software isn't like traditional commercial-off-the-shelf (COTS) solutions that have specific licensing terms negotiated between two parties, including warranties or some level of technical support. Often, FOSS comes into a codebase without going through procurement and with no warranties or support number to call when something goes wrong. Open source licenses also do not follow traditional IP licensing models. All this means that an alternative approach must be taken. But when a company suddenly requires action without having, creating, and implementing a preemptive process, decisions end up being made without the optimal set of information.
You often hear about the maturity of open source software--how stable, high quality, and evolved the code is. And we hear about the increasing statistics regarding adoption of FOSS across industries and for a range of purposes as wide as software use generally. But, it seems that the maturity of open source users in regards to knowledge around business and legal issues is lagging behind (as seen by examples in the previous two posts). Why?
When something has no explicit licensing cost, there is a perception of less value; it garners less responsibility and less concern. As consumers, we are used to seeing advertisements showcasing "FREE" as a hook to get us in the store and the hope we'll purchase the full-price goods. No matter how many times advocates of free software explain that it's "free as in free speech, not free beer" or what freedoms FOSS licenses provide, "free" will still be associated (also) with cheap. And people tend to give less attention to things deemed as cheap.
But, as the saying goes "there's no such thing as a free lunch.” There is a cost to using open source software, it's just not the type of cost we usually think of: money. No, the cost of using FOSS in the enterprise is knowledge: it's the cost of understanding the license, technical risks, how to improve development processes so that you know what's in your code base, and so forth.
How do we "pay" that cost? How do we solve the knowledge gaps and misunderstandings? With education. It's not sexy, it's time-consuming, and it may be a hard-sell to upper management, but without it, you can't even be sure you are speaking the same language. In the long-run, the up-front cost of education is still far less than the cost of proprietary licensed software.
What do I mean by education? It means all the interested parties--anyone in your organization who touches open source software or is involved in decision-making that concerns the use of FOSS--will need to be provided the same foundation of knowledge. These parties will likely include business, legal, and technical folks. If you don't have inside counsel, then make sure your outside counsel is well-versed in the nuances of open source software, not just a practice area line-item listed on the law firm glossy.
Make sure developers (and possibly business people) get a primer on intellectual property law, particularly copyright. (They didn't get it during college.) They are the front lines in terms of open source software entering your codebase. Confusion abounds on key legal topics that can impact how licensing is reported or researched. Your best-intended open source policy alone, without training, won't remedy this potential pitfall.
While a one-time crash course may be the most efficient way to get everyone up to speed, don't forget to plan for training new employees. This should be considered within your company's FOSS policy, but if you are operating via an informal (read: not documented) open source policy, then you'll need to have a plan in place; or maybe this is the time to make that policy "official"!
And how do you obtain this golden FOSS knowledge of which I speak? You have a few options, depending on what makes the most sense for your company. Below, I'll discuss the pros and cons for the three most obvious methods of learning.
Pros: The only cost is time. Don't have to coordinate divergent schedules and location of a scattered workforce.
Cons: Favors one type of learner. How do you know which resources provide the best information? Not easily implemented in a large organization. Inconsistent results. Easy to simply not do. No opportunity for collaborative learning.
Pros: If materials are created by internal resource, the only cost is time. Don't have to coordinate divergent schedules and location of a scattered workforce.
Cons: No opportunity for collaborative learning. Still may have some inconsistent results, in terms of comprehension.
Pros: Encourages collaborative learning, which can then help bridge gaps between departments going forward. Opportunity to address specific concerns and questions. Better suited to ensure consistent results.
Cons: costs $$ and time. For best results, must coordinate attendance of all relevant parties.
And, finally, there must be communication, collaboration, and cooperation. I'm talking to you, lawyers and engineers! For reasons I fail to completely understand, there sometimes seems to be resentment, animosity, or rivalry between these two lots. My advice to everyone: get over it, check your egos at the door, and embrace the fact that we have more in common than you might think. Neither of you can do this alone. And for the business folks: you need to collaborate as well, most importantly by supporting this process. Don't expect immediate answers or easy fixes without the required investment.
The "cost" of education is a lot cheaper than purchasing a licensed, proprietary solution with robust support and training. Plus, the education you will need to support the various aspects of your open source policy is applicable to more than one software program; it is applicable to all the open source software your organization uses, which is probably much more than one program.
What is your level of FOSS knowledge?
How is your company supporting the education needed to properly manage open source software?
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.
Follow @jilaynelovejoy View Jilayne Lovejoy's profile
Allowed tags: <a> link, <b> bold, <i> italics
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.