Raul Miller <[EMAIL PROTECTED]> wrote: > On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote: >> Brian, we are talking about identical code. > > Are we?
In many contexts, yes. >> Software doesn't stop being software if it's burned into a ROM instead >> of being supplied with the OS. > > It does, however, cease to be a dependency issue if those who have the > hardware also have the firmware. In most cases, they do already have the firmware. It's on a CD that came with the hardware. > For practical reasons, we don't require that all users have a piece of > hardware before we distribute software which drives that hardware. > > However, we don't bother including that software in main unless all the > software it depends on is free. If they're not, the software goes in > contrib (or non-free), assuming we distribute it at all. The reason we don't include free software that has non-free dependencies in main is that we want to discourage people from using non-free software. If the user already has non-free code in ROM, then there is the same amount of non-free software being used. > In this context, we ignore bits which are embedded in the hardware, > but we don't ignore bits that we distribute. It's more complicated than that, because in several of these cases we don't have permission to distribute the firmware anyway. Your argument is either: 1) Code can go in main if it's dependent on code that is shipped with the hardware. If it depends on code that we ship instead, it has to go in contrib. 2) Code can go in main if it's dependent on code that is in an eeprom. If it depends on code that is stored on the hard drive instead, it has to go in contrib. In the case of (1), we penalise drivers that use firmware that's under a slightly more liberal (though still non-free) license. This seems wrong. In the case of (2), we penalise drivers for hardware that the vendor has made slightly cheaper and more flexible. This also seems wrong. > It's really that simple. Whichever argument you're using, it leads to the following situation. A vendor releases a piece of hardware. It requires run-time loadable firmware. We put the driver in contrib. A customer comes to the vendor and asks for a version that doesn't require the firmware be loaded from userspace. The vendor adds an eeprom and puts the firmware in that instead. Despite there being the same amount of non-free code, we can now put the driver in main. Does this not strike you as mad? We make a distinction between main and contrib because we want to discourage non-free code. The distinction you're drawing instead merely encourages vendors to put their non-free code on an eeprom. It doesn't advance the cause of free software, and it doesn't help our users. -- Matthew Garrett | [EMAIL PROTECTED]
