I would like for the minimal LiveCD to support my Atheros based WiFi card using madwifi-ng. I could use another installation medium (such as Ubuntu or Knoppix) but I rather use the Gentoo LiveCD if possible. Is there currently any rationale for not including madwifi-ng on the LiveCD? Until there is a LiveCD that supports madwifi-ng what would be the steps to create a custom minimal LiveCD with madwifi-ng on it so it works just like the current LiveCD (i.e. card gets autodetected). For reference here's the lspci info on my card: 0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
We release 2 times a year... madwifi* wasn't stable at last release, and the maintainers say that it isn't "stable enough" this release. Because of this, it isn't on the 2006.1 CD, either. We're aiming for 2007.0 for this one. If you're impatient, you're more than welcome to create your own CD with the driver before then.
I guessed that the quality of the driver might be the reason why it isn't included. However, does including it break something else? If not I would prefer something that works for most people that something that is guaranteed to not work (i.e. no driver). However if you feel waiting is the right thing then please do so. However, it would be nice if someone comfortable with building LiveCD:s could write a short note on how to add additional drivers. I've found nothing of the sort as of yet. Intuitively I would guess the steps would be something like: 1. Extract all the files from the ISO. 2. Extract all files from the squashfs file. 3. Chroot and run emerge madwifi. 4. Add to modules-autoload. 5. Pack everything together again and create an ISO. However chrooting and emerging doesn't work for me (because the minimal LiveCD doesn't include emerge & co?).
#1. Grab catalyst specs from CVS #2. Grab stage3 tarball used for the release #3. build livecd-stage1 w/ catalyst #4. add madwifi-ng to livecd-stage2's spec file #5. build livecd-stage2 w/ catalyst As for why we don't include known broken items, we don't want the bug reports from people when it doesn't work. If the maintainer says no, we listen to him, no matter how many people ask.
Not to get all political or anything, but since ath_hal is a proprietary blob you can't distribute it on a livecd along with the kernel or you'll be violating the GPL (it's the same deal as Kororaa and the Nvidia/Ati drivers). There is a port of the Open BSD driver but it's probably not incredibly stable : http://madwifi.org/wiki/OpenHAL Suggest closing this one as CANTFIX.
Nope. I'm working on (low priority) a system to build things like this on-demand. It isn't something I'm actively working on for 2007.0, but we'll have it at some point.
*** Bug 194051 has been marked as a duplicate of this bug. ***
Well, madwifi-ng is finally stable in the tree for x86, amd64, and ppc. Is there or is there not an issue with redistributing the binary blob?
Yes there is. You can rig up some system to let the user download it on demand, but how are they going to do that without an internet connection? You can't ship the blob and the kernel together; packing up the blob in some archive and unpacking it on demand won't change that. The solution is openhal. It doesn't work with all of the Atheros chipsets yet, but apparently works ok on the ones it does support.
(In reply to comment #8) > Yes there is. You can rig up some system to let the user download it on demand, > but how are they going to do that without an internet connection? You can't > ship the blob and the kernel together; packing up the blob in some archive and > unpacking it on demand won't change that. Wrong. If we meet the license requirements for redistribution of the binary blob, we can do so, kernel be damned. What we cannot do it ship a pre-compiled module. We can, however, ship distfiles and have the compilation done on-demand. This really needs to be done, not only for this driver, but also for others. I simply haven't had the time to get everything done that is needed for this.
Well, we are not lawyers. My opinion is that shipping the kernel and blob (there's no publically available source, so you can't compile it on demand) together creates a derivative work, since clearly they are meant to be used together. Your opinion is that it doesn't. Other people will have different opinions. None of them really matter, though asking the copyright holders what they think via the kernel mailing would be a polite and legally expedient thing to do. I would also point out that, to my knowledge, no other major distribution ships the kernel and closed source modules (with headers prebuilt or otherwise) on the install CD.
Not being lawyers has nothing to do with it. The GPL license only applies to derivative works that actually are derivative. Upstream's source tarball is not a derivative work of the kernel. If it was, it would be required to be shipped under the GPL. Obviously, the copyright holder on the binary blob don't think it is a derivative work, so neither will I, until that status is changed in court or we're asked to remove the pieces in question by either the upstream copyright holder or a copyright holder on the kernel. Also, I don't care what any other distribution is doing. Other distributions are not Gentoo. They are binary-based and don't build from source. They also haven't brought up a compile-on-demand system to work around this issue. If we are not making modifications to the sources/binaries as shipped on sourceforge by the upstream authors, then we are not violating their license.
Actually, some people believe that binary drivers are derivative works. But leaving that argument aside, this hypothetical module build system would be nothing more than a glorified modprobe. The underlying data representation is irrelevant, it is the act of shipping kernel and module together which forms a derivative work; even if the module source were available, it is not GPL, and hence couldn't be legally combined with the kernel. The shipping of a binary blob without the kernel is a completely different issue, and obviously Atheros believe this to be ok, as you point out. The shipping of the individual packages is also obviously a completely different situation (GPL clause 2, "mere aggregation", would cover that, but I would argue it doesn't cover a situation where you clearly intend the software to be used together). Given that this is such an obvious way to get around the GPL license of the kernel, and that there's end user demand for binary drivers on live CDs, it speaks volumes that no other distribution has done this. It's a legal gray area, and thus quite normal for people to have different opinions. Feel free to go ahead with it, but don't be too surprised if, like the Kororaa guys, you receive a cease and desist notice from one of the thousands of people who own copyright on some small part of the kernel.
(In reply to comment #12) > Actually, some people believe that binary drivers are derivative works. But > leaving that argument aside, this hypothetical module build system would be > nothing more than a glorified modprobe. The underlying data representation is > irrelevant, it is the act of shipping kernel and module together which forms a > derivative work; even if the module source were available, it is not GPL, and > hence couldn't be legally combined with the kernel. The shipping of a binary > blob without the kernel is a completely different issue, and obviously Atheros > believe this to be ok, as you point out. The shipping of the individual > packages is also obviously a completely different situation (GPL clause 2, > "mere aggregation", would cover that, but I would argue it doesn't cover a > situation where you clearly intend the software to be used together). I honestly don't care if anyone thinks that shipping the sources for a kernel module, as a tarball, *exactly* as shipped by the upstream, along with a compiled kernel is a GPL violation. I just don't buy it. My opinion is that people that believe that are people who have a personal motive to get open source drivers into the kernel and will do anything in their power, correct or not, to pressure others into doing their bidding. Well, I don't bend to pressure very well. > Given that this is such an obvious way to get around the GPL license of the > kernel, and that there's end user demand for binary drivers on live CDs, it > speaks volumes that no other distribution has done this. Yeah, those Ubuntu guys sure are crazy, aren't they? There's a few others that already do this, including Sabayon. The only problem we have is that Sabyon's system won't work for us due to the lack of disk space on the CD, as they use a DVD, exclusively. > It's a legal gray area, and thus quite normal for people to have different > opinions. Feel free to go ahead with it, but don't be too surprised if, like > the Kororaa guys, you receive a cease and desist notice from one of the > thousands of people who own copyright on some small part of the kernel. Well, I participated in the Kororaa debate with Chris (the Kororaa lead). The main reason he dropped the binary drivers was *not* a belief that the guy was right, but because he felt morally objectionable to using any possible loop holes in the GPL. Also, he never received a cease and desist. A cease and desist is a formal letter written and delivered by a lawyer. Chris got an email, which doesn't have a legal leg to stand on. Remember, as a trustee, this has been my playground for a year now. I've been researching this sort of thing for even longer, since we, too, used to ship the NVIDIA drivers on our media. >
*** Bug 207971 has been marked as a duplicate of this bug. ***
*** Bug 208682 has been marked as a duplicate of this bug. ***
Any reason this is still needed or can we just rely on ath5k?
ath5k is a moving target, so it works most of time, but sometimes it broke. That said all cards should be supported by ath5k driver at the moment (some features are absent, but... driver should work), so I think it's good idea to close this bug as wontfix until somebody provides better explanations why we need madwifi-ng now.
(In reply to comment #17) > ath5k is a moving target, so it works most of time, but sometimes it broke. > That said all cards should be supported by ath5k driver at the moment (some > features are absent, but... driver should work), so I think it's good idea to > close this bug as wontfix until somebody provides better explanations why we > need madwifi-ng now. Done.
