just like ati/nvidia, or almost
|
| Author | Content |
|---|---|
| incinerator Aug 30, 2006 12:22 AM EDT |
regarding their GNU/Linux driver strategy, Elo just seems to be another company that doesn't grok how Free Software works. Well, at least they make some sort of source code available, but then again they offer the dreaded binary blobs, as well. And that bad because: 1.) Binary blobs are illegal (if the corresponding source code is not made available) 2.) Binary blobs are impossible to debug in case of problems. 3.) Binary blobs make it very difficult for distribution integrators to support the device out-of-the-box. If Elo would really want to be committed to support GNU/Linux, they should try to get the drivers into the official Linux kernel and let them be maintained by Linus et al. That has many advantages: 1.) The effort to maintain the driver will be spread amongst the kernel maintainers and the Elo driver engineers, reducing each others' workloads. 2.) If there's a problem, an integrated driver is much easier to debug than a binary blob. 3.) Every distribution on the planet will be able to support the device out-of-the-box very easily. Some will never learn, will they? |
| dinotrac Aug 30, 2006 3:02 AM EDT |
Well, two out of three ain't bad. Depending on the implementation, binary blobs are not illegal. They just piss of the FSF, who can't do much of anything about them. They are, however, pretty much impossible for anyone other than the originator to debug and, barring a court ruling, seem to make it hard to support a device out of the box. |
| incinerator Aug 30, 2006 4:54 AM EDT |
Thing is, I've got the suspicion that the source code offered doesn't correspond to what's in these "premium version" binary blobs. Bad strategy if you ask me. Otoh, imho every module specifically written for the Linux kernel, binary blob or not, is a derived work of it (ianal etc.). According to the documentation within the kernel itself , all that is deemed absolutely safe to use by the kernel developers without actually creating a derived work is using the system calls in the public interface only. |
| dinotrac Aug 30, 2006 5:56 AM EDT |
>Otoh, imho every module specifically written for the Linux kernel, binary blob or not, is a derived work of it Under copyright law, a derived work is always the combination of two works: old and new. A module can be a derived work of the kernel only if it actually incorporates part of the kernel. This can be the result of using kernel headers, though it's possible that a court would find specific header files contain insufficient authorship to merit copyright protection. For the sake of argument, let us presume that somebody has carefully crafted a binary blob/GPL'd front end combination so that the blob need not directly incorporate any of the kernel. In that instance, they would require no grant of rights to any GPL'd code. The combination of the kernel and module together, however, does constitute a derived work that merits legal protection. The problem with calling a binary blob illegal, however, comes from a combination of kernel architecture and GPL provisions. The Linux kernel can load modules dynamically. It is possible to distribute the blob in a way so that the final combination of parts is done by the end user. The GPL, however, grants the user freedom to do that and pretty much anything else so long as he does not distribute the result. For that matter, the GPL also permits the developer of the blob to test against the Linux kernel to his heart's content. Without details of the code in the blob, it is impossible to tell whether or not a violation has taken place. One can speculate, one can even make a good guess, but one can not know. |
| incinerator Aug 30, 2006 7:10 AM EDT |
That was well written dinotrac. However, I've got some more points to add. Let me use some analogies, they have their weaknesses but well: 1.) An author of fiction literature writes a book. A wee bit later, another author writes another book with an unrelated plot, but the characters author B. uses are the same as in author A's books. Author B has probably created a derived work of author A's book. 2.) Author A writes another book. This time, author B copies the plot, but changes all the characters (their name, appearances etc.). Lets assume that apart from the characters the book is essentially the same. Author B has probably created a derived work of author A's second book. 3.) Author A writes three more books. All these books (assume it is Fantasy literature for the sake of convenience) have their storyline set in a carefully crafted artificial universe (let's call that middle hell or something like that). Author B writes another book which has its storyline set in middle hell, as well. Apart from that, all the characters and the plot are not copies but an original work from author B. Now, does this book 3 written by author B constitute a derived work of author A's last three books? I would think it does, because it seems that the work has been specifically designed to have its storyline set in middle hell. My point is: not only linking code together that creates a derived work. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation Imho, any driver (be it kernel module or not) that utilises specific internal (=not part of the public API) characteristics of the Linux kernel (and that kernel only) constitutes a derived work of it. In that case it doesn't matter if it is the end user who does the final step of linking the blob together with the kernel or not. The blob is a derived work of the kernel at any time, it doesn't start to be one just at the moment it is loaded into the kernel. A "normal" binary userland application can run on many different kernels, you can even make it run on other operating systems (running GNU/Linux programs on BSD for example) but a driver blob is specifically designed for that kernel. You won't be able to run a driver blob for Linux on a FreeBSD kernel, and I think that's a good criterion in order to determine if that blob is a derived work or not. That's why I would rather say that we don't really need to look into the blob's internals. If the blob is specifically designed to load into the Linux kernel and not the FreeBSD kernel for example, it constitutes a derived work of it. Anyway, the point is somewhat moot. Makeing these drivers Free Software is much more beneficial for the hardware vendors than keeping them non-free. The same goes for proper technical documentation and specification that enable kernel developers to write drivers. I once read some funny stuff about an argument some OpenBSD developers were having with Adaptec in the past. The OpenBSD guys wanted to write a driver for that particular device. In order to do that they asked for technical documenation. Adaptecs declined, their excuse was: "Sorry we don't have such documentation, not even internally". Aha, the so-called market leader in RAID controllers doesn't internally document their own hardware they develop, produce and sell in order to make money. That doesn't speak for their quality at all, does it? |
| dinotrac Aug 30, 2006 7:33 AM EDT |
Case three might or might not be a derived work, depending on the uniqueness of middle hell and how specifically it used middle hell elements. Let's presume, however, that it is a derived work. Please notice how your case three differs from a binary blob. The universe in which it takes place is directly incorporated into the book. If the book said, "Please read Book A so that you'll know where this is taking place," or "Johnny went to a place I can't describe, but you can find out all about it in Book A, chapter 3", Book B would infringe on Book A in any way. To get the full story, a reader would need both Book A and Book B. Essentially, Book A is dynamically linked into Book B instead of being statically linked by Book B's author. As to the benefit of freeing the drivers, I couldn't agree more. The only argument against freeing drivers that has ever made sense to me was the argument HP made when they first began the process of freeing their printer drivers. They used tools that were not themselves free and had either to change the drivers or negotiate a change in terms with the tool providers in order to free them. That I understand. Of course, it's a great warning to be careful about the tools you use! |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!