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

6 of 23 comments (clear)

  1. This is worth noting re. GPL by renehollan · · Score: 2, Interesting
    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?

    --
    You could've hired me.
    1. Re:This is worth noting re. GPL by phyxeld · · Score: 2, Interesting
      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?
      --
      __
      Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - Larry Wall
    2. Re:This is worth noting re. GPL by Samrobb · · Score: 2, Informative
      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.

      --
      "Great men are not always wise: neither do the aged understand judgement." Job 32:9
    3. Re:This is worth noting re. GPL by Samrobb · · Score: 2, 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 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.

      --
      "Great men are not always wise: neither do the aged understand judgement." Job 32:9
    4. Re:This is worth noting re. GPL by renehollan · · Score: 3, Informative
      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.

      --
      You could've hired me.
  2. Re:requirement? by fizbin · · Score: 2, Informative

    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.