Slashdot Mirror
Embedded Linux Overview: Free Beer, Free Speech
An anonymous reader writes "Never one to have his thirst for 'free beer' quenched, LinuxDevices.com contributing editor Kevin Dankwardt sets off on a quest to determine just how much freely downloadable embedded Linux software flows from the taps of commercial embedded Linux vendors' websites -- and discovers that there's a lot more available than you might realize. Read Dankwardt's guide to 'free beer' (well, uhm, free embedded Linux, that is)."
Hmm? I thought that this type of construct was specifically allowed. There are many companies who release proprietary code as loadable kernel modules - video drivers, for example. A quick Google shows that binary-only lkm's are permissible, though apparently there is some effort being made to clearly define what "permissible" means in this case.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
You don't need to _redistribute_ the source, but you do have to make it available to those who request it (free of encumberances).
A tarred-up copy of SELinux + other application source code is sufficient.
Of course, a kernel config and any custom code must be disclosed as well.
[ Ideally, a person should be able to take the source code you provide and build the system that you distribute in binary form. ]
In a word, NO!
Now, there is nothing wrong with this, as Linus Torvalds can license his code any way he likes, and contributors have to accept that license for their contributions to be redistributed. Since some contributers prefer a pure GPL position, for political reasons, the means are there for their modules to check, at run-time, if any other non-GPL code has been dynamically linked in, at least that is my understanding. I don't know if this technique can apply to any contributed kernel code, but I see no reason why it couldn't in practice.
It is my understanding that RMS is very upset about this particular exception, but that should come as no surprise. It has led to production of non-free drivers within kernel modules with minimal "free" applications under the misleading notion that the code (all of it) is free. I'm told that NVidia does this with some of their video drivers, and RMS considers that very unfriendly, to the point of NVidia being hostile to the free software community (Disclaimer: I work for ATI, a competitor of NVidia, but these comments are entirely mine and not representative of any position ATI might take).
But, the fact remains, proprietary kernel modules or not, if you distribute binaries of the Linux kernel, even if unmodified (your mods being entirely in kernel modules), the GPL obliges you to either (a) distribute the source, (b) offer the source to anyone who asks (not just the recipient of your binaries) and has received the binaries, or (c) point them to a well-known location where they can be found. Option (c) is only available for non-commercial redistributors.
Contrary to popular belief, this does mean that a pointer to an FTP site you maintain is not sufficient complience unless that's where the binaries came from -- that is you can't ship CDs of binaries with a pointer to an FTP site as the only means of obtaining source, though it is perfectly acceptable to do this as an alternate means.
Now, the GPL strikes me as a little vague when it comes to inter-process communication between cooperating processes as part of a whole. Tom Christiansen's "GPL-freeing" socket wrapper around readline() is an example of it. While it may be legally complient with the GPL (though I am not a lawyer and you should seek specific advice from your legal council), it is generally viewed as deceitful and unfriendly by many.
You could've hired me.
Furthermore, there's nothing that says you can't be fairly compensated for your time in putting the source on CD and mailing it (just be sure to obey clause 3b of the GPL - you can't include the administrative overhead of keeping track of the source in your cost for producing a source CD)
.iso's of the GPLed source that went into each release of the product - you do have everything under version control, right? - and stick them somewhere in permanent storage. You don't have to go nuts here, making sure that the iso is nicely structured or anything. Just put the source to the GPL'd parts in whatever format you already have it on the CD. No one says that you have to carefully think through UI considerations in your GPL section 3b compliance.
Were I an embedded developer, here's what I'd do:
1) Read the GPL. It's not that long, and as license go is very, very readable.
2) Place a "GPL compliance" notice in the printed documentation (along with any other required compliance notices, like FCC or other legal notices) that says something like: "Some of the source code used in FOOPRODUCT is covered under the Gnu General Public License (Gnu GPL). Persuant to the terms of that license, FOOCOMPANY will supply the relevant source code on demand for three years from the date this product was sold. Send inquiries to gplcompliance@foocompany.com and refer to FOOPRODUCT build number 123456a." (or "refer to the model number stamped on the bottom of the unit")
When I first bought my first linux CD from LSL, they printed the required GPL notice around the edge on the top of the CD. You could probably shorten the notice a bit, too, and get it down to something that could easily be put on a disklabel.
Then, set up an autoresponder at that address that says "here's what a CD of the GPL'ed source costs for us to copy, here's how much we'll charge you for shipping and handling, here's who to contact to actually order the source".
Then, I'd prepare
If it's part of the regular process for releasing a version of the product, (and archiving all the source somewhere permanent should be part of that regular process anyway) we're not talking about much additional overhead at all.