Linux Sourcecode To Minitar Access Point
mcbridematt writes "Minitar sells a rebadged Edimax Linux based-802.11b Access Point in Australia (no FCC ID yet) for a relatively cheap price (under AUS $100 in places). These access points are based around the Realtek 8181 wireless-system-on-chip design, have 8MB flash rom, and run a 2.4 series Linux kernel. After requests from the community to get the kernel sources, which resulted in a incomplete sourcecode release, we finally have (allegedly) complete and GPL compliant Linux kernel sources for this fine Access Point. Special thanks to chuna, serialmonkey and screwball at Minitar for making this happen, especially after they ran into arguments with their OEM and Realtek over this." From the attached forum discussion, you can see there's disagreement about whether the source code release is as complete as it should be.
Before I kick myself in the arse over my usage of "full" in this story, there ain't any wireless code in there. It appears to be for the purpose of getting Linux to run on the damn thing. (Imagine a Beowulf cluster of these AUS $100 things blah blah..)
:(
The RTl8181 driver for Linux has been a seperate binary driver for some time
Yes, I know that there already is a binary driver [realtek.com.tw] for the 8180, but it is very flaky, and rather picky about the kernels and distributions it agrees to work with... (as binary drivers usually are, alas!)
Which is why I contend that the Linux driver interface sucks.
Assume that I have, on my Red Hat system, kernel 2.4.20-8. Which I parse as 2.4.20 kernel, build #8. So a security update comes out, and I upgrade to 2.4.20-12. (Not an atypical scenario).
Suddenly, my nvidia driver doesn't work, and once that's resolved (with a loss of 3D support, no less) I find also that VMWare won't load properly.
It may be that 3 lines of code were changed, so that
"if (a>20){
b=5;
} "
now reads
"if (a>=20){
b=5;
} "
out of umpteen kazillion lines of code, but dammit, now I have to find precompiled binaries for the exact version and build of the kernel I'm now running.
I think that's just retarded.
Kernel modules should communicate through a documented API, allowing a particular binary driver to work on a series of versions. I think it'd be fair to have a 2.4.x api, and a 2.5.x, 2.6.x, and so on.
But the current way is just stupid and hampers Linux' adoption in the less techie areas.
Of course, since I'm not Linus, nor a programmer of sufficient skill to provide any serious challenge to the powers that be, I generally just swallow my gripes and live with it for the parts that I like. (fantastic reliability, good uptimes, reasonable security, etc.)
I have no problem with your religion until you decide it's reason to deprive others of the truth.
1. Company X makes the guts of one of these routers or access points. They modify GPL'ed software, and put it on ROM in the device.
2. Company X sells these things to OEMs, who put it in boxes, add their applications in a separate ROM, and sell it to customers. Company Y is one of these OEMs.
3. Company X includes the full machine readable source of the GPL'ed ROM with the board they sell to company Y. Note: Company X has completely satisfied their GPL obligation. They are completely off the hook as far as anyone who acquires the software from company Y is concerned.
4. Now it gets interesting. Company Y takes the board with the ROM, and sells it to an end user. Note that company Y is allowed to do this without the permission of the copyright holder, because of the first sale doctine (see footnote).
5. Because company Y didn't do anything other than what is allowed by copyright law, they are under no GPL obligation to provide ROM source to the end user.
6. Note the end result: no one has a GPL obligation to provide source to the end user! Company X satisfied all their GPL obligations in their dealings with company Y, and company Y distributed in a way that falls outside the GPL.
Note: this isn't as big a loophole in GPL as it might seem, since it only applies to things like ROMs, where someone like company Y receives a particular copy, and distributes that particular copy to the end user.
Footnote: the fair use doctine, codified at 17 USC 109 if I recall correctly, basically states that the legal owner of a particular copy of a copyright work can sell that copy, without that violating that copyright owner's exclusive right to distribute or authorize distribution of the work. This is what allows used bookstores, for example. Without the first sale doctrine, every time a book changed hands, it would require the publisher's permission!
This is also what lets you sell a used embedded device on eBay without incuring any GPL obligation if it turns out the device uses GPL'ed code, so I wouldn't say this loophole in GPL is a bad thing. If you just go down to BestBuy and buy a router, you should be able to resell that without worrying about whether or not the manufacturer used any GPL'ed code in the thing.
What we need is a new law that makes it illegal for hardware manufacturers to keep driver details secret. If you want to sell me a fancy wireless adaptor, graphics card, sound card or whatever, fine; but you have to give me all the information I need to write a driver for anything that I might want to interface to it.
It used to be so, back in the days when a printer came with a big thick manual explaining how to do various textual and graphical effects, even pulse timings and voltages for the interface. And everyone thought that information was part of the operating instructions. Sometime between then and now, it went sour; probably we didn't notice, but documentation went from hacker-friendly, to (non-hacker)-friendly, to non-(hacker-friendly). Nowadays, it seems printer manuals just say "plug in the USB cable and install the Windows software" -- and manufacturers are treating the important stuff like how to fire the second "red" nozzle down as though it were some sort of nuclear secret.
Well, it isn't. If you buy a piece of hardware you have every right to make use of that hardware, and if the manufacturer will not tell you how to do so then they are obstructing your enjoyment of your own property. At the very least, the owner of a particular device should -- by sole virtue of ownership -- be automatically privy to any "secret" it may contain; ideally, such information would be in the public domain by law.
And sod the whingeing about "competitors having access to your 'proprietary information'". Your competitors already pay people to reverse-engineer your products, and you will get access to their "proprietary information".
Je fume. Tu fumes. Nous fûmes!