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.
Who is actually going to care? Will any of you buy this product now, and hack around with the source?
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!
Everybody's a libertarian 'till their neighbour's becomes a crack house.
sorry to say, but any company that abuses the gpl isn't getting my hard-earned dollar, even if they are forced to cough up the code at some later point. i see what you're saying about the realteck, but i don't think that can justify buying one of these things from such a shady company
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.
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.
...is not going to promote widespread corporate adoption - rather, it will push them towards proprietary solutions.
Quite frankly, so what!? If I release software I have written under the GPL, then I expect the terms of that licence to be met. If some corporation wants to take something I, or others, have put their blood sweat and tears into without giving anything back, then tough. If they don't like being required to give back, then they can find some other solution to their problem. If they can't find another solution, then they must play by the rules. They have NO legal or moral right to use someone elses property in a way other than that person allows.
I would like to see the widespread acceptance of Linux, but I am not willing to see that happen at the expense of what Linux and the GPL stand for. If people go soft on enforcing the GPL now, then its perceived validity will be eroded in the future, and we'll have more problems than we started with. If this slows down widespread acceptance, then so be it. If widespread acceptance never materialises because corporations don't like the philosophy of the GPL, then so be it.
There is no reason to be scared of the GPL. If a company tries to abuse it, then they should expect to come under fire. If a company plays fair and release what they should, they can still keep closed whatever else they desire. They simply don't have the right to use people's work in a way that is illegal.
---
Any man who can drive safely while kissing a pretty girl is simply not giving the kiss the attention it deserves. -- AE
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:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Yah, but the problem is that under copyright law, they're not allowed to make that restriction in this case - I can resell a book without having permission to copy it at all. The GPL says "You don't have permission to copy it without including the source", but first sale says you don't need any permission. That's the point - Someone could say to company Y "You don't have the right to distribute this GPLed software without source!" and company Y's response would be "I'm not distributing it. I'm selling it."
It is an interesting loophole, and it is a loophole. The easy way to see this is just consider that copyright gives you no rights to copy and distribute a copyrighted work you bought without a license. But first sale doctrine does allow you to sell something you bought.
Since these linux drivers are responsible for so much revenue to these big companies, they would much rather gobble you up for a couple dozen million (chump change really), than deal with the publicity of a lawsuit.
Of course you need to have a backup plan incase they don't bite. You need to protect your "IP" so you issue press releases like you were the AP, telling anyone and everyone that you are suing these evil corporations, and you have expensive lawyers. Sell your stock like mad, when dumb people buy your story..
If they ask "what IP do you have?" Loudly shout "errr, umm, Look at that monkey over there!", and make sure that by the time they turn back around, your expensive lawyer is there with lawsuit in hand..
I don't need an MBA or a Law Degree, everything I need to know i learned from Slashdot and the litigious bastards.
What are we going to do tonight Brain?
Okay, I get to play 'Devil's Advocate' here for Mr. McVoy. That's okay, I'm not too shabby at it :)
First of all, *read* the entire (linked) thread. It doesn't have to do with this case specifically, just these issues generally. I just picked some juicy pieces.
If you read Linus' *entire* post (which I didn't quote) you'll see that he makes no distinction between "modifying the kernel" and not. His distinction in the thread is, as I quoted, that "derived" works are those which show some knowledge of kernel internals *or* interfaces which are specific to Linux, regardless of whether they are *in* the kernel or outside of it. Depending upon who you believe (and on what day), the line between "in" the kernel and "out" lies somewhere between statically-linked drivers and end-user programs that utilize kernel function-calls.
The problem is, Linus also says that user-space programs cannot possibly be considered derived, even though some (like the example above) clearly were written with Linux in mind.
Larry is just pointing out that this is somewhat of an inconsistent interpretation.
Now, that's not to say that there is anything *preventing* Linus from taking this interpretation and putting it into action. In fact, as the gp shows, Linus does clearly explain the legal methods he is using to achieve his desired results and the level(s) of protection that they assure to anyone wanting to license Linux for uses such as these. They range anywhere from 'technically, you have no protection if a work can be considered derived' to 'I have said before that X is acceptable so estoppel should prevent me from changing my mind at a later date'.
"I assumed blithely that there were no elves out there in the darkness"
By that logic, an OS without memory protection or preemptive multitasking is not to be blamed for lock ups - applications are.
Maybe device drivers a bit different because some operations can cause a hardware malfunction that will bring down the machine no matter what the OS does. But I bet most crashes are due to more trivial reasons - a driver corrupting kernel memory, waiting forever for a failed operation, taking 100% of CPU time an so on.
There is no excuse why device drivers can not have their own protected memory space, swap to virtual memory, only be able to access mapped memory and I/O ports they are supposed to use, communicate with the kernel through regular system calls and receive queued interrupts by reading from sockets. There is no reason device drivers can not be implemented in Java.
Have real-time concerns or chicken-and-egg problems (disk drivers will have a hard time using virtual memory)? Fine, implement that driver - or just the portion that needs to be real time - in kernel. Just don't tell me my Palm USB driver needs to corrupt kernel memory and crash the system.
I think (in my non-lawyerish way) that Linus is wrong about what a judge will consider a derived work.
For userland programs all of which dynamically use the kernel he has said that he (as the copyright holder) won't find them actionable. (even if some GPL interpreters might disagree). I agree that they are not actionable, but not just because he thinks so. I think that even if he thought they were actionable, any judge would rule against him. Otherwise the entire software industry would have no legal basis, and clearly it does. Dynamic loading or plugins just leaves a library shaped hole in your program. It could be filled by any library that matches the shape of the hole.
For dynamically loadable kernel modules or drivers he thinks they are actionable. For the same reasons as in userland above I think that just because he believes they are actionable, doesn't make it so. I think that no judge will agree with him.
For dynamically loadable kernel modules or drivers that use inline (i.e. copyable) kernel functions he believes they are actionable. I think there is a 50:50 chance that a judge will agree with him. I think there is also a chance that the judge will consider that since the inline functions form a part of the interface, that using them is fair-use, and rule against him.
For statically linked kernel modules he thinks they are actionable. I agree, if the module and kernel are distributed together. If the author just provides the statically linked module as some kind of patch, separate from the kernel, then it is not the module author that has created a derived work, but the user who installs it, and that is fine with the GPL.
I think his assertion that if you are "thinking of linux" when writing your module or driver, it becomes a derived work of his, is somewhat crazy.
But that's just my opinion. Linus has his, and so does everyone here probably. I'm sure that a lawyer would advise differently again. Personally I would love to see a GPL violation go to trial, for each of the cases above. Just to see what would happen. It would be interesting.