On Wed, 21 May 2008 16:20:39 -0300 Alexandre Oliva <aoliva(a)redhat.com&gt; wrote: All spins must be composed of packages that are contained within the Fedora repositories. kernel-libre does not fit that category (today). We've had this discussion. We aren't going to allow a forked kernel package. Please work with the kernel team to integrate this into the main kernel package. You don't need a package. Make a comps group. I think we can certainly discuss it. However I believe the biggest hurdle to what you propose is the extra kernel-libre package. Your overall proposal hinges on that, and the way you've stated you would like to provide it has been frowned upon quite a bit. josh

On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: Really, that's a stupid objection. Just post it in ed form. Kernel-libre is a very bad plan; just help move the firmware which offends you out of the kernel instead. -- dwmw2

On May 21, 2008, David Woodhouse <dwmw2(a)infradead.org&gt; wrote: Assuming that's acceptable upstream. I sort of doubt it, but then, I could send xdeltas as well, and if you've been part of the discussion, then you probably know that that's not the only reason why I can't take part in this plan. Another I still haven't mentioned is that I have no interest in being harrassed and verbally abused like the last discussion about freedom issues I got into there. Now, let me show you why this proposed plan is an impossible mission that people are trying to drive me into. Consider this snippet from http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25 # SND_KORG1212 - Korg 1212 IO clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL clean_blob sound/pci/korg1212/korg1212-firmware.h # SND_MAESTRO3 - ESS Allegro/Maestro3 clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL # SND_YMFPCI - Yamaha YMF724/740/744/754 clean_blob sound/pci/ymfpci/ymfpci_image.h clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL clean_blob() removes long sequences of numbers, whereas clean_ifdef() runs unifdef on the named file assuming the named variable is undefined. Could you honestly tell me, with a straight face and a reasonable degree of assurance, that a patch that performs these actions stands any chance whatsoever of being accepted upstream? The firmwares are already optional to compile in, they can already be loaded with the standard firmware loading machinery. But while they're there, in the source code, distributing the kernel sources amounts to distributing this non-Free Software, and distributing binaries built out of these sources, even with these options disabled, amounts to distributing the this non-Free Software as part of the kernel sources or committing to distributing it over the next 3 years. One way or another, it amounts to propagating the problem. If you tell me with a straight face that something like this stands a chance of being accepted, I will give that a try. Otherwise, please stop sending me in a mission that can't possibly be accomplished in a way that achieves our shared goals of providing users with freedom, with an operating system built out of only Free Software. If Fedora cares about users' freedom, why would it follow and abide by policies and dubious legal theories set by someone who doesn't and is proud of it? Does anyone think the issue about non-Free firmwares is any different from the issue of non-Free drivers for nvidia cards, except for the irrelevant detail that these different pieces of software can corrupt the system (technically and morally) running on different CPUs? Seriously? Why do we bend over to keep compatibility and even distribute binary-only code published by with vendors who have taken dubious measures such as releasing code under the GPL without sources, or explicitly contributing, to the kernel Linux, code under licenses incompatible with its license, when an alternative is readily available and looking forward to being included and with an active maintainer that has already proved to be able to keep up even with daily rawhide builds, and at the same time we proudly defend the decision to ship X drivers that disregard (for good reasons) compatibility with non-Free code? What is it that appears to make these issues different? Is nVidia any less supportive to our community than any of the other vendors who push hardware and then push non-Free Software to enable their customers to use the hardware at full power? Aren't we forgetting something, or drawing a line at a point that is absolutely arbitrary (which might be fine) and not in sync with our mission (with is certainly not fine)? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 21, 2008, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote: I'm sorry to be the bearer of bad news, but you did indeed miss something. Have a look at the license for drivers/net/tokenring/3c359_microcode.h 2 /* 3 * The firmware this driver downloads into the tokenring card is a 4 * separate program and is not GPL'd source code, even though the Linux 5 * side driver and the routine that loads this data into the card are. 6 * 7 * This firmware is licensed to you strictly for use in conjunction 8 * with the use of 3Com 3C359 TokenRing adapters. There is no 9 * waranty expressed or implied about its fitness for any purpose. 10 */ This is just one out of some 30 examples of such licenses in the kernel. And, heck, this one doesn't even grant permission for redistribution. What are those Linux-no-libre guys thinking? Anyhow... How does this relate with my question quoted above? nVidia's video drivers are non-Free. firmware included in the kernel, as well as the other redistributable firmware included separately in Fedora, are non-Free. The hair-splitters that try to invent an artificial difference based on what CPU the code runs on don't only miss the point on supporting unethical vendors, but also on their very amoral technical grounds for introducing the artificial distinction: they're supposed to run on *some* CPU on *some* users' machines, and since we don't know what they're doing and they run in privileged mode (on whatever CPU they run), they're at least in theory perfectly capable of wreaking havoc on the entire system, and in fact some of them do. So why the exception again? Because users can't live without them? Well, sure some users can't. Nobody stops such users from being informed by Fedora about the problems in their hardware and how to get ahold of the hardware vendor to obtain some software (presumably non-Free) that will get the hardware going. Fedora doesn't need to carry such software, and Fedora doesn't need to promote or encourage its use. I'm well aware of that exception. Nowhere does it say "we must force binary firmware onto every Fedora user's machine, and we must avoid at all costs any attempts to enable users to prevent the installation of such binary firwmare on their machines" :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 22, 2008, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote: Indeed, it doesn't. I don't think there are very many of these firmwares that are licensed in such obnoxious terms. But it's certainly not the only example of this kind of problem. The nouveau-drm patches that we're adding ourselves contain relatively large chunks of "voodoo" [sic] code copied from non-Free drivers by means of mmio dumps, but no copyright notices or licensing associated specifically to those pieces of code. As much as I appreciate what these folks are doing, I'm not sure this approach is ethical, let alone legal. I don't know whether this has been run through legal, but if it hasn't, I suggest that it be. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On Thu, 2008-05-22 at 12:47 -0400, Alan Cox wrote: Being a separate work doesn't save it from the requirements of the GPL. The GPL clearly states that under some circumstances it _does_ extend to sections which are independent and separate works in themselves. And it seems fairly clear to me that those circumstances include the firmware blobs included in the Linux kernel tarball. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. (OK, that's the firmware). But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. (as is that). -- dwmw2

