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.

Comments

Not exactly "complete"

[mcbridematt]

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 :(

Re:Not exactly "complete"

[Marlor]

The RTl8181 driver for Linux has been a seperate binary driver for some time

What's worse, is that (if the linked forum posts are to believed) the RTl8181 driver is not actually a kernel module. It is linked directly into the kernel, and relies on some modified core kernel files (mm.o kernel.o mm.o fpu_emulator.o).

The source for the modified files, and the driver itself, have not been released. This looks like a violation of the GPL to me, as these files are linked directly into the kernel.

One of the posters in the forum has promised to take this up with the FSF and Realtek, and it would be interesting to see what the results are.

Re:Not exactly "complete"

[benjamindees]

This thread on KernelTrap is the best discussion I have come across so far wrt GPL/binary/static/module issues like the ones in this case.

Here's some snippets:

Kendall Bennett:

I have heard many people reference the fact that the although the Linux
Kernel is under the GNU GPL license, that the code is licensed with an
exception clause that says binary loadable modules do not have to be
under the GPL.

Linus:

Nope. No such exception exists. ...

Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.

Zwane Mwaikambo:

What about software which utilises Linux specific kernel services, such as
say some cd writing software?

Erik Andersen:

An ordinary program that uses normal system calls?

linux/COPYING says: 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".

Larry Mcvoy:

Yeah, and the GPL specificly invalidates that statement. We're on thin
ice here. Linus is making up the rules, which is cool (since I tend to
like his rules) but the reality is that the GPL doesn't allow you to
extend the GPL. It's the GPL or nothing. ...

But given that, neither Linus (nor any of you) get to say "well, that's fine
for userland but drivers are derived works".

I've said this over and over and I'll say it again. If you want the
protection of the law you have to live with the law's rules. You DO
NOT get to say "user programs are a boundary across which the GPL does
not apply but drivers are a boundary across which the GPL does apply".
It doesn't, and can't, work that way. Either userland is GPL and drivers
are GPL or neither are GPLed. Take your pick.

Re:Not exactly "complete"

[Arker]

Interesting that you chose your selections to give McVoy the last word. He's not exactly an authority on the GPL, or even someone with a neutral position on it historically. Linus answered him quite well:

From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 17:58:18 -0800 (PST)

On Thu, 4 Dec 2003, Larry McVoy wrote:
> >
> > linux/COPYING says: 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".
>
> Yeah, and the GPL specificly invalidates that statement. We're on thin
> ice here. Linus is making up the rules, which is cool (since I tend to
> like his rules) but the reality is that the GPL doesn't allow you to
> extend the GPL. It's the GPL or nothing.

Larry, you are wrong.

The license _IS_ the GPL. There's no issue about that. The GPL rules apply
100%.

But a license only covers what it _can_ cover - derived works. The fact
that Linux is under the GPL simply _cannot_matter_ to a user program, if
the author can show that the user program is not a derived work.

And the linux/COPYING addition is not an addition to the license itself
(indeed, it cannot be, since the GPL itself is a copyrighted work, and so
by copyright law you aren't allowed to just take it and change it).

No, the note at the top of the copying file is something totally
different: it's basically a statement to the effect that the copyright
holder recognizes that there are limits to a derived work, and spells out
one such limit that he would never contest in court.

See? It's neither a license nor a contract, but it actually does have
legal meaning: look up the legal meaning of "estoppel" (google "define:"
is qutie good). Trust me, it's got _tons_ of legal precedent.

Linus

Re:I'm curious.

[BlueUnderwear]

Who is actually going to care?

Maybe those of use stuck with a Realtek 8180 card? The model number is close enough to 8181 that there is some chance that the 8181 AP driver would work with the 8180 PCMCIA card, with only minor modifications.

Yes, I know that there already is a binary driver 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!)

Picking your battles

[fuzzy12345]

Don't get me wrong. I think that, under GPL, people are fully entitled to ask for the source for this thing.

But big deal. The source is going to be 99.8% unchanged from the previously public version, and the 0.2% remaining is just going to be bootstrap code and code to work around bugs in the specific hardware, etc. Further, I bet nobody actually does anything interesting with it now that they've got the source. After all, the HW's only good for one thing, and it already does it.

Suing every commodity router builder that comes down the pike with a product like this, which has essentially zero software value added in it, is just going to make some manufacturers squeamish about using Linux inside. And I want them to use Linux, because I, as a consumer, would rather have that than the lower quality, higher cost alternatives that exist.

Looking at it another way, if the OSS community sues over these dinky issues, where they get no great new software to show for it, they'll lose out on luring some big fish to use OSS plus their own super-duper-multimedia-software, which the community could then sue for and actually get something out of it.

P.S. For those that say "but we might get a driver for the buggy chipset that we've only got a buggy closed source driver for now" - will you listen to yourselves? Support another chipset vendor, you twits!

Re:Picking your battles

[putaro]

Manufacturers like RealTek are looking for a free ride. They take the work of other people without compensating them in the way that they ask - in this case to distribute the changes made to their code so that they can learn and modify. If the Linux developers asked for cash in return for using their code would you say they should not worry about it? A deal's a deal. RealTek can BUY an OS if they want to keep their changes proprietary or they could use a differently licensed free OS, like BSD. No one is forcing them to use GPL'd code.

Are you a contributor to the Linux code base? If not, then your wishes as a CONSUMER of other people's work don't really count for a lot.

For USians wanting one...

[MsGeek]

NewEgg's got it.

Link to the product at NewEgg.

Re:Corporations and the GPL

[LordArathres]

You are wrong on that part. So what if the code on your product is GPL'ed? You are still SELLING the HARDWARE, all you are doing is allowing people to modify it at will. This will in fact INCREASE your sales to the computer community as they can now roll out their own custom solutions and not be bogged down by the compiled software.

The GPL is not a new idea, it's principle is based in history. People thoughout the centuries have written down their scientific breakthroughs, finds and other discoveries. They believed that by sharing what they found and developed would help the world. They are still credited with the finds, but now everyone has access to them. Why are computers so different? Because money and companies are involved. Stupid managers and officers all see, Propritary CODE MUST NOT SHARE, when in fact if they made good products, GPL'd the code they would make money.

You see even though you GPL the code does not mean that your competitor can steal it, they too are bound by it and must make their changes public, which in turn helps you. WHOA!!! The GPL is a idea based on the sharing of knowledge for the benefit of the whole world.

Later,

Arathres

Re:I'm curious.

[mcrbids]

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

First Sale Doctrine and GPL

[harlows_monkeys]

These kind of cases are going to get interesting, when the following happens.

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.

Re:First Sale Doctrine and GPL

[toast0]

Your parent is incorrect about point 3. But you're also incorrect. The GPL does not require that you give the source to the public, it requires that either you transmit the source with the object code or you make an offer to give the source to any third party.

But it's hard to take someone up on an offer you haven't received. And company Y is not distributing the object code noncommercially, so they have to either provide their customers with the source code, or provide their own offer. Customers of company Y would not know of the offer of the source from Company X.

Your parent is incorrect with his point 3, because the GPL compels Company X to distribute the source and object codes under the GPL. Thus, Company Y must agree to those terms, and it's bound to include the source code with the object code, or offer the code.

Re:First Sale Doctrine and GPL

[Mike Buddha]

This loophole doesn't exist. If you look at the GPL, it states that a written offer for the source code must exist that offers the entire source to any third party to eligible to receive it, i.e. someone receiving a binary copy of the software.

A ROM is merely a storage place for a binary file. By distributing software on ROM, you aren't exploiting any hole at all in the GPL. The hole is not there.

If you were to buy a piece of hardware with GPL'd software on it from E-bay, you would have to be extended the right to the source from the one who originally modified it.

In your example, Company Y would be off the hook, but Company X would still have to provide the source to those who owned the devices.

Re:I'm curious.

[Monkelectric]

yea but you know that drivers are the primary reason windows is unstable right? if you get conservative, non-flashy hardware, windows is very stable. Win2k is *more* stable under VMWARE then it is on real hardware -- and the reason is the vmware authors are professionals and know how to write drivers. Some chinese kid who makes 8$ a month banging out drivers for generic wifi card #23 isn't producing quality code, and that crashes your computer :)

Thats why Win2k/WinXp/etc like signed drivers. Being signed means they've been throught MS's tests... MS realized they were getting reamed for alot of lockups that weren't their fault.

So whatever linux is doing wrong, its still doing better then MS.

Re:I'm curious.

[idiotnot]

Thing is....

The binary drivers also aren't platform-independent. I'd imagine the 8180 driver only works on 32-bit x86. Now, for the majority of people, this isn't a problem, but what happens when you buy an Athlon64 notebook and want to run a 64-bit kernel, and the driver won't work....stuck in 32-bit land until Realtek graces you with a driver.

I'm in a similar situation, which is why I bring this up. I own a notebook with a broadcom wireless chip. Dell uses these in their notebooks. For PC users, they use the NDIS wrapper and use the windows driver. It has limited functionality, but it does work. I own an iBook, so the windows driver won't work at all for me. Cisco/Linksys use this chip in their wr54g router/ap, which uses arm, I think? They've relesed the source to the AP....everything *except* the source to the driver for the broadcom chip. Broadcom seems steadfast in its refusal to release the specs on the card, so until someone manages to reverse engineer it or something, there won't be any real free driver for it, and certainly not one for non-pc platforms. So much for running Linux or BSD on my iBook.

Re:I'm curious.

[BlueUnderwear]

Actually, many "binary" drivers use a "mixed" approach: some "glue code", available in source form, responsible to be the interface with the rest of the kernel, and the binary driver itself, containing those superseekrit proprietary algorithms that the company doesn't want to reveal. The binary part only interacts with the glue code, never directly with the rest of the kernel.

Well, that's the theory. Unfortunately, despite their best intentions, many drivers get it wrong. They either "forget" to put a certain number of APIs into their glue code, and call those directly from the binary part. Or, all functions are covered, but they access structures directly. Or any other kind of SNAFU. Smacks more of lack of testing or proper development procedures than lack of foresight.

NVidia gets it right (even to the point that their driver works flawlessly with 2.6 kernels. But not with SuSE's X servers, but I'm more inclined to blame SuSE for that...).

VMware gets it mostly right (no problems with any 2.4 kernel, but you need a third-party patch for 2.6 kernels).

Realtek (and, unfortunately many others...) get it wrong, and don't seem to work on anything more recent than 2.4.18.

Re:Picking your [principles]

[Hast]

First of, the main reason to do it is because those are the rules. If a company doesn't want to release their (perhaps) minor additions to the source then they should use a different license. Typically something under BSD. If they can't be bothered to find software with the required license then they'll just have to develop on their own.

They are making money on other peoples generousity, fuck that. They deserve the lawsuits.

Second, when you say that there is no value in firware you are quite clearly not getting the point of OSS. (Besides, I don't know if I'd call an embedded OS firmware.) One of the mayor reasons why we have GPL in the first place is because Stallman got sick of having printers with poor software which he couldn't correct.

Just because you don't have the imagination to change functionality of an accesspoint (perhaps turn it into a wireless information kiosk?) doesn't mean others can't. Just because there is free doesn't mean it's worthless.

For Gods sakes man, one of the main ideas with OSS is that money isn't value.

Damn, I've just been trolled.

The End of Binary Drivers

[ajs318]

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