Buildroot in embedded project, what source do I need to provide for GPL compliance?

Question

http://buildroot.uclibc.org/

I understand that Buildroot itself isn't the GPL component, but in my company's embedded project, we use Buildroot to compile a minimized version of a Linux OS and use Busybox to run our actual application. Our core application does not use any GPL code, and is functionally separate from our OS generation/use (i.e., not specifically linked against it, etc.). I've been tasked with ensuring GPL compliance, but I've been reading articles all over and my brain hurts. I'm pretty sure I need to release at least some part of the system which compiles our OS, but I'm not positive how extensive it needs to be.

I don't really know of a better place to ask, and I know most of you aren't lawyers, but I know several of us have fought with this same battle many times, and perhaps could enlighten the rest of us (me) with your experience.

1) Is there a better place to ask this question?

2a) Do I satisfy the license by releasing only the buildroot folder of our repository, along with the configuration files we use to compile it?

2b) What about the components which are downloaded automatically by buildroot's make? We cache them locally in our repository for bandwidth and build time performance, but don't actually modify them (we have a buildroot/dl folder full of .tar.gz files) - do I need to release all of these too, even though they're downloaded automatically by the script if not present?

3) Speaking of scripts, we have a series of chain scripts which eventually builds our entire "world"; most of the targets are proprietary code and simply reside as files on the file system once the OS image is generated. Do I need to release the scripts which invoke buildroot's scripts "cd buildroot;make oldconfig;make"?

Answer 1

1) At the office of a lawyer experienced in software licensing :-)

2a) Probably not, but luckly you already asked the extra questions to reveal why not.

2b) Yes, you need to provide the source of the exact version you ship, even if you haven't modified it. It is not sufficient (at least for GPLv2) to rely on someone making the source available, even if that someone else is the original author.

3) Assuming GPLv2, you need to release the "scripts used to control installation". The meaning is dubious, but a reasonable interpretation would including releasing the script and any tools necessary to build the filesystem image or final firmware image.

Note that GPL compliance is not just about releasing the sources. You need to include in the documentation shipped with the device/software the GPL license, and one of the acceptable forms of pointing people at the source. (A link saying "download from " is fine.)

You may also need to release the compilers/toolchains you're using.

Another point is that this isn't a one off exercise - make sure you remember to release any updated source as new versions of the firmware are released.

There are two ways your company can approach GPL source release:

1. Release the absolute minimum that is absolutely required by the license
2. Release a useful set of source that allows people to actually easily work with your devices and easily make changes if they want.

(There's obviously the third way that many companies seem to take too, ignore it till someone sues you...)

Depending on your market, taking approach 2 and positively engaging with the open source could really help sales, as it can buy you a substantial amount of goodwill with the "geek" segment. In many cases it's that geek segment that recommend products to the non-techy segment, or have to approve hardware companies are buying.