On Thu, May 22, 2008 at 06:48:14PM +0100, David Woodhouse wrote: No it isn't. See "mere aggregation" -- Take control of enterprise infrastructure Sign up for starfleet academy today

On May 23, 2008, David Woodhouse <dwmw2(a)infradead.org&gt; wrote: Besides, in order to claim it's mere aggregation, you have to be able to point at the separate works and say "see, I aggregated this work, that is under the GPLv2, with these other works, that are under various other licenses". Now, where can I get this original work that is under the GPL, that was aggregated with other works? It's just the sort of thing I've looking for, couldn't find, and ended up creating linux-libre for. But I can't find it anywhere. I claim this separate independent work has never existed. +1 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 23, 2008, Alan Cox <alan(a)redhat.com&gt; wrote: Although I'm pretty sure they'd have a hard time making this case once they saw something like this: http://lkml.org/lkml/2007/9/18/277 Their opinions may very well be more informed, but until a court decides on the matter, they're just as right or wrong as ours. It's not too hard to find a lawyer that will tell you what you want to hear. It's like going to doctors until you find one that says you're not going to die soon, and then become convinced this one is right and all the others were wrong in their diagnostic :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On Thu, May 22, 2008 at 11:36:38PM -0300, Alexandre Oliva wrote: Well that mostly depends if the people doing the work are prepared to be rational about it and submit request_firmware() based support, test it and identify the additional files needed. So far all we've had from the "Free software extremist" side has been - stupid patches to just remove stuff - insults - long political arguments on a technical list - people saying "we" (being some undefined 'kernel community' with whom they apparently think they have a service contract) should fix it. Alan

