Hardware with GPL firmware

Question

I would like to know if selling a hardware product which runs a firmware is considered as conveying that firmware.

For example, if I want to use a GPLv3 library statically linked with my own code, I am required to inform the costumers that buy my products that they are running GPLv3 software? And licensing also my code as GPLv3? In such case, how I must inform them?

Note: the product firmware can be updated using the programming tools of the microcontroller, which loads the software into the microcontroller's flash memory.

And about a different but similar case: if I decide to employ uCLinux (a linux version for embedded products), can I ship the product with close source programs, which will run over the uCLinux OS, and offering the source code of uCLinux only?

Answer 1

I would like to know if selling a hardware product which runs a firmware is considered as conveying that firmware.

Yes. The binaries are inside the device and are therefore redistributed with the device aka. conveyed.

For example, if I want to use a GPLv3 library statically linked with my own code, I am required to inform the customers that buy my products that they are running GPLv3 software?

Yes, notification is the essence of most open source licenses including the GPL.

And licensing also my code as GPLv3?

Yes, when linking code (statically or dynamically) with GPL-licensed, the copyleft of the GPL would typically apply to my code and should be made available under the GPL or a GPL-compatible license and treated as GPL-licensed. You can also find more details on dependencies in this answer:

For Copyleft licenses, how (proprietary- or non-Copyleft- licensed) programs and Copyleft-licensed programs are used together, how they depend and interact with each other is the essence of what triggers the Copyleft clauses of the GPL and LGPL.

In the case of the GPL, I consider any linking as an "intimate" relationship where the copyleft would apply and extend to the caller.

In such case, how I must inform them?

This can take several forms such as notifying in the UI (if my device has such a thing) or the documentation. It should contain at least a notice and the text of the GPL. See also this answer (of mine) on: Does GPLv3 require attribution?

And about a different but similar case: if I decide to employ uCLinux (a linux version for embedded products), can I ship the product with close source programs, which will run over the uCLinux OS, and offering the source code of uCLinux only?

Yes, if my closed source code runs in userspace, this is considered a normal usage of the OS and I can use any license I please.

Linux (the Kernel) uses the GPL 2.0 with an extra statement per this answer:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.

No, if my closed source code runs in kernelspace, then the consensus is that this code should be licensed under a GPL or GPL-compatible license and treated as GPL-licensed.

And of course my device would typically combine both userspace and kernelspace code so a bit of both may apply.

Answer 2

This is certainly distribution (i.e., what the GPLv3 defines as "conveying").

In particular you are conveying the software "in, or embodied in, a physical product" so your options for required source distribution are described in 4(a) and 4(b), so you may either

• accompany your device with a piece of computer media that contains the source code, or
• accompany your device with a written offer for the source code, valid for anyone who possesses the object code, and valid for at least three years and not less than the commercial-support lifespan of the product.

The full relevant text is:

a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

The FSF's opinion is strongly that static linking creates a modified work, and the GPL's copyleft requirements apply to the whole combination:

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

Therefore, whatever code you statically linked to the GPL code would need to be included in the source you distribute with your product, and the combination needs to be licensed under the GPLv3.

As for the uCLinux case, it is a generally understood that userspace code is not affected by the GPL on the kernel. The mere fact that a piece of userspace software makes system calls to the GPL-licensed kernel does not impose GPL requirements on that software. If you include your own kernel modules (which is a very different case from ordinary userspace code), however, those likely are a modification of the kernel and need to be included in the GPLv3 work.