In a roundtable discussion at Sensors Expo 2015 in Long Beach, CA, an interesting observation emerged regarding how some engineers have been using, or better put, misrepresenting their use of open-source software code. The discussion took place between Will Tu, Dave McLoughlin, and Marco Gatti. All three gentlemen were major presenters at Sensors Expo, so some brief bios are in order before we dig into the matter at hand.
Will Tu is the Director of Embedded at ARM. He is responsible for developing awareness of ARM technologies in the embedded markets such as automotive, smart energy, and standard microcontrollers.
Dave McLoughlin joined OpenLogic, now Rogue Wave Software, in 2006, He started in a technical sales position and has since helped the company to develop its open-source content strategy and technical support department. Dave is currently director of open-source software auditing services.
Marco Gatti is a registered patent attorney at Brooks Kushman. He focuses on domestic and foreign patent prosecution, and litigation support in electrical, mechanical, and software matters. Marco's practice expands beyond patent prosecution and includes advising clients on open source software. In this capacity, he works with clients to understand complex software licenses and copyright matters.
The conversation began with Will Tu making a very eye-opening observation. That being there are some engineers in the field taking open-source code, making a few adjustments here and there, eliminating a header or two, and claiming to have written it themselves. This can be construed a number of ways, plagiarism being just one. The topic was considered more than ripe for further discussion, leading to the following interview.
Mat Dirjish (MD): Just so we have a baseline of reference for some of our readers who may not be familiar with open-source software practices and etiquette, what is required of someone who wants to use open-source code for an application? Is it a matter of just publicly acknowledging the usage, give credit to the author(s), pay licensing fees, or is there more involved?
Will Tu (WT): Just to give this a little more context. I think there is a perception that open source software (OSS) is free. Free of cost, free of obligations, free of support, free of maintenance, free, free, free. What part of free did I not cover? But this is entirely false. Let me discuss the two biggest misconceptions.
Free of cost – you don't have to pay "money" to use the code but you may have to pay in terms of resources to use the software, support the software, and maintain the software. This might mean modifying it to meet your needs, or updating the software if the open source community does not do it in time for your project.
Example: If a new BT standard is created, in likelihood someone will contribute and update the software, but what if it is not done immediately? Do you wait? Does your project have time to wait? Is time to market not critical? In such a scenario you might need to take on the responsibility yourself.
Free of obligations – this is where it get tricky there are lots of opens source licenses. You can check organizations like:
- The Open Source Initiative, they have a whole section on licenses.
- Another organization, the GENIVI Alliance, in the automotive domain, provided a table of most common licenses
- Wikipedia also has a table of comparison of open source software licenses
I am sure Marco and Dave will be able to elaborate more from their perspectives. But bottom line is that OSS is not completely free as one might think.
Marco Gatti (MG): The answer to this question depends on the open source software (OSS) license attached to the OSS software the developer selected to use. I know what you are thinking, I am just giving you a typical lawyer answer! But in reality, you have to understand how each license attached to the OSS works. There are thousands of licenses out there which range from simply requiring a public notice for use of the OSS to making a donation to a charity organization. The details matter, and the starting point is knowing which licenses apply.
Dave McLoughlin (DM): Many open source packages are provided under a license or terms of use. Those that aren't are either in the public domain or at a minimum are "copyrighted" work. Just like in writing a research paper it's important when citing or copying others' work not to claim that your wrote it and that you give them proper credit and attribution. The same is true in open source. When using open source it's your responsibility as a developer to read and follow the terms of use and at a minimum give acknowledgement and credit to the original author of the work.
What have you observed some engineers or designers doing with open-source code and software?
WT: There are lots of positive examples of engineering been able to use open source to accelerate development. Why re-invent the wheel all over again. Why create what has already been written for you? I am sure many of the kick-starters and makers are able to focus on innovation by utilizing open-source code.
The great advantage that open source provides is a "jump start" of sorts. You are able to take source code, study it, learn from it, modify it, and utilize it. It is like you are going to write a paper in college and you have examples of other papers on similar topics, or an outline is provided for you. You are getting a head start, but in the end you still have to do some work.
One of the pitfalls is that as you move from a proof of concept (POC), one needs to be careful, and follow the compliance aspects. If you are using OSS in your POC and want to leverage your earlier work to migrate into production development you need to be sure you are following the compliance. If you make the next "big" product and you have not followed OSS compliance, than you are opening up your company to potential liability. Lots of engineers are not aware of the compliance aspects or simply forget about it when the move to production starts.
On the other hand, there are companies that potentially have engineers misrepresenting OSS as their own original work. Managers have no way of telling if an engineer has simply modified the header or variable names in OSS, and submitted it. Here is where Dave's company Open Logic comes in, it provides a tool that can help management determine if there is OSS in their product. It also helps assess compliance to OSS licensing.
MG: A majority of developers and engineers understand that OSS includes compliance obligations of some kind, but they're usually unfamiliar with the details and the consequences of a failure to comply. It is often surprising to project managers, chief engineers, and directors who manage large projects how much OSS is used in the development of a production product they are managing. After running an OSS audit on a client's product, the client is typically surprised to learn that OSS projects are included in the product's executable that the client was unaware of or thought the OSS was removed.
What are the implications and consequences of this code plagiarism?
WT: Just like in college. When you write a paper you need to cite your sources, and direct quotes. Code plagiarism is like cheating on a college paper you are not "complying" with the licensing terms and saying you were the creator of the source code. This is wrong and has consequences.
MG: Let me start out by staying that Open Source Software (OSS) is a good thing. It's free and easy to use. Therefore, products are brought to the market quicker and at a lower cost. Whether you are an experienced developer working for a major corporation, a small entity with a single product line, a CEO, or an in-house counsel, if you decide to use OSS in your product you must be familiar with the license obligations. OSS is subject to license terms that are binding like a contract. If you don't comply with them, you could face a federal claim of copyright infringement. And, depending on how the OSS is integrated into your proprietary software, some licenses can transform aspects of your proprietary software into open source software.
DM: Most work is protected under copyright law and/or the terms of use (the license) provided by the author. Not respecting the copyright or violating the terms of use can result in the original author or open source community bringing a lawsuit against you or your organization.
In addition to an end-product not meeting certain compliance standards, are there risks and uncertainties as to how the end product will perform? Are there safety and/or security issues?
MG: This is not a question for the lawyers.
WT: All software has risks. There are potential bugs or potential security vulnerabilities. One hopes, when the open-source community is involved, that having more "eyes" will lead developers to work on something collaboratively and will help identify bugs or risks. The Heartbleed Bug in 2014 is an example of such a risk. Many developers were using OpenSSL crypto library and there was a weakness in the code that allowed malicious hackers to steal information.
DM: Security vulnerabilities exist in all code, commercial and free. You should be very selective when using OSS in critical or exposed parts of your applications. Chose code from well vetted, well supported communities for those components. The opposite is don't rely on OSS from single developer communities, that don't fix or respond to bug reports. And more importantly, put together a plan to monitor your "key" OSS components going forward. As the community finds vulnerabilities be able to react quickly to remediate any problems these issues may cause in your product.
Dave, with all the code out there to, for lack of a nicer phrase, secretly borrow for one's own glory, how difficult is it find "borrowed" code?
DM: Before I answer let me make one point. If someone wants to hide "borrowed" code they can. But most developers are using OSS to save time, so it's unlikely they will waste time trying to obfuscate the code. So with that said, the answer is that's it's very easy to find unobfiscated OSS, even down to the snippet level.
There are several vendors today that sell OSS detection applications that allow you to scan your code and find matches based on OSS "fingerprints." And, actually many applications will exhibit features and user experiences that come from OSS. So even at a high level just based on how an application works, folks can tell you if you are using OSS.
What methods do you use to track down the "borrowed" code and verify that it is in fact "borrowed" unofficially?
DM: The most common technique is to use a commercial "scanner" that will search your code and compare it with known OSS. Most scanners will also look for copyright statements, author information, license information, and URLs in addition to code matches. But just as important is to create policies and procedures that make it easy for your developers to report and track OSS as they download and begin to incorporate it into your applications.
Marco, I assume that once Dave find the illicit code, the matter is turned over to you for litigation?
MG: Hopefully, this is discovered and resolved before litigation initiates. As an attorney, we first understand what each license agreement requires, how it impacts the larger code base, and what clients need to do to comply with the license. After the audit is completed, we look at OSS in the product and create a compliance strategy.
How do you proceed from that point?
MG: What many don't understand is that each OSS project has a separate license, and many commercial products use different OSS projects with each subject to different licenses. Some of the licenses prohibit you from using the OSS with other software having conflicting license terms. Other OSS licenses require the developer to keep a modification log and to publish the modified OSS with the modification log to the OSS community. We assess the pros and cons of using each OSS project, to either help the client comply, recommend using another OSS project, or in some cases, advise the client to write the code themselves.
What are some of the penalties one faces by unofficially "borrowing" open-source code and claiming to author it?
MG: Depending on the way the OSS license is written, failure to comply with a material term could result in termination of the OSS license [See, Jacobsen v. Katzer 535 F.3d 1373 (Fed. Cir. 2008)]. As a result, sale and distribution of products or software including the OSS could subject a company to claims of copyright infringement. The U.S. copyright laws provide statutory damages for infringement, and the copyright owner may also seek an injunction, i.e., a court order prohibiting further sale and distribution of any products including the OSS at issue in the litigation.
Exactly how common is this practice of lifting code? Can you give some good examples and what was the result, either a blatant product failure or complicated litigation?
DM: From a security perspective, the Heartbleed bug found in the OSS library OpenSSL, affected most websites that use encryption across the world. For companies that had good tracking practices and processes for remediation were able to quickly fix the problem. Those that weren't scanning actively for OSS and tracking its use had the difficult task of first finding where they were using the affected code, how it was used, and how they would go about fixing it. This is why managing your OSS is so important.
MG: I don't think of it as lifting code. As I previously said, there is a significant benefit to using OSS. It is there for people to use. It is typically used with good intention, just a lack of understanding in terms of license obligations and compliance. Developers and their supervisors need to understand the legal aspects of OSS software. Several federal copyright lawsuits have been filed against business of all sizes because OSS software was used in violation of the license terms. In most instances, the compliance obligations are promptly satisfied, or the code is removed shortly after the lawsuit is filed. A payment is often made to the copyright owner and the case is settled.
What procedures, methods, and/or systems do you think could be implemented to stop or at least limit this practice of code lifting?
WT: Each organization needs to establish best practices. Things like peer review, using compliance tools like Open Logic as due diligence in their processes development. Sometimes there is plagiarism and code lifting, and sometimes in just an oversight and/or by accident. Good organizations will put some processes and procedures in place to manage their software development processes. Things like leveraging an existing code base that they have created, but this should also extend in how they embrace OSS, like how do they bring it, how do they vet it, how do they support and maintain it. As I mentioned earlier, using OSS is like a jump start. It is free of use but not free of development.
DM: I recommend at a minimum a simple declaration process for engineering organizations, where developers can record the OSS they download and use in their development. For a more comprehensive solution, organizations should consider creating OSS usage policies and a request-approval process their developers can follow. This way the business, technical, and legal departments can help steer and manage the use of OSS that goes into product development.
MG: You want to be careful to not scare people away from the legitimate use of OSS, which is a good thing. We just need to educate the developers to understand the obligations associated with OSS licenses. In the end, it comes down to understanding the OSS code used in development, understanding the legal obligations associated with that OSS, and defining a strategy to satisfy those obligations.
Are any of these methods in place now and are they successful? To what extent are they succeeding or not?
DM: The more mature organizations - I'm taking maturity from an OSS point of view - have OSS offices that set the policies and procedures for the use of OSS across the organization. These organizations take input from the business, technical, and legal groups. And they take the responsibility to educate and train the organization on OSS usage and management. By putting the policies in place and creating OSS management best practices they are able to mitigate and manage the legal, security, and support risks associated with OSS.
MG: In our experience, clients that tackled OSS compliance have done so successfully. Once they understand the various license obligations, they make OSS selection decisions early in the development process, not after the product is complete. Then, they have a compliance strategy in place before the product launches. This eliminates the risk and guess-work typically associated with OSS software. Education is key, and this approach is almost always successful.
From the above discourse we can conclude that open-source software in general is a great asset to be used to save time and costs in the development of new products. Like the development of said products, the designers need to do a bit of their own development within the OSS code. However, engineers should embrace OSS as they would War & Peace. You cannot move the commas, remove the exclamation points, and then claim you are the real Leo Tolstoy. ~MD
About the Author
Mat Dirjish is Executive Editor of Sensors magazine. He can be reached at [email protected].
Related Stories
IEEE Computer Society Identifies Key Drivers And Predicts The Future Of The Web
Microsoft and Arduino Partnership Announced