On May 22, 2008, David Woodhouse <dwmw2(a)infradead.org&gt; wrote: Thanks, I'll probably take up the offer. Can't really help that, there's a fundamental cultural clash. That's why your offer to be the man in the middle is so invaluable. But I am :-) :-) Seriously, not really; I don't intend to deprive users of the ability to get their stuff to work, but I also have limited resources to put into personal projects, so it's hard to do more than the absolutely minimum necessary to achieve the goal I had in mind. Even more so because I foresee a lot of resistance, that ultimately makes me expect it to be a pointless exercise. But it's yet another of those win-win situations, in which if I try it and succeed, excellent; if I don't, I can at least come back and say "see?, I told you" :-) It seems like a reasonable idea and a useful feature (although I don't quite see that as a major improvement over loading this stuff out of initrd), but I honestly don't see that upstream will want to sacrifice the convenience of having the firmware right there as part of their buildable tarball just because such a feature is in place. They don't exactly care about helping us achieve a 100% Free source tarball, you know :-) I guess we'll have to try and see. Maybe we should start with the non-redistributable piece of firmware I mentioned. This is the part I don't see happening. And if it doesn't happen, then all of this will have been just running around in circles as far as my goals are concerned. As long as they're part of the kernel source tarball, the distribution of any spins allegedly Free still involve the distribution of this non-Free Software. So achieving anything less than a blob-free kernel source tarball is no progress. Now, do you understand what I'd need to achieve in order to accomplish the goal I set out to accomplish, and do you still believe there's even a slight chance of that coming about upstream? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On Thu, May 22, 2008 at 10:36 AM, Dave Jones <davej(a)redhat.com&gt; wrote: You sir, have brightened my day. If you weren't several thousand miles away, I'd probably track you down and give you a hug. But since I am several thousand miles away. I'll have to delegate that task to someone else. Someone hug Dave for me! -jef

On Thu, 2008-05-22 at 14:36 -0400, Dave Jones wrote: Yeah, but that's just the start. We'd need to convert other drivers to use the firwmare loader too instead of having their own private blobs. And while we're doing that we _are_ going to get people complaining that we force them to use an initrd where they didn't need to before. Hence the suggestion to make the firmware loader capable of having a built-in set of blobs. -- dwmw2

On Fri, 2008-05-23 at 14:19 -0300, Alexandre Oliva wrote: First we get to a point where the blobs exist separately in the kernel and _can_ be easily removed. The korg1212 sound driver patch was just the first of many, and someone will need to finish the job. When that's done, we can have a sensible discussion upstream about moving them to a separate tarball. And as I said -- even if upstream baulks at that last step, I'd support Fedora doing it on our own. -- dwmw2

Alexandre Oliva wrote: For your purpose, wouldn't you want to separate source-available-firmware and documentation-available bit settings from the parts that would be more difficult for you to modify freely? -- Les Mikesell lesmikesell(a)gmail.com

On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote: I considered it, but I figured it was better to do things one step at a a time. I was probably wrong though; I'll take another look. -- dwmw2

David Woodhouse wrote: (Having not read the follow-ups on the list yet...) This is the right track, but if anybody goes down this route, please, please organize it this way: 1) make the firwmare class support caching of firmware images (which also means supporting manual expiry of them at runtime...) 2) give the firmware class an interface to "push" an image which has not been requested. That is, preloading the cache. 3) make an initcall that runs before almost all of drivers/ which loads all built-in firmware images. This solves the "built-in modules using request_firmware don't work" problem, but still allows us to e.g. update built-in firmware images at runtime to support debugging builds, new features, blatantly violating the "can not modify" license sections in the comfort of our own homes, etc. -- Peter

