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)."

Comments

t sop TSR if, first post

[DNA Land]

I think I still prefer WindowsXP Emmbedded, Free as in Tibet.

Young ada had a GNU, Oy!

Re:t sop TSR if, first post

[Anonymous Coward]

thats embedded to you, mister retsim!

(fp haste is a leading cause of stupid typos)

This is worth noting re. GPL

[renehollan]

From the article (and perhaps I am stretching fair use doctrine a bit by copying two whole paragraphs, but I wanted to get context clear):

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

[phyxeld]

I don't understand why he would make such a serious allegation...

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."

...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 is it?

Re:This is worth noting re. GPL

[renehollan]

don't understand why he would make such a serious allegation...

... perhaps precisely because it is a serious allegation and the author is not a lawyer.

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

[Samrobb]

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.

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.

Re:This is worth noting re. GPL

[renehollan]

Yes, this is explicitly permitted by the license on the Linux kernel, but, IIRC, there is also an option honoured by the kernel that allows a module to indicate that it should not be loaded unless all other loaded modules are GPL.

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

[Samrobb]

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 new binaries and code in accordance with the GPL. If this is primarily a method of making a statement, then it's a weak one at best.

Re:This is worth noting re. GPL

[Captain Large Face]

Too true -- I use the nvidia module as a driver for my graphics card. You'll get a warning about tainting the kernel, but there's nothing there to break the GPL, as I understand it...

Re:This is worth noting re. GPL

[valshaq]

If you had read that article instead of just posting it, you would have noticed that binary-only modules are illegal and even Linus agrees to that nowadays:

This is, of course, an explicit shot across the bow of anybody who distributes proprietary kernel modules. Linus, then, sent out his current view on binary-only modules:

There is NOTHING in the kernel license that allows modules to be non-GPL'd.

(cited from that very article :-)

Re:This is worth noting re. GPL

[renehollan]

Hmm... interesting. Is this type of behavior allowable under the GPL?

In a word, NO!

...and I'm sorry if I gave that impression. What you miss (and I failed to make clear) is the the Linux kernel is not licensed under the GPL. It is licensed under the GPL with a specific exception for kernel modules.

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

[renehollan]

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".

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 use the code, including performing that redistribution if you redistribute under the terms of the GPL. There's a subtle point there: if you do redistribute in violation of the GPL, you lose your right to anyuse, including non-redistributive uses.

As you your second point, the license probably forbids what you are considering: remembering it is not GPL in that case -- it is "GPL but can only be dynamically linked with GPL code or code under this license". This is (a) fine for dynamic linking with similar code, and (b) fine for dynamic linking by the kernel because the kernel makes an exception for non-GPL modules (which, ironically causes the problem in the first place) which this is -- it is using the exception against itself, as it were.

Re:This is worth noting re. GPL

[Samrobb]

What you miss (and I failed to make clear) is the the Linux kernel is not licensed under the GPL. It is licensed under the GPL with a specific exception for kernel modules.

You're right, of course - that's easy to forget. Thanks for reminding me.

Re:This is worth noting re. GPL

[renehollan]

Perhaps you are citing a different article. The text you cited appears nowhere in the article in question.

Since your claim goes against common wisdon, I would very much like to see a cite.

Re:This is worth noting re. GPL

[RAMMS EIN]

It's a grey area. If they modify parts of the Linux kernel and distribute it, then they have to make available the sources no their changes under GPL. If they add their own applications and/or libraries, they have no obligation to do so (although they still need to make sure the sources to the version of Linux they are distribution are available).

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 is no need to publish the sources for everything. Now whether or not a vendor breaches the license agreement depends on what part of the code they won't release, what chatges they have made, and whan provisions have been made in the licenses (e.g. binary-only modules could be allowed as an exception to the GPL, or there could be some sort of implicit non-prosecution agreement).

Re:This is worth noting re. GPL

[valshaq]

http://lwn.net/Articles/13398/ (fifth/sixth paragraph) And no, it's not illegal to MAKE such a module but to distribute it ;-)

Re:This is worth noting re. GPL

[renehollan]

Your quote was from a different article. This thread was referring to this article. Still the points you raise are worth respondong to.

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 system calls, and that went further than he thought was appropriate. In a separate posting, Christoph stated:

My argument is that I want this flag as a hint for authors of proprietary security modules that I'm going to sue them if they use hooks called from code I have copyright on. This includes such central parts as vfs_read/vfs_write. This is, of course, an explicit shot across the bow of anybody who distributes proprietary kernel modules. Linus, then, sent out his current view on binary-only modules:

