What's in your software?

Channeling our inner Samuel L Jackson -- but really, do you know what is in your code? Automatic code generators, downloaders, and builders are making the world a whole lot more complicated.

Speaker: Terry West  

read podcast TRANSCRIPT:

If I had infinite marketing dollars, I think I would be tempted to hire Samuel L. Jackson and he'd be on my set to help me out with my advertising. I would call him SLJ and try to be really cool, but probably I wouldn't. I would be scared to meet this great actor. In addition to his great acting, he is famous for his commercials as well, with his famous tagline - "what's in your wallet? That is the tagline that came to mind for this podcast: What's in your software?

I was wandering by one of my engineers desks the other day - Nick. And Nick was putting together a Linux package that is kind of like a driver, I'll call it a super driver. It's an interface package to our board so that you can write Linux applications on embedded Linux platforms and talk through USB, or through Ethernet, or whatever, to one of our platforms. And you could exchange data with the platform, upload new firmware to the platform, push a file (like a JPEG) out there. We're starting to see some customers that have traditional embedded Linux platforms as the engine for whatever it is they're doing. And surprisingly, rather than using QT or a monitor attached to the platform they're looking at using some of our HMI solutions (which of course are not Linux, they're an embedded platform) and then communicating with it. It's an interesting usage model. Part of the reason for it is licensing of QT is not simple. If you want the free stuff that's fine, but now you're subject to GPL. In fact, it's going to be GPL V3, which is particularly nasty for those of us who like to own software.

So, people are becoming more averse, surprisingly, to using QT in embedded applications. And certainly, an embedded monitor is relatively expensive. If you're talking HDMI and, of course, you're adding that capability to your motherboard. So now you've got a Linux motherboard with video output controlling a monitor – there's a fair bit of expense in the process. So much so, that customers are starting to use our embedded HMI modules (which are lower processing power, lower memory, but still give a great UI) and connecting it to their headless Linux system and moving data back and forth between the Linux system and the m HMI.

It’s an interesting usage model which we didn't quite expect. We thought that if you got to an embedded motherboard for Linux or for windows you're going to just use the drivers in Windows and Linux and run a monitor. Well it's not happening that way. So, we're surprised.

Back to my story though. I'm dropping by Nick's desk and he's building this Linux driver plus interconnect capability so that people can write apps on the Linux platform to talk through this thing over to our platform. I'm watching him build the driver and create a package that can be deployed. Think of that like a zip file or an executable, that under Linux you would just install, and it would unpack and put all the right things in the right places. It's a lot like windows. You say, "I want to update my driver. I want to update my application whenever" and they'll go over the web and they just do things automatically. As users of PCs, we have absolutely no clue what's happening during that process. Right. I mean even the techie amongst us are going, "OK it's probably downloading some files it's installing some things. " We only get frustrated, techie or non-techie, when somebody installs something on our PC and it makes the PC not work. We've all had that experience where, suddenly, we say, "what the heck? My keyboard used to work. or my mouse used to work and now it stutters." And you wonder who installed what on your PC and what happened.

