, Confirmation required
Title: The Secret on How PORN STARS Grew Big DICKS ! The answer is here. Turn off notifications here. . CQ International Exports Ltd St. #1469Belize City, Belize .
Re: LCC and blobs
Måns Rullgård <[EMAIL PROTECTED]> writes: > Josh Triplett <[EMAIL PROTECTED]> writes: > >>> But what if loading the firmware is not required? >> >>> That if the device was >>> "warm-booted" in another OS? (I know there are technical limitations >>> here) Would the driver-firmware relation still be a "depends"? >> >> No, then the driver Depends: firmware | other-os . We don't ship >> either, so the driver still needs to go to contrib. :) And presumably >> other-os depends (though not in the Debian package sense) on the >> firmware as well, so even if that other OS was Free and we shipped it, >> we'd be back to needing the firmware. > > What if every unit of this hardware included a CD with the required > firmware? Then anyone in owning the hardware would also have the > firmware, without Debian needing to touch it. For those not owning > the hardware, the driver is obviously useless anyway. Is the CD in a little sleeve with a "you accept the licence when you break the plastic" sticker, like the IBM printer driver CD in front of me and currently torturing me with its obscure placement of PPD files? It doesn't matter if the manufacturer includes the CD. If I buy the card on eBay, the original owner may not have a license to redistribute the firmware to me. > Yes, I'm deliberately being a little extreme here, but I see no > fundamental difference between requiring the user to possess some data > and requiring the user to possess a physical object. One is software, which Debian could ship, and the other is hardware, which Debian cannot ship. Software has no inherent limitation on its duplication and distribution -- copying bits and shipping them about is essentially free. Duplicating and distributing objects is hard enough to be the basis of our economy. Free software, free data, are inherently different and useful concepts without needing to free all hardware. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
On Sat, Dec 18, 2004 at 01:28:46AM +0100, Måns Rullgård wrote:
> >> I'm convinced enough. Some time ago, I was playing around with an
> >> emulator for Texas Instruments calculators. It obviously required a
> >> ROM image to be useful, and the only legal way of obtaining one was
> >> dumping it from your own calculator (an easy task). I still found
> >> this emulator useful, since I happen to have one of the calculators.
> > By your reasoning, everything in contrib should be moved to main, and
> > contrib should not exist.
>
> That's not what I said, nor what I meant. For instance, a Matlab
> program no doubt depends on Matlab, which is clearly non-free.
Some time ago, I was playing with a program that depended on Matlab.
it obviously required Matlab to be useful, and the only legal way of
obtaining it was to purchase it. I still found the software useful,
since I happened to own a license to Matlab.
Matlab is non-free, just as the BIOS that you're copying off of the
calculator is non-free; both the Matlab program and the emulator go
in contrib, for the same reason.
I might even have an (expensive) calculator that has Matlab in a ROM,
which would make these cases even more parallel.
> OK, then it's about time someone removes libti68k ("Motorola 68000
> emulation library for Texas Instruments calculators") from main. Not
> only does it require a ROM image, it also depends on libticalcs3 and
> libticables3, both of which require an actual calculator, and hence
> the firmware (let's call it firmware, to make the analogy easier to
> see), without which the calculator is useless.
Requiring a calculator for a program designed to manipulate that calculator
is OK, in the same fashion that requiring a 3c905 is OK for a 3c905 ethernet
driver. The difference between software driving a piece of hardware, and an
emulator requiring a non-free BIOS block (that happens to be available on a
piece of hardware) seems clear to me.
While I can understand (even if I disagree with) arguments that they are
the same, the conclusion of that line of reasoning seems to be "merge
contrib entirely back into main", since I can take any non-free library,
stick it in a flash, and say "look, now it's a hardware dependency!".
(I don't have the energy to file a bug against libti68k about this at
the moment, but if what you say is accurate, I suspect it should be
done.)
> Now you'll say the calculator doesn't need the firmware to be loaded
> every time you want to use it, and that would somehow make a
> difference. Suppose now, that TI released a new model, which didn't
> have flash memory, so it would need to be reloaded if the batteries
> were removed, while in all other respects being compatible to the
> previous models. Would this suddenly render all those libraries
> non-free?
No, because (as has been said already) the existance of cases where you need
non-free stuff isn't the issue; the issue is whether there exist cases where
you don't. If nobody can use the software without needing non-free data, the
software is (at best) contrib. If some people can use it without that data,
it can go in main, regardless of the existance of people who can't. The
existance of a free Matlab, or of a free calculator BIOS, would allow the
program using Matlab and the BIOS emulator into main. The reason each is
(or in the emulator case, should be) in contrib is because a free version
of this stuff does not exist, not because non-free versions do exist.
> Suppose some piece of hardware had a Compact Flash reader, and came
> with a Compact Flash card containing firmware necessary for the
> hardware to run. Would this also be non-free?
I believe software that only works with this reader would go in contrib,
if that's what you mean, unless the data on that card was Free itself.
It's a dependency on non-free software. (It's not the same as having
the firmware stored in flash memory on a device, since removable devices
are expected to be removed, overwritten, or lost; where I'd call a device
with a hosed flash "broken". (The former I'd sell on eBay as "drive
only, no packaging, drivers or manuals"; the latter I'd expect to see
sold "AS-IS, UNTESTED".)
However, this is a corner case, and I think the "simpler" cases of simple
on-card flash should be dealt with before banging our heads on the corner
cases.
--
Glenn Maynard
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > I think I'm starting to understand your point of view. So _any_ use of > the software without using non-DFSG data makes it free, right? Any reasonable use. Printing out a "firmware not found" message doesn't count! > But what if loading the firmware is not required? That if the device > was "warm-booted" in another OS? (I know there are technical > limitations here) Would the driver-firmware relation still be a > "depends"? Then there's a dependency on the other OS instead, and *it* either has a dependency on the driver, or is free software and we can just do it the same way they do. So now you have a dependency on non-free software, and several ways to fulfill it. If you could express the entire software dependency tree in free software, then the software at the root of that tree is also free and can go in Debian. > Oh, I have another use for the ipw2100 driver without firmware: it can > recognise the card from the pci-id information. :-) Great, so can lspci. Waste of time and archive space. It's a driver, not a card prober. >> Please at least read Policy on what "Depends" means first. If you > > I see no mention of this in version 3.6.1.1. There is: > |5.6.9. Package interrelationship fields > -> see chapter 7 > |7.2. Binary Dependencies > -> is for debian packages. And has: > |... > |The `Depends' field should be used if the depended-on package is > required |for the depending package to provide a significant amount of > |functionality. > |... > |7.6. Relationships between source and binary packages > ->N/A > > There is no mention of dependency of packages on external data that > fall outside the packaging system. So what meaning do you mean? > > If you extend the rules for packages to firmware then the question > becomes what "significant amount of functionality" is. In the past it > was used for "can run", optional libraries were "Suggest"ed in. Firmware that is optional is, well, optional. Suggests is a perfectly reasonable expression of that. Depends is not. > [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls > ipw2100-1.0.fwipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw > ipw2100-1.1.fwipw2100-1.2.fwipw2100-1.3.fwisl3890 > ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ > mv: cannot move `t' to a subdirectory of itself, `t/t' > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l > t/ > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko > insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko > insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko > > The module loaded without firmware, not? It detected my card, but > failed to load the firmware. > > ipw2100: Detected Intel PRO/Wireless 2100 Network Connection > ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. > ipw2100: eth1: ipw2100_get_firmware failed: -2 > ipw2100: eth1: Failed to power on the adapter. > ipw2100: eth1: Failed to start the firmware. > ipw2100Error calling regiser_netdev. > ipw2100: probe of :02:02.0 failed with error -5 > > I would say this is a functional driver. It provides me with useful > information about my system. The fact that I cannot connect to a wifi > lan is the same situation as with grub not being able to load XP > without the XP bootsector, if there were a free firmware with the same > API I would be able to load and use it. No. It's a driver for an ipw 2100; it has an ipw2100 and can't drive it. It's not functional -- it failed to power on the adapter. In the case of Windows and Grub, Grub is a generic bootloader. It can usefully boot Linux, Hurd, or NetBSD without access to an XP bootsector. It has significant useful functionality. What device can the ipw2100 driver drive without the firmware? > Making Debian uninstallable because of mistaken beliefs is too much > and I care enough to resists this. This certainly doesn't make Debian uninstallable. All the drivers in question can move to contrib. It just ensures that Debian ships only free software in Debian main. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
On Fri, Dec 17, 2004 at 11:36:09PM +0100, Måns Rullgård wrote: > > To me, that seems much like arguing that because an emulator (such as > > one for a console system) provides a GUI, and because it can run and > > display that GUI without needing a ROM, the emulator should go to main. > > I don't believe that is "a significant amount of functionality". Do > > you? Feel free to try to convince people. > > I'm convinced enough. Some time ago, I was playing around with an > emulator for Texas Instruments calculators. It obviously required a > ROM image to be useful, and the only legal way of obtaining one was > dumping it from your own calculator (an easy task). I still found > this emulator useful, since I happen to have one of the calculators. > By your reasoning, the only software allowed in main would be programs > that could be used on any machine that will run Debian at all. The > only things I can think of that all machines have are a CPU and a few > megabytes of RAM. Everything else is more or less optional. (I don't think this follows at all from his reasoning, but here I'm focusing on your reasoning, since it seems a little confused.) By your reasoning, everything in contrib should be moved to main, and contrib should not exist. Can you please explain what the difference is between your calculator example, and everything else in contrib? Free software that needs non-free software to function is not allowed in main. (There's no debate over this--it's a fundamental principle, straight out of the first clause of the Social Contract.) That's the whole reason contrib exists; that's where your calculator emulator would go, if no free ROM image was available. It doesn't matter how easy it is to get that ROM image. If it was distributed under a "distribute freely, but do not modify" license, it would be trivial to obtain, could go in non-free, and the emulator would be useful to people that don't own the calculator. Despite that, the emulator would still go in contrib. (The firmware debate is due, in part, to it not being immediately clear whether a driver requiring firmware to fire up a device counts as "depend[ing] on an item of non-free software", but your emulator example has no such ambiguity.) -- Glenn Maynard
Re: LCC and blobs
Josh Triplett <[EMAIL PROTECTED]> writes: >> But what if loading the firmware is not required? > >> That if the device was >> "warm-booted" in another OS? (I know there are technical limitations >> here) Would the driver-firmware relation still be a "depends"? > > No, then the driver Depends: firmware | other-os . We don't ship > either, so the driver still needs to go to contrib. :) And presumably > other-os depends (though not in the Debian package sense) on the > firmware as well, so even if that other OS was Free and we shipped it, > we'd be back to needing the firmware. What if every unit of this hardware included a CD with the required firmware? Then anyone in owning the hardware would also have the firmware, without Debian needing to touch it. For those not owning the hardware, the driver is obviously useless anyway. > To me, that seems much like arguing that because an emulator (such as > one for a console system) provides a GUI, and because it can run and > display that GUI without needing a ROM, the emulator should go to main. > I don't believe that is "a significant amount of functionality". Do > you? Feel free to try to convince people. I'm convinced enough. Some time ago, I was playing around with an emulator for Texas Instruments calculators. It obviously required a ROM image to be useful, and the only legal way of obtaining one was dumping it from your own calculator (an easy task). I still found this emulator useful, since I happen to have one of the calculators. Sure, the emulator is useless for anyone who doesn't own a calculator, but a lot of software is useless for a whole lot of people for all sorts of reasons. Is software only "free" if it is useful for *everybody*? Debian includes hundreds of programs that require a fast network connection to be useful. Lots of programs make specific use of various types of hardware (mice, printers, monitors, GPS receivers, etc.) and are quite useless without these. By your reasoning, the only software allowed in main would be programs that could be used on any machine that will run Debian at all. The only things I can think of that all machines have are a CPU and a few megabytes of RAM. Everything else is more or less optional. Maybe we should also consider that some software is only useful to a small set of people, such as those working in some specific field. If use of a program requires some knowledge of, say, signal processing, does that make it non-free? Education is far from free, and is certainly not distributed by Debian. Yes, I'm deliberately being a little extreme here, but I see no fundamental difference between requiring the user to possess some data and requiring the user to possess a physical object. -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde wrote: > Brian Thomas Sniffen wrote: >> Peter Van Eynde <[EMAIL PROTECTED]> writes: >>>[data == software ?] >> >> Bingo. Debian had this debate last year. There was a giant vote over >> it. Then another debate and another vote. > > Hmm. I remember we had an "editorial change" that then turned into Considering the fact that Debian has always considered "everything on the Debian CDs" to be subject to the DFSG (see Bruce Perens' messages on this topic around the time of the vote, along with agreement from others around at that time), it certainly seems like making that clearly explicit is nothing more than an editorial change. > something completely different, followed by 6 damage limitation options > and 1 hard line option. A damage limitation option won, but I if I read That's not an accurate summary: we had 4 variations on "postpone for Sarge", one "repeal the changes entirely" option, and one "do nothing, the changes apply for Sarge" option. I think that covers both extremes as well as many points in the middle. > the matrix correctly the hard line option was defeated by _every_ damage > limitation clause, so I would not be so certain that "we had this debate". Certainly we did; the votes were for two entirely different purposes. The first stated our position more clearly and unambiguously, and the second said "just because we are making this explicit doesn't mean we have to fix our lax enforcement of it immediately, before releasing Sarge". > Post-sarge we will have the debate and I hope that this time ftp-master > will state the consequences of the options in advance, so there are no > surprises any more. Also having less then 7 options would also be nice. We have already had the debate; we will not have it again post-sarge unless someone decides to raise another GR. Considering that one of the options in the previous GR was "repeal the changes entirely", and that option was at the bottom of the ranking along with the opposite extreme, I think it is quite clear that developers agree with the new social contract. Indeed, the vote before that showed that developers agree with it by more than a 3:1 ratio. :) >>[clarifications] > > I think I'm starting to understand your point of view. So _any_ use of > the software without using non-DFSG data makes it free, right? Within reason, yes. (Linker errors because a library is missing, or similar situations in which the only functionality is to tell you that a piece is missing, don't count.) > But what if loading the firmware is not required? > That if the device was > "warm-booted" in another OS? (I know there are technical limitations > here) Would the driver-firmware relation still be a "depends"? No, then the driver Depends: firmware | other-os . We don't ship either, so the driver still needs to go to contrib. :) And presumably other-os depends (though not in the Debian package sense) on the firmware as well, so even if that other OS was Free and we shipped it, we'd be back to needing the firmware. > Oh, I have another use for the ipw2100 driver without firmware: it can > recognise the card from the pci-id information. :-) To me, that seems much like arguing that because an emulator (such as one for a console system) provides a GUI, and because it can run and display that GUI without needing a ROM, the emulator should go to main. I don't believe that is "a significant amount of functionality". Do you? Feel free to try to convince people. Think about it this way: is that functionality sufficient that if the firmware was Free Software distributed in main, that you would still say the driver should only declare a Recommends or Suggests on the firmware? >> Please at least read Policy on what "Depends" means first. If you > > I see no mention of this in version 3.6.1.1. There is: > |5.6.9. Package interrelationship fields > -> see chapter 7 > |7.2. Binary Dependencies > -> is for debian packages. And has: > |... > |The `Depends' field should be used if the depended-on package is > required |for the depending package to provide a significant amount of > |functionality. > |... > |7.6. Relationships between source and binary packages > ->N/A > > There is no mention of dependency of packages on external data that fall > outside the packaging system. So what meaning do you mean? Dependencies on anything outside of the Debian archive automatically put a package in contrib; see "2.2 Sections". For example, see the packages placed in contrib because they depend on mplayer, despite the fact that mplayer is Free Software (just legally dangerous to package in any useful manner, rather than stripped of much of its useful functionality). > If you extend the rules for packages to firmware then the question > becomes what "significant amount of functionality" is. In the past it > was used for "can run", optional libraries were "Suggest"ed in. > > [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ > [EM
Re: LCC and blobs
On Fri, Dec 17, 2004 at 03:23:54PM +0100, Peter Van Eynde wrote: > Hmm. I remember we had an "editorial change" that then turned into > something completely different, followed by 6 damage limitation options and > 1 hard line option. A damage limitation option won, but I if I read the > matrix correctly the hard line option was defeated by _every_ damage > limitation clause, so I would not be so certain that "we had this debate". > > Post-sarge we will have the debate and I hope that this time ftp-master > will state the consequences of the options in advance, so there are no > surprises any more. Also having less then 7 options would also be nice. It was not "defeated", it was delayed until post-sarge, at which point the 2004-003 GR's SC will kick in automatically with no further debate. I don't know what debate you think we'll have; while I'm sure many debates on many topics will be held, 2004-003 *will* reactivate unless another GR is held to repeal it. > >[clarifications] > > I think I'm starting to understand your point of view. So _any_ use of the > software without using non-DFSG data makes it free, right? This is the widely-accepted understanding of software in main, yes. > But what if loading the firmware is not required? That if the device was > "warm-booted" in another OS? (I know there are technical limitations here) > Would the driver-firmware relation still be a "depends"? Then it requires that other OS to function. > Oh, I have another use for the ipw2100 driver without firmware: it can > recognise the card from the pci-id information. :-) That's attempting to sidestep the issue and pretend freeness isn't important, which isn't something Debian should be stooping to. :) > I would say this is a functional driver. It provides me with useful > information about my system. The fact that I cannot connect to a wifi lan > is the same situation as with grub not being able to load XP without the XP > bootsector, if there were a free firmware with the same API I would be > able to load and use it. If grub was only able to load XP, and not other operating systems, and it required XP's boot sector to be functional, it would probably go in contrib. However, grub loads several operating systems, so XP's boot sector is just "added functionality". > >also read the archives, you'll have a chance at understanding the For what it's worth, it's not really reasonable to expect people to "read the archives", since the archives on these topics probably exceed a thousand messages. > Well. The last couple of times I thought rationality would return and I > grew tired of the gedanken-experiments going on, and actually I did not > care for the documentation idiocy. I should have paied more attention to my > history classes and how extremists will take over democratic regimes > because the majority cannot be bothered resisting simplistic arguments > until it is too late. Making Debian uninstallable because of mistaken > beliefs is too much and I care enough to resists this. I survived Erik > Naggum, so this should be a walk in the park. So now you're saying that expecting that documentation be Free is "idiocy", and that the majority doesn't actually want it, despite the very clear results of GR 2004-003. Sorry, that's a tired old complaint that's not even worth refuting ... -- Glenn Maynard
Re: LCC and blobs
On Fri, Dec 17, 2004 at 10:33:41AM -0500, I clumsily wrote: > I was talking about the API the firmware uses -- the one that the program > contained in the API was designed to work with. That should have read: I was talking about the API the firmware uses -- the one that the program contained in the firmware was designed to work with. -- Raul
Re: LCC and blobs
> Raul Miller wrote: > > The API that is programmed by the firmware -- which you shouldn't confuse > > with the API used by the driver that downloads the firmware -- is not > > known to us. On Fri, Dec 17, 2004 at 03:51:22PM +0100, Peter Van Eynde wrote: > I don't understand you. Hmm... > An API is not "programmed". Programs are written against an API. The API represents the aspect of the computer which is being programmed when you write a program. > Something can provide or support an API or use an API. "Use an API" can correspond to an "API being programmed" for the case that that the use of the API involves the creation of a program to do the using. > In this case the firmware+hardware provides and API to the linux > driver. Sure. But that's not the API I was talking about. I was talking about the API the firmware uses -- the one that the program contained in the API was designed to work with. > It is known, we can support it. Which has nothing to do with the issue I was talking about, because you've got the wrong API. > If the device has bugs in executing the API it makes no difference if > there is a firmware or not to the driver, nor does it to our support > because we don't provide the firmware, we only use it. EXACTLY! We don't provide the firmware. And the reason we don't provide the firmware is that we don't understand the issues well enough to do so. This rather concisely captures what the DFSG is about. > The mere fact of uploading the firmware does not give us an obligation to > support it. And, in fact, we shouldn't support it. > If your printer misprints a page you don't expect debian to patch it do you? This is another good example. And, taking it a bit further, I think shipping a printer to me would be a waste of Debian resources. [That said, I don't have a printer.] > >>It is useful to re-upload the flash. Nothing else. So what is the > >>difference between this use and the driver that has to load it every time? > > The "has to" bit. > > If the "has to" is to do a specific task, eg connecting to a wifi network, > then the "has to" is no different from grub loading the XP bootsector. We don't distribute the XP bootsector. > In the other case the ipw2100 driver already loads and does some (very > limited) work. The issue is completeness. A piece of software which has to have some non-free software to become functional is useless without that non-free software. -- Raul
Re: LCC and blobs
Raul Miller wrote: On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote: The API is known, otherwise there would be no Linux driver. The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. I don't understand you. An API is not "programmed". Something can provide or support an API or use an API. In this case the firmware+hardware provides and API to the linux driver. It is known, we can support it. If the device has bugs in executing the API it makes no difference if there is a firmware or not to the driver, nor does it to our support because we don't provide the firmware, we only use it. The mere fact of uploading the firmware does not give us an obligation to support it. If your printer misprints a page you don't expect debian to patch it do you? ... It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The "has to" bit. If the "has to" is to do a specific task, eg connecting to a wifi network, then the "has to" is no different from grub loading the XP bootsector. In the other case the ipw2100 driver already loads and does some (very limited) work. Groetjes, Peter
Votre commande est acceptée!
Nous avons le plaisir de vous annoncer que votre commande a été accepté le 2004-12-17. Votre paquet Eurorest contient les informations suivantes: 1. Un chèque hôtelier international Eurorest 2. Un réglement du système Eurorest Votre ID de Participant de l'Action: HW2B2-YDSR6 La forme d'expédition choisie: par courrier Le délai de paiement: paiement à la réception. --- Montant de la commande: 38,90 EUR --- Votre commande vous sera expédiée demain, à l'adresse indiquée dans le bon de commande: Tensiong-Duboss Alain 59, boulevard Vincent Auriol 75703 Paris Cedex 13 France Si vous remarquez des erreurs dans le bon de commande, contactez nous immédiatement à l'adresse e-mail: [EMAIL PROTECTED] Nous vous remercions de votre confiance et vous souhaitons d'agréables vacances. Pour toutes questions nous restons à votre entière disposition. Bonne chance Les consultants du Bureau d'information Eurorest
Re: LCC and blobs
Brian Thomas Sniffen wrote: Peter Van Eynde <[EMAIL PROTECTED]> writes: Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. :-) >>[data == software ?] Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. Hmm. I remember we had an "editorial change" that then turned into something completely different, followed by 6 damage limitation options and 1 hard line option. A damage limitation option won, but I if I read the matrix correctly the hard line option was defeated by _every_ damage limitation clause, so I would not be so certain that "we had this debate". Post-sarge we will have the debate and I hope that this time ftp-master will state the consequences of the options in advance, so there are no surprises any more. Also having less then 7 options would also be nice. >[clarifications] I think I'm starting to understand your point of view. So _any_ use of the software without using non-DFSG data makes it free, right? But what if loading the firmware is not required? That if the device was "warm-booted" in another OS? (I know there are technical limitations here) Would the driver-firmware relation still be a "depends"? Oh, I have another use for the ipw2100 driver without firmware: it can recognise the card from the pci-id information. :-) Please at least read Policy on what "Depends" means first. If you I see no mention of this in version 3.6.1.1. There is: |5.6.9. Package interrelationship fields -> see chapter 7 |7.2. Binary Dependencies -> is for debian packages. And has: |... |The `Depends' field should be used if the depended-on package is required |for the depending package to provide a significant amount of |functionality. |... |7.6. Relationships between source and binary packages ->N/A There is no mention of dependency of packages on external data that fall outside the packaging system. So what meaning do you mean? If you extend the rules for packages to firmware then the question becomes what "significant amount of functionality" is. In the past it was used for "can run", optional libraries were "Suggest"ed in. [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls ipw2100-1.0.fwipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw ipw2100-1.1.fwipw2100-1.2.fwipw2100-1.3.fwisl3890 ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ mv: cannot move `t' to a subdirectory of itself, `t/t' [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l t/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko The module loaded without firmware, not? It detected my card, but failed to load the firmware. ipw2100: Detected Intel PRO/Wireless 2100 Network Connection ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. ipw2100: eth1: ipw2100_get_firmware failed: -2 ipw2100: eth1: Failed to power on the adapter. ipw2100: eth1: Failed to start the firmware. ipw2100Error calling regiser_netdev. ipw2100: probe of :02:02.0 failed with error -5 I would say this is a functional driver. It provides me with useful information about my system. The fact that I cannot connect to a wifi lan is the same situation as with grub not being able to load XP without the XP bootsector, if there were a free firmware with the same API I would be able to load and use it. also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. Well. The last couple of times I thought rationality would return and I grew tired of the gedanken-experiments going on, and actually I did not care for the documentation idiocy. I should have paied more attention to my history classes and how extremists will take over democratic regimes because the majority cannot be bothered resisting simplistic arguments until it is too late. Making Debian uninstallable because of mistaken beliefs is too much and I care enough to resists this. I survived Erik Naggum, so this should be a walk in the park. Groetjes, Peter
Re: Copyleft font licensing
> > I don't really understand this. I suspect I'm not thinking what you're > > thinking "real sourced code" means. On Fri, Dec 17, 2004 at 09:18:37AM +0100, Florian Weimer wrote: > A METAFONT program, for example. Ok, but in that context it's pretty clear that the font is not the program. In that case, the font is the output of the program. This is easy to see because the font doesn't have all the capabilities of the metafont program. -- Raul
Re: LCC and blobs
> Raul Miller wrote: > > Fundamentally, the DFSG is aimed at making sure that we can provide the > > software that we can support. Restrictions that leave us writing an > > opaque blob of bits which drives an unknown API very much put us into > > a context where we can't know that we're doing the right thing. On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote: > The API is known, otherwise there would be no Linux driver. The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. > The fact that we uploaded the firmware does not excuse the device from > respecting its API. Personally, I've never found devices to be particularly apologetic under any circumstances. > Nor is it our task to write the firmware, Debian is a distribution for > general-purpose computers, if you want to have a distribution for firmware > you are free to do so. Are you thinking that these firmware devices are not used in general purpose computers? If not, this seems about as relevant as the other stuff you've said (which is to say: not at all). > Debian should consider hardware as things that you have to talk to with a > certain protocol. This would make all software which uses a well defined interface into hardware > It is useful to re-upload the flash. Nothing else. So what is the > difference between this use and the driver that has to load it every time? The "has to" bit. -- Raul
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > Please at least read Policy on what "Depends" means first. If you > also read the archives, you'll have a chance at understanding the > position of other debaters here, and of generating original > arguments. So far, this is all a repeat. It wasn't convincing any of > the last couple times, so it won't be this time. Note that the social contract says "requires", not "depends". I'm inclined to believe that policy is in the wrong here. (This does not mean that I believe the social contract's wording to be sane in this respect) -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen wrote: >> Peter Van Eynde <[EMAIL PROTECTED]> writes: >>>And now you consider it software just because the method of storage is >>>different? How can the nature of the bytes change because they are >>>stored on a disk? >> The nature of the bytes do not change. But my name, distributed in a >> Debian package, is software. My name, written in letters of granite > > You name is software! > Now I'm a Common Lisp hacker, you know the data is code people, but > even _we_ do not consider a string software unless it drives some > software. > > Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. >> Architectural plans for a house, shipped in a Debian package, are >> software. > > I'm stunned. So anything in a Debian package is software. With alien I > can convert a tar.gz into a debian package, so all tar files are > software. With tar I can create a tar.gz from any file, so all > electronic data is software? Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. "software" is not "program". Programs are software that happens to be executable. Data is not executable, but still software. > And you restrictions that any package that depends on non-DFSG > "software" to work cannot be in main means that after releasing sarge > we have to remove from main: > > - all bootloaders. Grub cannot start my XP without the XP > bootsector. Grub doesn't depend on XP's bootsector. It provides other useful functionality -- booting Linux -- without it. That's more of a Suggests. > - tftpd. I want to netboot my Solaris machines. The tftpd needs the > solaris code to "work". It implements the tftpd protocol all by itself. There are even plenty of tftp clients out there. Apache doesn't become non-free because you want to use it to distribute your great novel... which you haven't written yet. > Should I go on? Please at least read Policy on what "Depends" means first. If you also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen wrote: >> Some firmware is part of the hardware. Some isn't. It's easy to tell >> -- either it's in the hardware or it isn't. Of course, the name >> "firmware" should make it clear that this is an often ambiguous line. >> But this does seem to be a good practical place: can anybody with the >> device and the driver use it? Or are there some people who even with >> a functioning, complete device and a driver who can't get it to work? > > This is not only a feature of a device with firmware. Some hardware > you cannot buy, you only get a license to use it. If I remember > correctly you never "buy" an EMC, you only get permission to use it > and have to pay every year to continue to use it. > > So you want to rip out all fiber-channel drivers because they might be > used to connect to an EMC? No. They have useful functionality in connecting to other fiber-channel devices. Open standards are a nice thing. The fiber-channel devices have no dependency on the EMC hardware -- and even if they did, Debian doesn't express dependencies on hardware in its packaging system. >>>I see no limitation of my freedom in using firmware. Please tell me >>>how I am limited in my freedom. If I wanted a open source firmware I >>>could buy a device with open firmware, >> Then Windows isn't proprietary either. Sigh. > > It is, but does the fact that I can boot it with grub limit my freedom? Of course not -- and grub can boot Linux or the Hurd, too. So Grub has no dependency on Windows. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
On Fri, Dec 17, 2004 at 10:45:07AM +0100, Peter Van Eynde wrote: > Matthew Palmer wrote: > >>Should I go on? > > > > > >No, I think you've adequately demonstrated that you don't have the foggiest > >idea what you're talking about. > > Ok. I'm game. Why? Where is the error my in applying your rules? Primary purpose, for a start. "Perl can't go in main because it's useless without some non-free, perl-using app" is ridiculous. - Matt signature.asc Description: Digital signature
Re: LCC and blobs
Matthew Palmer wrote: Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. Ok. I'm game. Why? Where is the error my in applying your rules? Groetjes, Peter
Re: LCC and blobs
Raul Miller wrote: Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. The API is known, otherwise there would be no Linux driver. The fact that we uploaded the firmware does not excuse the device from respecting its API. Nor is it our task to write the firmware, Debian is a distribution for general-purpose computers, if you want to have a distribution for firmware you are free to do so. Debian should consider hardware as things that you have to talk to with a certain protocol. [hardware with build in flash that lost the flash] However, unlike non-flash devices that need the firmware uploaded every time, the driver is still useful without it. Yes. It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? Groetjes, Peter
Re: LCC and blobs
Brian Thomas Sniffen wrote: Some firmware is part of the hardware. Some isn't. It's easy to tell -- either it's in the hardware or it isn't. Of course, the name "firmware" should make it clear that this is an often ambiguous line. But this does seem to be a good practical place: can anybody with the device and the driver use it? Or are there some people who even with a functioning, complete device and a driver who can't get it to work? This is not only a feature of a device with firmware. Some hardware you cannot buy, you only get a license to use it. If I remember correctly you never "buy" an EMC, you only get permission to use it and have to pay every year to continue to use it. So you want to rip out all fiber-channel drivers because they might be used to connect to an EMC? I see no limitation of my freedom in using firmware. Please tell me how I am limited in my freedom. If I wanted a open source firmware I could buy a device with open firmware, Then Windows isn't proprietary either. Sigh. It is, but does the fact that I can boot it with grub limit my freedom? Groetjes, Peter
Re: LCC and blobs
On Fri, Dec 17, 2004 at 09:53:51AM +0100, Peter Van Eynde wrote: > I'm stunned. So anything in a Debian package is software. With alien I can > convert a tar.gz into a debian package, so all tar files are software. With > tar I can create a tar.gz from any file, so all electronic data is software? > > And you restrictions that any package that depends on non-DFSG "software" > to work cannot be in main means that after releasing sarge we have to > remove from main: [Several rather absurd overgeneralisations] > Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. - Matt signature.asc Description: Digital signature
Re: LCC and blobs
Brian Thomas Sniffen wrote: Peter Van Eynde <[EMAIL PROTECTED]> writes: And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite You name is software! Now I'm a Common Lisp hacker, you know the data is code people, but even _we_ do not consider a string software unless it drives some software. Is your name input for a state-machine? Architectural plans for a house, shipped in a Debian package, are software. I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? And you restrictions that any package that depends on non-DFSG "software" to work cannot be in main means that after releasing sarge we have to remove from main: - all bootloaders. Grub cannot start my XP without the XP bootsector. - tftpd. I want to netboot my Solaris machines. The tftpd needs the solaris code to "work". - all font renderers. I want to see a document with the font I bought, and without it the document is broken, so the renderer needs the font, right? - all interpreters. I want to run HACMP. It is in perl, so the perl is useless to me without HACMP. - the kernel. I want to ship a stripped down debian with my non-DFSG code in an embedded system. The kernel is useless without my code, so the kernel cannot be in main. Should I go on? Groetjes, Peter
Re: Copyleft font licensing
* Raul Miller: >> Anyway, this isn't the case I'm really interested in. And if there's >> real source code, it should be reasonably clear that the GPL is >> impractical. > > I don't really understand this. I suspect I'm not thinking what you're > thinking "real sourced code" means. A METAFONT program, for example. > That said, if the GPL is really a problem, and you're the copyright > holder, you could always use BSD's license. Even if I were the copyright holder, I'd rather use a copyleft license.