On May 21, 2008, Josh Boyer <jwboyer(a)gmail.com&gt; wrote: I have never opposed the idea of replacing the non-Free kernel Fedora ships today with linux-libre or any of its predecessors. I just thought proposing it as an alternative that I offered to maintain myself would generate less heat. Maybe I was mistaken. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 21, 2008, Josh Boyer <jwboyer(a)gmail.com&gt; wrote: It's been tried before. I gather upstream is not interested in achieving a 100% Free Software kernel tarball. It's in conflict with our stated mission. Where do we go from that point, when upstream is not cooperative and there is a drop-in alternative. This is a very unfair assumption. I just have had access to facts that you apparently didn't. Either that or you're being intentionally obnoxious in sending me down this wild goose chase. Finding someone else to do it might enable more patches to be posted, but it wouldn't make it possible to achieve the goal. Still no use, unless the spin comes with its own separate repository, never contaminated by non-Free Software. At which point users might as well switch to BLAG. Err... The only person I know who has volunteered to maintain this package disagrees with this assessment, especially because the ks file does not even begin to address the longer-term goal of enabling a user to avoid the installation of non-Free Software on his system (install time and updates over time), rather than a short-term goal of avoiding the inclusion of non-Free Software in one particular spin. Like, a number of people vehemently objected to the idea of replacing the current kernel with linux-libre. I hadn't proposed anything even close to it. That's a large misunderstanding to me. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 21, 2008, Josh Boyer <jwboyer(a)gmail.com&gt; wrote: Thank you. I haven't. I'm told others have, and have been ridiculed. From what I gather from the LKML archives and personal experiences there, I have no reason to disbelieve them. Because upstream doesn't want to achieve this goal, and actively refuses to accept changes essential to get there. Not all of them, no. No. I'm suggesting that a fedora-freedom package that conflicts with the non-Free packages in the main repository would be a simpler way to enable users to choose not to let non-Free Software sneak into their computers. Yup, except for the 'constantly'. Fortunately, there's not so much non-Free stuff in Fedora. Yes, it is error-prone, and I'm all ears to listen to to better suggestions on how to accomplish this. Ruling out all non-Free Software from Fedora would certainly make this much simpler, but I'm not going to count on that just yet ;-) So much for http://www.linux-books.us/fedora_core_0001.php Fedora Core is a complete desktop and server operating system created entirely with open source software. I'm pretty sure in the good old days something along these lines used to be on Fedora's front page, and that Fedora's mission statement didn't weasel out of it. But I still see people advertising today that 'freedom is a feature'. Unfortunately, it feels like it's buggy in several ways, and the bugs reported in this regard get responses along the lines of CLOSED/UPSTREAM and CLOSED/WONTFIX :-( And 'infinite freedom' is like a bad joke :-( Oh well... -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 22, 2008, Josh Boyer <jwboyer(a)gmail.com&gt; wrote: As in, what's in the archives, including my personal experiences on LKML, are hearsay? I don't think so. I don't have any such pointers handy, save for the related discussions that you'll find with a web search for "LKML remove firmware or blob". Sorry. I was so much in a mindset of "there's no way upstream is going to accept this" that I focused only on the second half of your question, completely missing the antecedent that conflicted with my mindset and that would have made the answer 'yes'. So, I take back the above. Given the antecedent, the answer would be 'yes'. I just don't see that happening. I guess it may be worth a shot, though. I thought the acceptance of all patches upstream was entirely hopeless. However, DWMW2's suggestion today might work, although I still don't quite understand its details. I wasn't trying to avoid your point. My response was an allusion to what I perceive as an inconsistency between Fedora's long-ago stated goal (build an entire operating system out of free and open source software) and the preference for following an upstream that (through their actions) oppose this goal, rather than giving precedence to the stated goal and switching to another upstream that is compatible with the goal. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

On May 27, 2008, Peter Jones <pjones(a)redhat.com&gt; wrote: I realize there may be work in anaconda that's not as simple as the approach recently taken by BLAG (a kernel package that's empty, and only Requires: kernel-libre), but do you have anything else in mind? Maybe configuring yum to retain a sufficient number of kernel-libre packages installed and avoid removing the running version from under itself? grepping for PAE, debug, xen et al should make these quite easy to locate this and any others, and extend them to kernel-libre. Once it's done, I guess it's even more negligible than the effort I currently put into Linux-libre. No biggie. http://www.blog.tdobson.net/node/172 may be quite enlightening for the FUD-slingers who oppose this kind of move. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

Le Jeu 22 mai 2008 10:24, Thorsten Leemhuis a écrit : It would be mightily useful to have regular pre-built vanilla and linux-next fedora rpms available in a well-known repo. Often one reports kernel bugs, and then upstream asks vanilla/linux-next re-tests when you do not have a few free hours to invest in a custom kernel rebuild (yes it can be a few hours when you have to figure what changed in kernel build procedures upstream and what changed in the fedora kernel spec during the same period) -- Nicolas Mailhot