So, I'm watching Nick build this package. And part of this package for this driver/connector thing application for Linux is our code. That's the stuff we write to glued it all together. Part of it is a variety of little pieces that you need (whether it's USB type elements or other elements) that are part of the Linux code base in the community. Which may or may not already be installed on a Linux platform. So Nick goes through and he identifies each one of those in some file. When he builds the package, it goes and pulls those things live from the web. It grabs this file from this place, that file from that place, and this file from that other place. It puts it in a big, I'll call it a zip file, but it's probably some sort of Linux package file, and puts all that together with our code. Voila, you now have a package that we can give out to customers.

And remember our customers are engineers. They're not end users that are running desktops and laptops. So that package would then be used by an engineer who's trying to build a Linux load for their embedded product (whether that's a kiosk or whatever it happens to be) and they are trying to figure out, "what do I need from a Linux distribution perspective to put on that board that I can ship out now."

In the old days (I'm telling my age), we would have a directory or a file system on our PCs. We would download all the pieces that we know we needed and we would put them all in a directory structure. We would say, "okay that's in my code." And we could, if we wanted to, go through all the files in that code and figure out what it was. We could look at all the license agreements inside that code and make sure nobody had done anything stupid. Make sure that we weren't distributing a piece of code that we weren't supposed to. The process was fairly predictable.

Then, when we wanted to upgrade to our latest version of a software, we would very deliberately go out and grab a few pieces and integrate that into that directory. Check what changed. We would see what's changed, make sure it all had good license agreements, that it all played nice together. Then we would have a new package. Very predictable. A little cumbersome, but you must be deliberate about that process, right?

I say that rhetorically. When I watched Nick build this package, he had identified all these little pieces of Linux that were required to put this package together. As he said 'Build’, it went out to the web and grabbed stuff from the web. One at each of those files dynamically put it together and created a package. I said "oh, that's really cool! You mean it's just going out automatically to the cloud and pulling the stuff out from the web." I said, "How do you know what version you're getting?" And he said, "Well, you can't really tell." I said, "How do you know what license agreement is associated with each one of those files?" "I don't know," he said. I said, "well, and how do you know you're not getting one that doesn't work and play nice with another one." He responded with "Well, I have to test it." "OK. So let me back up. So what you're telling me, Nick, is you have no idea what license agreement all these old files are. So if somebody updates all those files and squeaks a little nasty license agreement like GPL V3 and one of those files, you have no idea." He concluded, "No, you don't really have control over your versions."

And maybe Nick needs to learn something about versions there. I said, "so is this what we're distributing." He said, "Oh, no, no. It gets better." How can it get better from this? He said, "See what you do is, you put our stuff. All we really have to do is put a recipe on the Web and our specific file. And then when customers have their motherboard, or whatever it is, and they want to build their distribution, they just take our file and they just take our recipe and go say install. Then, our website will pull our file that just has our stuff. Not anybody else’s, just our stuff. It'll pull the recipe that says what else is needed. And when the customer's actually building, it will then (at that point in time) dynamically pull it from the various websites." He said, "that's great because we just distribute the recipe and our file; that's it. The rest is the customer's problem.”

And I went, "oh, and this is better?" He said, "Yeah, because we don't have to create bundles or prepackaged anything. We just have to put our single file up in the recipe and when the customer does the install and says, ‘I want the serious driver’ - I just install this package and it goes and gets everything it needs." And I said, "is that the way things normally are." "Yeah, that is," he said.

This is consistent with what I've seen around building distributions. In the old days, again we used to have things called Makefiles. They would describe all the pieces and you would configure the makefile in a file called Makefile.config.

And it was very predictable.

Now, everything is built dynamically. When you build something for Linux it just goes and gets stuff from the cloud (from all over the world). In fact, we are building something the other day. Our firewall has Russian domains blocked because it just created too many problems (i.e. attackers, malicious activity, harvest, and viruses and all that stuff). So, at some point we just decided to shut the firewall for certain geographies in the world that are particularly troublesome. Russia was one of them and so we did. Well this installer wouldn't run, because some of the files it was fetching were from Russia. We have no idea what they were, but without them it wouldn't install. We have a whole bunch of geographies like that that we've shut down that we think are not worth keeping open, because they're more trouble than they're worth.

One of our engineers went to install the schematic and PCB design package, Altium, that we use. It would not install in the office because it was pulling from servers from geography's that we felt were completely unsafe and inappropriate. But the minute the person tried to install it from home, it worked fine. So here we were installing a program that pulled pieces as part of the installation program from lots of high-risk places, from a security perspective.

This Linux installer that Nick is talking about in this whole process was exactly the same. So I'm going to get to the point now, what's in your code? (I'm not going to attempt to do it in Samuel L. Jackson's voice). What's in your code?

Either you have a supply chain for your code that says: this is your code. This is the version. We've scrubbed all the license agreements and there's nothing bad in there that's going to force you to give away all your IP or sign over all your patents.

There are license agreements out there that say, "hey, if you use this code (any code that is linked to it) you have to publish to the public domain. GPL V3 goes even further. It says, if you link to the code you have to publish your code to a public domain and you must allow people to rebuild the codebase. And when they rebuild the codebase, they must be able to reinstall that rebuilt code base with whatever changes they want into your device. As you can imagine, when TiVo lost the lawsuit in Germany several years ago on this very point, the whole goal for those folks that were taking TiVo to court was the ability to take the TiVo source code (which was Linux based) remove the commercial skipping, and all the content protection and copy protection, rebuild the code base (put it back into the TiVo box) and have commercial free (absolutely free) television.

At that point, all that code was based on GPL version 2. While the court sided against TiVo, and with the free software foundation, that TiVo had to publish all or code. TiVo published all the code in the TiVo box. What TiVo didn't do was make it easy to rebuild it. And they didn't make it possible at all (if you had rebuilt it) to put that code back in the box. So, TiVo thought "aha! we've got it! Yes, it's unfortunate that we had to all our code, but nobody can really build it unless they're wizards. And even if they could build it, they couldn't put it back in the box."

That was what GPL version 3 was for. From the Free Software Foundation's perspective. It was to fix their perceived loopholes. From their perspective, they say that nobody should be allowed to do that. You should have to publish your code. You should have to help people recompile your code if they can't. So that's in GPL v3. You must help people read compiler code. Even if not your customer. Even if they're not paying you any money, you must make it really easy for them to rebuild the code and you have to allow them to put it back in the box that you shipped.

Theoretically, are now liable for the code that's in the box. That's a really interesting question. What if you're building a car and you had Linux in your cluster (in the central cluster for command and control) and because it had GPL V3, somehow you were obliged to not only publish the source code; allow people to modify the source code rebuild it and put it back in the car. Then they're driving and they have an accident because something weird happened in the software. Who's liable for that?

Are they liable because they made the changes? Are you liable because somehow you enabled them? Obviously, if you're a car manufacturer, you've probably got deeper pockets than the person who was driving the car.

So it opens up a very interesting problem. What's in your code?

Do you know every license agreement in your code?

or do you have a partner who's helping you sort through that stuff and giving you an assurance or a guarantee that all that code is acceptable?

Do you know what version(s) it is? Do you know it's not going to change underneath you (so that you don't have validation issues and conformance issues)? Does it work?

How do you test it? If it's always changing every time you rebuild your distribution do you have to retest every time. Do you have to validate your license agreements? It's a very interesting problem.

I don't have any solutions for the folks in the Linux world. There probably be a lot there are better advertising solutions. I'll expand this beyond Linux, because it's not just Linux. It's all open source code, where this whole movement towards auto-building, auto-generation of code bases even code-generator generators that are just creating code on the fly and mapping it with some license agreement. Do you know what's in your code?

Return to Podcast Main Page


embedded technology blog

Visit Blog



captain's log embedded podcast


The challenges of HMI and IoT can be overwhelming. Listen weekly to our Captain – Terry West, CEO – on industry trends he sees and implications for the embedded systems designer. 

You'll find practical thought leadership conversations covering all facets of embedded technology, human machine interface evolution, architectural challenges, IoT readiness, and much more.


Podcast General App Image-100.jpg

You can now stream the Captain's Log on Podbean, iTunes and Google Play Music!

Available on Podbean.jpg


Listen on Google Play Music