There is NOTHING in the kernel license that allows modules to be non-GPL'd. The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

Starting with Linus' note, he (and you) are correct): it isn't the kernel license per se. that allows non-GPL modules, but the fact that they are not "derived works" of the kernel. Linus has always maintained that modules are not part of the kernel, and therefore not subject to the GPL. He could have argued that they are part of the kernel, and the situation would be different (while copyright law would not allow this, given the non-derivative code shield, the kernel use license could have required agreeing to that fact by anyone who distributes the kernel with non-GPL modues -- the kernel license then would not be GPL, of course).

It becomes a point of semantics: is Linus' traditional position part of the kernel license or not? Some would say yes, others would say no. In any case, as author of the kernel (yes, I'll address other contributors later), he is free to selectively relax restrictions in a the license thereof to the benefit of licensees. This is the same reasoning that lets a late payment be "forgiven" at the discretion of a lender even though it may technically make a loan in default.

What Christoph Hellwig has done, since kernel modules do not have to be GPL, is license HIS module to forbid binding by other non-GPL modules. Given Linus' position, I see this as perfectly acceptable.

However, as others have contributed to the kernel (and not just modules), perhaps their interpretation of Linus' lax enforcement of his license isn't all that pleasing to them: some might not want to see non-GPL kernel modules using their code at all.

While I would think that their creation of a derived work would fall under the terms of the license that covers derived works, the issue is whether this license is just the GPL, or the GPL with Linus' informal note that modules are not derived works and therefore not covered by the GPL. While I am not a lawyer, I'd think that Linus' interpretation of derived work forms part of the complete license, including the text of the GPL. Thus, those who produce derived works of the kernel must redistribute them under terms of the original license: GPL with Linus's definition of derived work. Copyright law may or may not agree but it is the license that matters because it confers greater rights than copyright law alone. Again, IANAL, so take this with a big grain of salt.

But, then, this is a change to the GPL, and the license on the use of the text of the GPL (overriding the copyright on the text of the

Re:This is worth noting re. GPL

[valshaq]

Well, the problem that I see is:

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 happy they aren't legal :-)

Linus' note:

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".

This doesn't include modules as they are using special system calls, but only user programs. Kernel modules are NOT user programs, they don't even live in user space.

(About my first citation: I answered to the comment in which the lwn.net article was posted and cited only those parts that seemed to clarify the misleading interpretation of that comment.)

Fact: Linux is dying

[Anonymous Coward]

Fact: Linux is dying

It is official; Slashdot confirms: Linux is dying. One more crippling bombshell hit the already beleaguered Linux community when IDC confirmed that Linux market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Slashdot survey which plainly states that Linux has lost more market share, this news serves to reinforce what we've known all along. Linux is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin to predict Linux's future. The hand writing is on the wall: Linux faces a bleak future. In fact there won't be any future at all for Linux because Linux is dying. Things are looking very bad for Linux. As many of us are already aware, Linux continues to lose market share. Red ink flows like a river of blood.

Red Hat is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time Red Hat developers Linus Torvalds and Alan Cox only serve to underscore the point more clearly. There can no longer be any doubt: Red Hat is dying.

Let's keep to the facts and look at the numbers.

Debian leader Ian Murdock states that there are 7000 users of Debian. How many users of Mandrake are there? Let's see. The number of Debian versus Mandrake posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 Mandrake users. Slackware posts on Usenet are about half of the volume of Mandrake posts. Therefore there are about 700 users of Slackware. A recent article put Red Hat at about 80 percent of the Linux market. Therefore there are (7000+1400+700)*4 = 36400 Red Hat users. This is consistent with the number of Red Hat Usenet posts.

Due to the troubles of SCO, abysmal sales and so on, Red Hat went out of business and was taken over by IBM who sell another troubled OS. Now IBM is also dead, its corpse turned over to yet another charnel house.

All major surveys show that Linux has steadily declined in market share. Linux is very sick and its long term survival prospects are very dim. If Linux is to survive at all it will be among OS dilettante dabblers. Linux continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Linux is dead.

Fact: Linux is dying

requirement?

[SHEENmaster]

I'll be distributing a program for many platforms, and a feature of the program's disc is that it can boot Linux to run the app.

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?

[Anonymous Coward]

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. ]

Re:requirement?

[fizbin]

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)

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 .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.

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.

UR GHEY K? FCK U K? THX BYE

[Anonymous Coward]

ASDF