The vast majority of questions I get about combining GPL and proprietary software concern embedded systems, since Linux is a component of so many consumer products these days.
It’s impressive, for instance, to look at Sony’s web site where they fulfill their GPL obligation, and see the dozens of TV models and many other products that contain Linux. So, this discussion concerns primarily embedded systems.
(Desktop and server applications really only have one path to keeping Open Source and proprietary products separate: make them physically separate programs, each with its own license.
Fortunately, most of the libraries on a Linux system are under licenses that allow them to be combined with a proprietary program without trouble.)
Linux is a natural for embedded systems. That’s why it’s popping up in more cell phones, often without the customer even realizing it’s there.
But cell phone manufacturers, and the broader sector of embedded systems, must cope with the problem of how to combine the GPL Linux kernel, and software that isn’t Open Source. How does one do that legally?
Most of the publicity over suits to enforce the GPL concerns embedded systems: set-top boxes, cable modems, the list goes on.
The suits are caused by just one thing: engineers and their managers combining software from different sources, without going to their company’s own lawyers for help in understanding the software licenses.
They’re used to just “clicking yes” with no regard to what they’re committing themselves and their company to.
The very worst offenders sell their designs to other, much larger, companies without conveying what the licenses are and what obligations the big company must fulfill – and then the big company gets sued.
This problem isn’t specific to Open Source: violation of proprietary software licenses, with their higher stakes, is rife in the embedded systems industry.
Fortunately, it is possible to combine different sorts of software legally, if your team puts some thought into it.
The first thing you’ll need to do is to build a partnership of your legal organization and engineering.
This requires giving engineers sufficient training so that they’ll recognize a copyright issue when they encounter it, and will know to call in legal for help rather than attempting to solve the problem alone.
On the legal side, they must be aware that engineering is scored by fulfilling goals on time, and that when they call for legal advice, that advice has to come quickly enough that the engineer isn’t put off schedule.
Often, an engineer who has been delayed too long will simply go ahead without legal advice, due to the need to fulfill his schedule. And that can cost you big bucks later.
Legal-engineering reviews of how software is combined need to happen early in the design process, when the cost of making a change is low.
Finding an issue of license non-compliance or copyright infringement when you’re two weeks from shipping the product is much more expensive.
It’s important for management to completely understand why you need to hold some software close, while other software should be open.
There are really only two good business reasons for keeping software proprietary: that the software provides a business differentiator, making your product visibly better in the customer’s eyes, or that the software component doesn’t belong to your company, and thus you’re not the one who decides whether it’s open or closed.
Surprisingly, all of the cellular telephone handset manufacturers I’ve talked to designate one product as the software that they must hold close at all costs: the GSM stack. This is the software that actually links your telephone with the rest of the cellular network.
But the customer’s only concern with the GSM stack is that it works. It’s not business-differentiating, because every phone has a GSM stack, and they all do pretty much the same thing.
But the GSM stack costs each of these companies many millions to develop, so it must be valuable, right?
Not quite right. One GSM stack is valuable. 20 independently-developed GSM stacks that do the same thing, without customer-visible differences, are a waste of a few billion dollars across the industry.
The trend has been to place the non-differentiating parts of technology into Open Source projects, where competing manufacturers can collaborate on their development, each putting less into the task than if they’d done it alone, and getting the benefit of the entire software development.
Thus, we see projects like Android and the Symbian Foundation, concentrating on the non-differentiating parts of the phone in public projects.
The next step, obviously, is to put a GSM stack into such a collaborative project. Companies facing hard times can save millions of dollars in development expense by doing so.
So, what might a cellular handset manufacturer sensibly wish to keep proprietary? Software that the customer sees, and that makes their phone different in a customer-visible sense from competing products.
The one remaining reason to have software that’s physically separated from Open Source is lock-down.
In the U.S. cellular market, the network vendor generally wants to exercise control over the software in the telephone, perhaps to make sure you’re using their services rather than just anything on the Internet.
Network neutrality hasn’t yet arrived at U.S. cell phones. In Europe, handsets and cellular network connections are often sold separately and the network vendor never has the opportunity to control the internals of the phone.
The cellular carrier will still want to lock down the GSM stack to keep the phone behaving well with the cellular network and in compliance with the rules of FCC or their national radio authority.
So, we arrive at a few different sorts of software that must somehow be combined in your embedded device:
- Software that must not be modifiable, for some business or regulatory reason.
- Software that is proprietary to your company or another company, and is protected by copyright and trade secret law.
- Open Source software with “gift-style” licenses, like the BSD license, which don’t present significant compliance requirements, and can be combined directly with proprietary software.
- Open Source software with sharing-with-rules style licenses, like the GPL, which requires a continuing license compliance process, and which must not be directly combined with proprietary software.
You might ask why all Open Source can’t be licensed with the “gift-style” licenses, since those licenses allow you to combine the Open Source that they apply to with proprietary software, and they are easy to comply with.
A good answer is that not everybody wants to give your company a gift, but people who use the GPL have a good alternative: their license is an invitation to share work – modifications to their program – with them.
In general, the Open Source developers aren’t on your payroll. They might use a GPL-style license because they are commercial companies, and they don’t want their competitors running away with the product without sharing their work on it.
Or they are individuals, and they feel the “sharing with rules” is a good reward for their own work, as others will work to improve and expand their program, and to expand Free Software in general.
So, there might be some amount of proprietary software that you might wish to have in your product, and some amount of GPL software.
The GPL requires that modifications to the GPL program be licensed compatibly with the GPL itself: given to the world for free in source-code form with the right for anyone to use, modify, and distribute.
So, we can’t combine GPL and proprietary software directly. There are a few ways that we can combine it, though, which won’t violate the license of either program.
Cell phones often have two processors, a small one that concerns itself with the basic operations of the telephone – the interface to the cellular network – and a larger one that provides the PDA-like functions of the phone.
These used to be an ARM-7 for the smaller processor and an ARM-9 for the larger one (the numbers might be different today).
Often both processors are physically on the same chip, a custom ASIC (application-specific integrated circuit) that is the core component of the phone.
The GSM stack lives on the smaller processor, and communicates with the larger processor using a very simple control protocol derived from Hayes modems of the 1970’s.
The smaller processor runs a compact real-time operating system or no operating system at all.
The PDA-like functions live in the larger processor, which runs a more powerful operating system based on the Linux kernel, Windows CE, Symbian.
The smaller processor listens for phone calls continuously, while the larger one sleeps to save battery power when the user isn’t interacting with it.
With two processors, it’s clear that the programs in one are separate from those in the other processor.
As I’ve described this, it already keeps the GSM stack in its own space. Other software that must be locked away from the world – like a DRM system – can live there too.
With this sort of organization, it is possible to change all of the software in the larger chip, and the software in the smaller chip continues to do its appointed tasks properly.
Properly handled, this organization can even be used to host software under the newer GPL3 license alongside of software that is locked down and provides DRM, things GPL3 eschews.
Although the Linux kernel is under the GPL, applications that run on top of it do not themselves need to be under the GPL, and they can be under any license.
User-mode programs are where most of your business-differentiating software belongs, since they interact with the user.
The only programs you might not want to put here are ones that need to be very thoroughly locked down, that need to provide real-time services or that handle hardware interrupts directly.
Kernel Under A Kernel
Just as Linux does not insist that applications on top of it have the GPL, a kernel running under Linux, in a separate hardware address space, can be used to insulate proprietary software from Linux.
Recently, virtualization systems have been used for this task, although they are probably too large for embedded applications.
What Not To Do
Don’t assume that you can put proprietary kernel drivers in a run-time loadable kernel module.
The legality of such a practice is dubious, and there have not been sufficient cases to say reliably what would happen if you were to get sued.
Also, don’t look for, and use loopholes in the Open Source licenses. Nothing makes your company look worse than taking unfair advantage of people who provided their work to you without charge, expecting in good faith that you’d honor their license.
It also tends to make Open Source folks reluctant to cooperate with your company, the next time you need help with their software. And it looks bad to judges, too.
Don’t try to do what I’ve discussed without legal counsel to advise and review your actions.