On Wed, 2008-05-21 at 16:20 -0300, Alexandre Oliva wrote: I've gone ahead and add the kernel-libre topic to the schedule for tomorrow. I've put it at the end of the agenda though, since I want to make sure we get to the other items on the schedule before we begin this discussion (since I'm guessing it will be fairly lengthy). Later, /B -- Brian Pepple <bpepple(a)fedoraproject.org&gt; http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E

Alexandre Oliva wrote: You might want to attend the IRC meeting and participate in the discussions regarding this proposal. Also try and pro actively address the objections raised and answer them within the wiki page. Not everyone in FESCo might have read the lengthy thread on the topic. IIRC, the primary and perhaps only real objection is that you are proposing to maintain a additional kernel package. Instead David Woodhouse, Alan Cox and others have offered to act as a gateway between you and upstream Linux community and remove the firmware out of the kernel in a way that satisfies the requirement of both the parties instead of maintaining a separate branch within Fedora. Rahul

On Thu, 2008-05-22 at 16:27 +0200, Christian Iseli wrote: I assume Alex won't be including an interpreter for closed-source ACPI bytecode in his kernel. So it's likely to have problems on a lot of i386 and x86_64 machines. Should be OK on PPC though :) -- dwmw2

On Thu, 2008-05-22 at 07:53 -0800, Jeff Spaleta wrote: http://lkml.org/lkml/2008/5/23/170 -- dwmw2

On May 22, 2008, David Woodhouse <dwmw2(a)infradead.org&gt; wrote: Is this an intentional strawman, or do you really not get the point? Why wouldn't I? There's nothing offensive or immoral about the interpreter, AFAIK. What is offensive and immoral is the imposition of restrictions on the bytecode that enables one's machine to work. But the interpreter itself can't tell whether it's offensive or immoral, since it doesn't have brains to understand technical and legal restrictions that the bytecode itself or its corresponding source code might be subject to. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}

Alexandre Oliva wrote: Here's a (possibly bad) idea to think about. Write a yum plugin that refuses to install packages that have licensing policies you object to. That sounds much easier to deal with than trying to keep your virtual package up to date with new packages continually being added to the repository. -- David Smith dsmith(a)redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)

On May 22, 2008, Casey Dahlin <cjdahlin(a)ncsu.edu&gt; wrote: This is not about the license. The kernel claims to be under GPLv2, even though, per our licensing policies and guidelines, it should be 'redistributable', or not even that. A license doesn't ensure your freedom. A copyright license mere states some permissions that, per copyright law, you might require in order to do certain things that, in the absence of these permissions, would be substantial limitations to your freedom. But lack of permissions in a license isn't the only way software can become non-Free. Consider software under the modified BSD license, for example. Some of it is present in Microsoft Windows, and it's still under that BSD license. If you look at all the fine-print, you'll eventually find the UCB copyright notice and a copy of the license. But does that make that piece of software Free Software, just because it's licensed under a Free Software license? Obfuscated code pretending to be source may also be under various Free Software licenses, but still deny users the freedom to study the source code and adapt the software to their needs, because the obfuscated source code is incomprehensible and not amenable to modification. The licence a package is under isn't everything. Please don't conflate these two related but significantly different topics into one. And then, if you exclude nonfree from the repo, no such package would be installed. Yes, this can work beautifully. The catches I can think of here is that this proposal depends on the maintainer of the package containing non-Free Software to introduce the dependency, and, if the non-Free Software is found out after a build, someone might still get the impression that that particular build does not contain non-Free Software, while it's widely known that it does, and someone who rejects nonfree might end up keeping the non-Free package installed because an update says it would introduce non-Free Software. A fedora-freedom package is superior IMHO because (i) it can be updated so as to mark existing packages as containing non-Free Software, (ii) it makes the choice positive, (iii) it is easier to connect it to a feature, (iv) it enables finer-grained control of what you don't want on your system. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}