Embedded Linux Overview: Free Beer, Free Speech 23
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)."
This is worth noting re. GPL (Score:3, Interesting)
Without going into a dissertation on GPL, it should be noted the GPL expects companies developing or selling products based on (or containing) embedded Linux make source code to the GPL components used in their products available to their end customers who request it. Therefore, as a consequence of GPL, if you need kernel sources for some specific processor, you ought to be able to buy a device known to be based on that processor, that uses embedded Linux, and then request and obtain source to that processor's kernel from the maker (or supplier) of that device.
Indeed, some device and system manufacturers do make sources to the embedded Linux kernel and other open source software used in their products freely available (by some other means) to their end customers. Unfortunately, however, we have found that many device and system vendors appear to consider themselves "above the law" when it comes to the GPL's source code obligations. For example, the author recently purchased an embedded Linux powered device and, when he asked the vendor's support person how to obtain a copy of the Linux they used, was politely informed that their product uses "a proprietary version of Linux." Additionally, some developers of kernel loadable module code, such as for device drivers, believe that by packaging their code as a loadable module it need not be released under the GPL. Thus, you might not be able to obtain source to some of the Linux code in your system even if you are one of their customers.
Am I the only one who sees this as a serious breach of the GPL and an affront and insult to the free software community?
Re:This is worth noting re. GPL (Score:3, Interesting)
...and yet not tell the community which vendor he's speaking of! If what he says is true, and they're shipping a modified kernel and witholding the source, they are definitely in violation. So who
Re:This is worth noting re. GPL (Score:2)
Though I agree that stating the facts without an opinion and identifying the supplier would probably be safe, without mentioning why this is done (i.e. the possibility of a GPL violation), the point would probably be lost on many readers.
Re:This is worth noting re. GPL (Score:3, Informative)
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 [lwn.net], though apparently there is some effort being made to clearly define what "permi
Re:This is worth noting re. GPL (Score:2)
So, legally you are correct, but the practice is viewed with some disdain, particularly when a "toy" GPL application is provided, making it look like the code is free, yet it relies on a kernel module that does the real work.
Re:This is worth noting re. GPL (Score:3, Interesting)
Hmm... interesting. Is this type of behavior allowable under the GPL? It seems to be an additional restriction on how the software can be used. At first glance, I would think there's no difference between saying "You may not use this kernel module with non-GPL code" and "You may not use this kernel module unless you are a customer of company X".
Nevermind that, if a kernel module is under the GPL, there's nothing preventing me from modifying it to run without these restrictions, and then distributing the
Re:This is worth noting re. GPL (Score:4, Informative)
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.
Re:This is worth noting re. GPL (Score:2)
You're right, of course - that's easy to forget. Thanks for reminding me.
Re:This is worth noting re. GPL (Score:2)
Oh, but there is a world of difference! And, an error in your logic.
First, the GPL does not address use, except to the extent that use, including redistribution is restricted according to the manner of redustribution: If you do not redistribute, you can use GPL code any way you like. If you do redistribute, you an only u
Re:This is worth noting re. GPL (Score:2)
Re:This is worth noting re. GPL (Score:1)
Re:This is worth noting re. GPL (Score:1, Redundant)
Since your claim goes against common wisdon, I would very much like to see a cite.
Re:This is worth noting re. GPL (Score:1)
Re:This is worth noting re. GPL (Score:2)
First, you quoted out of context. Expanding the quote a bit:
This situation has thus always been a little unstable. It came up again in recent times when Christoph Hellwig posted a patch which explicitly made the Linux Security Module functionality available only to modules licensed under the GPL. People were, says Christoph, using the LSM hooks to change the behavior of
Re:This is worth noting re. GPL (Score:1)
Linus didn't care too strictly about licenses and copyright in the past. So, it would be very difficult to enforce the copyright on the kernel as a whole (that's why Christoph Hellwig had to invent that technical solution for his own modules).
Defacto practice just sucks: nvidia (or ati or whoever) creates that cool hardware we all need to have and makes it almost impossible to write free and legal drivers for it. That's why binary-only drivers are so dangerous and I'm so ha
Re:This is worth noting re. GPL (Score:2)
But what if they write device drivers? They are part of the kernel in a way, yet there are many binary-only modules out there, and Linus allows them. Thus, there
requirement? (Score:2)
1. I am using a stock SELinux 2.4.20 kernel, do I need to redistribute the source?
1a. Would a kernel configuration be acceptable?
2. Most of the apps included for Linux bootability are also stock, do I need to redistribute their source?
Re:requirement? (Score:1, Informative)
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. ]
Re:requirement? (Score:3, Informative)
Were I an embedded developer, here's what I'd do:
1) Read the GPL [gnu.org]. 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