|(Image source: Markus Spiske, temporausch.com from Pexels)|
Microsoft's recent acquisition of GitHub, the largest repository of open-source software on the Internet, was only the latest in a trend that has been happening in open source software since about 2016. Specifically, large companies and even governments have begun to embrace open source in their workflows. In 2016, the Obama administration even established a Federal Source Code policy for government agencies to improve access to their source code.
But this new level of adoption also comes with hidden pitfalls. In its 2017 Open Source Support Report, Rogue Wave Software—a provider of software development tools and libraries as well as embedded components—found that in 98% of audits of its clients' software, the source code contained open source code of which the company was not necessarily aware.
While this may not sound immediately problematic, it does carry a host of potential legal and security issues that could come back and haunt developers. With embedded development finally embracing open source, engineers working on embedded applications and devices now have to be wary of these issues as well.
Ahead of his talk at ESC Minneapolis, “Are Open Source Software & Embedded Software Development on a Collision Course,” Rod Cope, CTO of Rogue Wave Software, spoke with Design News about what open source really means for embedded development. He also discussed how open source code ends up in devices without anyone noticing and what every embedded engineer needs to know before bringing open source into a project:
Design News: When we're talking about open source, are there specific or unique considerations for embedded developers?
|Rod Cope (Image source: Rod Cope / Rogue Wave Software)|
Rod Cope: There are two main ones. One is related to the legal aspects and the licensing of the open source itself. I've done a lot of talks over the last five or six years to embedded audiences—in particular at ESC and other conferences. And this is one thing that keeps coming up because embedded developers aren't always aware that they're using open source.
In some cases, they say they're not using any open source. Then, we'll ask questions and find out they actually are using Python or BusyBox or something like that and it is open source. Then, developers find out some of the open source code they are using comes with licenses that require them to make the source code publicly available. Or they're compiling or binding or linking with their own code or using things like GPL [General Public License], which would mean they'd have to open source all of their code. So there's just not a great awareness of that. There are some compliance issues certainly and people might run into trouble if they're not aware of how the open source code is licensed and what they need to do to comply.
The other aspect is related to security. I think that's a big one that is becoming more and more popular. People making embedded devices put code on a device, they ship it out, and they think it's a one time effort. They don't think that it has to be maintained in the sense that the software, if it hasn't been updated and patched for security issues, is basically just a huge source of vulnerabilities and could lead to all kinds of problems.
Developers really need to have the mindset that security is not a one time thing. It's an ongoing thing. So how do we offer remote updates or ways to facilitate changes in any device—certainly, ones running Linux or anything sophisticated on them? That's got to be taken into account. But a lot of times, it's not.
DN: So you're saying your company does these audits and you find out that developers aren't aware that they're using open source in some cases. How does that happen?
RC: [laughs] You think it'd be pretty straightforward, right? Somebody had to place the open source in the code base. But a lot of times, developers think, 'Well, I'm just looking to solve the problem, so let me search Google...Okay, here's some code that does what I need. Let me just download that and stick it in.' And a lot of times, developers—especially more junior developers—aren't familiar with open source. They think code is code, and it doesn't matter how they get it—whether they write it themselves or download it.
It's actually surprising when we talk to people and find that they actually knew most of what they have. That's almost never been the case.
So a lot of times, the code is grabbed from open source because it's a lot faster than writing it on your own. It already works, has already been tested, and developers don't think about telling anybody. So a lot of times, that will happen across teams—especially in a decent-sized organization, where the developers don't necessarily know all the components that are being brought into a device. Especially if you are looking at something more sophisticated, like if it runs Linux or is a car entertainment system or something like that, a decent amount of software can be convoluted and nobody really looks at it. Before you know it, there are a bunch of different components being put in where only one person knows about each of them. And suddenly, you're shipping something with a lot of open source in it. And some of those licenses can run into trouble, depending on the way you use them.
A lot of times, managers don't really know what's in there either. They kind of ask the engineers and they send out an e-mail and say, 'Hey, please update the spreadsheet with what you're using.' Of course, hardly any developers ever respond to those emails. If they do respond, they respond with whatever they happen to remember. So yes, it is more common than not that we find a lot of stuff that people don't really know that they're using. It's actually surprising when we talk to people and find that they actually knew most of what they have. That's almost never been the case.
DN: Using open source can save a lot of time and energy by keeping developers from having to write all of their code from scratch. But is that really the only advantage of open source? How do you talk to people about other reasons they should be using it?
RC: Well certainly, that's the big advantage. We live in an accelerating world, where getting products out to market faster is becoming more and more important over time. It used to be you had years. Now, you've got months. You really can't afford to write all the code yourself and be competitive anymore, because you need so many features and such a great user experience. You don't have time to write it all. You have to use something. You have to use libraries from third parties. Otherwise, you can't go fast enough. I think there's nothing wrong with that as long as you know you're doing it right.
If you are going to use software, make sure you know how it's licensed and if it's open source. The trick is to find out not just how that one component that you think you're downloading is open source, but all the dependencies that component can drag with it. A lot of times, especially for a significant open-source package, it's kind of like an iceberg: You only see what's above the water. You say, 'I'm downloading this thing, but that requires five others.' And two of those require three other things. And before you know it, you've got this whole pyramid of stuff, and all those things can be licensed differently and have different compliance requirements.