Raspberry, firmware, GPL and headaches.

[uncle bit]

Hi everybody,

I'm involved in a project where a cheap Raspberry board would fulfill every hardware and computing requirements, but I'm concerned about the GPL concept which relates to Raspbian and the board itself.
I carefully read the GPL terms, without finding a suitable answer for the following use case: if I embed a Raspberry in my end product, and write some firmware to, let's say, blink an LED, am I forced to apply the GPL principle to the source code which blinks the LED?
I'm not altering the source code of Raspbian in order to build a bigger entity, nor I'm selling a software product which links to GPL distributed code other than system libraries commonly used in every Linux's system call.
I'm selling a black box which internally uses a Raspberry and Raspbian for the sole purpose of blinking an LED.
Am I breaching the GPL principle?

[Tandy]

The code that runs on the operating system does not need to be open, but if you embed a raspberry pi with an open source OS like raspbian then you must ensure that any alterations you make to the OS are made available. If you use the raspbian as it is then it would be considered good manners to tell people that is what it is running and direct them to the source for it if they ask.

If your software does not alter an open source package then it can remain closed if that is your preference.

[sokoloff]

You're fine for the contemplated use case, assuming by "firmware", you mean a normal user-space program that runs to blink the LED.

Obviously, if you use an RPi just to blink an LED, you're a frickin' moron, but I'll assume the actual use case is more complex.

NB: there is also an RPi compute module that is smaller and easier to integrate in some cases (provided you don't need HDMI, etc).
https://www.raspberrypi.org/products/compute-module-1/

ESP32 is another platform to consider, IMO; again, depending on the specifics of the project.

[uncle bit]

If your software does not alter an open source package then it can remain closed if that is your preference.

Fine, that's the main GPL concept as I understood it, but someone told me that every souce code involved in a project which uses a GPL related product would inherit the GPL concept.
Now the question is: how can a firmware developer know if he/she is approaching the threshold of a GPL principle breach?
If blinking an LED is fine, then blinking a dozen of LEDs should also be OK.
You could write thousands lines of source code to manipulate hardware signals in every possible manner, and yet obey the GPL concept.
You could write a function to manage some kind of communication, without actually know which libraries would be linked or involved in the process.
You could write a function to play some video and audio files, still acting in the user space without a direct concern of which libraries get linked in.
Should the last assumption be false, where was the boundary between a fine GPL project (the LED blinker) and a breaching GPL project (the multimedia player)?
In other words: what could I do in order to legally conceal my own source code when it works in a GPL related environment?

[daveshah]

If your code is running as a separate binary under a GPL kernel/userspace, or linking dynamically to LGPL libraries, then all you need to do is provide the unmodified source code to those GPL components.

If you modify any of those GPL components, link in any way to GPL components, or link statically to LGPL code -  then you must provide your code for all of those parts (but not any independent parts as above).

[uncle bit]

If you modify any of those GPL components, link in any way to GPL components, or link statically to LGPL code -  then you must provide your code for all of those parts (but not any independent parts as above).

That's interesting.
I don't modify nor link any LGPL component, but I'm not sure about the "link in any way to GPL components". Is the mere usage by an API and/or system call considered a link? It's certainly a kind of interaction, but how can I know for sure what code will be internally involved in every single statement I write?
As a programmer, I could know that writing "open_framebuffer()" I'm actually interacting with some library which manages an internal resource named framebuffer, but such a "link" is totally hidden and out of my direct control.
In other words, I'm not directly asking for a "link" to GPL code, but the system does it in its own when I write "open_framebuffer()".
Now, what if I write one source for a process which runs without referring any GPL code as in the LED case, and a second process which eventually runs a "sensible" function call as in the "open_framebuffer()" example?
Obviously, the two processes will share some data in some form, since they work in the same environment. Am I forced to provide both sources under GPL?
One of the sources would run an innovative algorithm I would like to keep away from competitors' eye :-)

[daveshah]

System calls to the kernel don't count as linking. Anything you are likely to link against will probably be either LGPL or GPL with a linking exception in which case you will be OK.

[nctnico]

If your software does not alter an open source package then it can remain closed if that is your preference.

Fine, that's the main GPL concept as I understood it, but someone told me that every souce code involved in a project which uses a GPL related product would inherit the GPL concept.

No, that is wrong. Only if you link your program to a piece of GPL sourcecode you have to open source it. Most libraries are not GPL but LGPL or a different license which allows to use the library in a proprietary piece of software. You have to check the licenses of libraries you are using.

[Tandy]

Some examples.

You write a program that runs in Python on the Raspberry Pi
You are using Linux and Python but your code does not incorporate or modify any GPL code. You ship a product that contains Linux and Python, if someone asks you for the source code you simply direct them to the Rasbian source as you have not modified it.

You compile a C program that uses the GNU C Library
You are running an unmodified linux system and the GNU library as a shared library, the LGPL license allows you to use the GNU Library in your code without having to release the source code of your own software.

You compile a C program that incorporates a GPL Library
If your code includes other code that is licensed under the GPL then the whole code must be made available including your code.

You modify and recompile a GPL package in Linux
Lets say you have to modify something in the Linux distribution to make your code work. For example you need to modify the USB stack code so that it can talk to your hardware. The source to any modifications you make would need to be made available. If however your stand alone code simply makes calls to the modified version of the USB stack then that can remain closed if you chose.

To be honest though, unless you have something particularly unique why would you bother keeping it closed?

I mean if you have something that reads a few sensors and flashes a few LEDs then any teenager is going to be able to build something similar in a few hours in their bedroom. It is not as though keeping it closed is going to give you any competitive advantage. In fact opening it may be better as people are likely to find problems with your code and offer solutions. Also more people will adopt it (if it is good) instead of building their own open alternative to replace your closed software.

If on the other hand you have some complex algorithm that has taken hundreds of hours of pain staking work then there would be some advantage keeping things closed to prevent someone else producing a clone of your work overnight. Other than that seriously look at embracing open source.

[sokoloff]

If on the other hand you have some complex algorithm that has taken hundreds of hours of pain staking work then there would be some advantage keeping things closed to prevent someone else producing a clone of your work overnight. Other than that seriously look at embracing open source.

If you're shipping an RPi as a standalone device, it's going to be extremely difficult to prevent cloning. OP seems to be trying to prevent someone else reading the source code, not preventing cloning the device.

[Tandy]

By clone I meant create something that is functionally the same from scratch rather than cloning the SD Card image. if the application is quite simple then anyone can reproduce the function in a very short time, so keeping it closed source won't prevent someone having a functionally identical thing for sale in a few days. If however it is complex a lot of reverse engineering work would be required to copy the functionality without making an illegal copy of the authors code.

[uncle bit]

If you're shipping an RPi as a standalone device, it's going to be extremely difficult to prevent cloning. OP seems to be trying to prevent someone else reading the source code, not preventing cloning the device.

Yes and no. Let's say I would like to sell an innovative hand held device which performs some action. Everyone can see that action, and almost everyone with minimum tech skills can imagine some kind of advanced microcontroller inside.
The RPi would simply play a master role in a bigger hardware scenario, thanks to its good price / performance ratio in small, low volume projects.
I'm not concerned about a few copies of the device itself, I'm concerned about a competitor who peeks at my algorithm and uses the knowledge to build a whole range of similar devices from a China based plant.
I know that I can't protect my work form reverse engineering by enthusiasts, hobbyists and motivated competitors, but I would like to keep the things on the hard side, avoiding to be legally forced to share my algorhitm to anyone picks up the phone invoking the GPL principle