compatibility of OpenSSL and GPL'ed plugins
Let's consider a program, released under a MIT/X11 license and linked with OpenSSL. Some GPL'ed plugins (which are dlopen'ed at run time) are distributed with the program. Is distribution of this package a GPL violation? The plugins are actually a modified version of standalone applications, so I'm not sure if they could be considered derived works of the program, but then I'm not sure if this is relevant at all. -- ciao, | Marco | [7165 erXciRgTCHhbw]
Re: RPSL and DFSG-compliance
[EMAIL PROTECTED] wrote: >Debian's committment to Free Software does not stop at the DFSG. The "G" >in Debian Free Software Guidelines means "Guidelines". Obviously, this is your personal view of the issue, not shared among all developers. -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >> >You're asking why I think "can be flashed, but works just fine without >> >being flashed" is different from "won't work without being loaded"? >> > >> >Fundamentally, the latter case forces us to not ignore it. The equipment >> >won't work if we ignore the issue. > >On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote: >> So you say that non-free software is OK with you as long as you can >> pretend it's not there? Which part of the policy or SC justifies this >> theory? > >So you say that I was talking about pretending? Which part of what I >wrote justifies this interpretation? > You wrote "the latter case forces us to not ignore [non-free software running on a system]". To me, this implies that in the other cases you deliberately choose to ignore it. -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >> Yes, sure! If some stream of bits is considered software when stored in >> RAM then I can't see why it should not be software anymore when stored >> in some other media. I have not seen any convincing argument about why >> software should lose its nature if stored in ROM. >> If the conseguences of this are that some interpretations of the policy >> or social contract are inconsistent then maybe you should start >> considering that they may really be, after all. >How about when they're stored on paper? It's still software, stored on paper. Why not? >How about when they're burned into a different sort of persistent >chip, like an FPGA? If you believe that an FPGA design stored in a file on your hard disk is software then I believe that it's still software when copied to a FPGA. Again, why not? >How about CAD/CAM instructions, once embodied in a manufactured >device? Is my coffee mug still software? Obviously not: the mug does not contain software (but maybe you could start a contest for the shortest CAD/CAM file which can generate a mug with a copy of itself printed on it). >>>Looks like hardware, acts like hardware. >> To me, it looks like software stored in hardware. >>>Of course, it's a boundary case--it's neither strictly hardware nor software. >> Really? I think it's quite clear. >That's because you're not thinking about all the ramifications. I think you need to work a bit more on your mind-reading skills. -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >> >On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote: >> >> So you say that non-free software is OK with you as long as you can >> >> pretend it's not there? Which part of the policy or SC justifies this >> >> theory? >If I ignore something as a part of a system when that thing is outside >that system, there doesn't need to be any pretending. OK, then I have issues with the english language. Let's try again: So you say that non-free software is OK with you as long as you can ignore it's running on your system? Which part of the policy or SC justifies this theory? -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >On Thu, Nov 04, 2004 at 04:42:00PM +0100, Marco d'Itri wrote: >> So you say that non-free software is OK with you as long as you can >> ignore it's running on your system? Which part of the policy or SC >> justifies this theory? > >No, I've been saying that non-free software can be ignored as long as >it's not a part of our system. How do you define what is part of our system, and from what you derive this definition? -- ciao, Marco
Re: Bug#281672: marked as done (autoconf: non-free documentation)
[EMAIL PROTECTED] wrote: >From what I can tell, the overall consensus was that sarge should >release with GFDLed and similar works in place, and that we should >remove these works post-sarge. You are confusing the result of a votation with a consensus. These are pretty different things. -- ciao, Marco
Re: firmware : which license "less worse" available
[EMAIL PROTECTED] wrote: >Of course, debian-legal declared this situation at best contrib for debian-legal is just a mailing list and cannot declare anything. Many people here like to declare things, but this does not mean that they will be accepted by the project. -- ciao, Marco
Re: Are BLOBs source code?
On Dec 12, Bruce Perens <[EMAIL PROTECTED]> wrote: > A lot of these BLOBs have been identified as ARM7 code, and generally > "thumb" (the 8-bit ARM instructions). I know of some devices (very cheap stuff, nothing fancy) which even uses VxWorks. This explains why it is not even possible for some manufacturers to open the firmwares for their devices. -- ciao, | Marco | [9734 pa.Q8hjFjTs3g]
Re: LCC and blobs
On Dec 11, Glenn Maynard <[EMAIL PROTECTED]> wrote: > If the driver has to be able to open the file and read the blob so it > can send it to the device, there's a clear relationship and dependency > between the driver and the blob: if you don't have a copy of the blob, > the driver doesn't work. (Spewing out "hardware error, firmware not > loaded" doesn't count to me as "working".) The driver is fully capable by itself of driving the device, which is what it is designed to do. The hardware device may not work, but this is not due to a failure of the driver in doing whatever it needs to do. So, for me this qualifies as "working". -- ciao, | Marco | [9735 inevA7NZIx.BE] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 18, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > 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 No: it's reporting that the card did activate correctly, but it's not the driver's fault. The driver is complete and does not lack anything needed to operate the device. > 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. Packages in contrib are not part of debian. It's funny that after some people tried hard to remove any trace of non-free software from the debian archive now there is the concrete risk that using contrib and non-free will be mandatory for many users. -- ciao, | Marco | [9900 stMOs23QwadkU] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 18, Glenn Maynard <[EMAIL PROTECTED]> wrote: > 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, Just about every driver "needs" some software stored in flash EEPROM chips in your computer. > > 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 Let's suppose that this compact flash card were soldered to a PCI compact flash adapter. Would this still be software and an element of the debian dependecy chain? -- ciao, | Marco | [9901 riFoIPUHY2X7A] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 19, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > > No: it's reporting that the card did activate correctly, but it's not > > the driver's fault. The driver is complete and does not lack anything > > needed to operate the device. > ...except the firmware? No: the driver does not uses the firmware, the device does. The driver stays the same before and after the firmware has been uploaded. -- ciao, | Marco | [9915 luo2sWGzUZ9b.] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 19, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > >> > No: it's reporting that the card did activate correctly, but it's not > >> > the driver's fault. The driver is complete and does not lack anything > >> > needed to operate the device. > >> ...except the firmware? > > No: the driver does not uses the firmware, the device does. > > The driver stays the same before and after the firmware has been > > uploaded. > But the driver would not have reported that message if it had had > access to the firmware. Look, you can't seriously argue that the Which is something I do not consider relevant. > device is software, or that the device+driver bundle doesn't operate I'm not. > differently depending on the presence of additional software -- the > kernel, for example, or the firmware. I'm not doing this either. -- ciao, | Marco | [9940 rirFdg9dkkjso] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 20, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > >> differently depending on the presence of additional software -- the > >> kernel, for example, or the firmware. > > I'm not doing this either. > Great. Then the driver operates differently depending on the presence > of additional software -- it needs a Linux kernel and the firmware. But then drivers also "depend" on "additional softwares" stored in flash EEPROMs in devices. > Without either of those, it does not operate. This is a dependency. But then ICQ clients "depend" on non-free ICQ servers... -- ciao, | Marco | [9952 daGqzkCAC8yJA] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 25, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > > Yet, CF is actually chips --- often the same chips as used to hold > > firmware distributed with hardware. Thus, it's all hardware. > Sure. It's on a medium for software exchange, thus it's software. If > it were an integral component of a device, it'd be hardware. I've This is an interesting criteria, but which part of the policy or of the social contract specifies it? > never been confused when looking at such things; the closest case I've > found to confusing is the MP3 player, which has its OS on disk. I'm > inclined to say that it's software to the MP3 player, an architecture > which Debian does not support. It's hardware, a drive, to the > (Intel?) Debian-supported PC to which it's connected. So a driver for an USB MP3 player requiring a non-free firmware is OK for you, but a driver for an USB DSL modem requiring a non-free firmware is not? -- ciao, Marco signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 28, Raul Miller <[EMAIL PROTECTED]> wrote: > On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote: > > Yet the ICQ client is not useful without a component which is not in > > Debian and in fact is not freely available. > Same thing applies to hardware drivers. And, for that matter, all of > the kernel. From this I conclude that the criteria you would like to use needs some more refining... -- ciao, Marco signature.asc Description: Digital signature
Re: LCC and blobs
[EMAIL PROTECTED] wrote: >The relevant distinction is whether whether or not we consider there to >be an adequate abstraction barrier between the two pieces of code. >Other distinctions don't really matter. Then why you keep talking about where firmware is stored? >Drivers for firmware, where the driver would typically be non-functional >if we didn't ship some non-free software image, we've been treating as >depending on non-free software. No, "we" have not. A few people did. -- ciao, Marco
Re: LCC and blobs
On Jan 06, Josh Triplett <[EMAIL PROTECTED]> wrote: > An ICQ client wouldn't Depends: icq-server; it might Suggests: > icq-server, but that's OK. A driver might at most Suggests: > burned-in-firmware-for-reflashing, but it would Depends: or at a minimum > Recommends: firmware-loaded-by-driver. I can't see how you did come to these conclusions. > We all understand what Depends:, Recommends:, and Build-Depends mean; we Not if they refer to things which are not debian packages. -- ciao, Marco signature.asc Description: Digital signature
Re: LCC and blobs
On Jan 07, Josh Triplett <[EMAIL PROTECTED]> wrote: > I'll assume for the moment you are only disagreeing with the > driver->firmware dependencies, not the client->server dependencies, > since the latter is standard Debian policy. No. What I'm saying is that if you stretch the definition of "requirement" enough to cover firmwares then it will cover also things like ICQ clients. > On the other hand, if the driver must load the firmware, then the driver > cannot correctly function if the firmware is not present, so the driver No, I already explained why this is wrong. The driver functions correctly and is fully functional with or without the firmware being loaded in the device. The firmware being loaded or not in a device does not change the essence of a driver nor its capabilities (actual or potential). > >>We all understand what Depends:, Recommends:, and Build-Depends mean; we > > Not if they refer to things which are not debian packages. > I'm saying that from the perspective of checking the dependencies of a > package in main, we should treat anything that is "too non-free for > non-free" as identical to things packaged in non-free. Yes, but if the firmware of a device is considered a dependency of a device driver then an ICQ server has to be considered a dependency of an ICQ client. -- ciao, Marco signature.asc Description: Digital signature
Re: LCC and blobs
On Jan 08, Josh Triplett <[EMAIL PROTECTED]> wrote: > atmel-firmware . Would you argue that at76c503a-source should neither > Depends: nor Recommends: atmel-firmware ? If so, why? If you changed Yes. Read the debian-legal@ archive if you care about the details. -- ciao, Marco signature.asc Description: Digital signature
Re: why is graphviz package non-free?
[EMAIL PROTECTED] wrote: >i have read that graphviz is licensed under the Common Public License >Version 1.0 [1]. The FSF consider this license as free and also in the >debian-legal mailing-list archive i couldn't find a statement that debian >have a different view. >So why this package is in non-free? As explained at the top of the page, it has been recently relicensed. If this CPL is the usual CPL we know about then it should be moved to main. -- ciao, Marco
Re: Bug#317359: kde: ..3'rd "Help"->"About $KDE-app" tab calls the GPL "License Agreement", ie; a contract.
[EMAIL PROTECTED] wrote: >I think there's wide agreement here that forced click-wrap licenses >are non-free, and very impractical. I've seen installers in Windows Maybe impractical, but so far I can't see why they should be non-free. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MP3 decoder packaged with XMMS
[EMAIL PROTECTED] wrote: >In any case, I don't think denying our users access to files they have every >legal right to use is an appropriate way to try to kill off the mp3 format. >Even if it were, would you really have us do so by treating unsubstantiated >patent claims about mp3 decoding as if they were valid? This would mean not >only that Debian wouldn't support mp3 players, but also that we wouldn't >support mp3 *converters* for extracting legacy data. Is that really helping >anyone? It's not very different from the argument which keeps random emulators or scummvm in contrib. And yes, I agree that it's a bad argument. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
firmware files (Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source)
On Nov 19, Oliver Kurth <[EMAIL PROTECTED]> wrote: >The firmware is needed. Without it, the device is completely dumb. >But there are some devices which can store the fw permanently. Also, >the fw is distributed on their (windows) installation CDs. Make an unofficial package which will contain just the firmware and distribute it from your web site. This is what I will do for my own packages. When sarge+1 will be released with a list of tens of unofficial repositories for firmwares maybe somebody will realize that some firmwares will probably never be free software, and restricting their distribution will not help encouraging developers to write free ones. Beware: I accept arguments about how using a non-free firmware is unacceptable only from people who have none in their hardware, and I'm sure that nobody here qualifies. Saying that some non-free software is OK because it comes in a EEPROM instead of on a CD is hypocrisy. In main there are already other free drivers for devices which require a firmware, so this is not a problem. The policy requires packages in main to "not require a package outside of main for compilation or execution", and the driver itself is fully functional even without the firmware. (The device may be a paperweight, but policy does not cover this.) -- ciao, | Marco | [3172 l'XoRKaZ02QyI] signature.asc Description: Digital signature
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >I have just packaged a driver for wifi cards. The driver is licensed >under GPL, but the cards needs a non-free firmware to be uploaded in >order to work. I will quote from policy 2.2.2: Examples of packages which would be included in _contrib_ or _non-US/contrib_ are: * free packages which require _contrib_, _non-free_ packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. Your driver can be compiled and successfully executed without the firmware, so it should go in main because it's free software. As you correctly stated, the card needs a firmware, not the device driver. The hardware device may not perform useful work until its firmware has been loaded, but we distribute the driver and not the device. A similar issue was raised for clients for proprietary instant messaging protocols like AIM and MSN: long ago it was decided that as long as they are DFSG-free they can be part of Debian, even if they are obviously useless without the proprietary servers they connect to. Considering that every complex device needs a firmware to work (of which usually we lack the source code), I cannot see why it should be relevant for our policy or detrimental to the cause of free software if this firmware is distributed by the hardware producer on a CD or in a flash EEPROM. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Probably the right question to ask is: is there any chance to use the >driver without touching the non-free firmware (nor any other non-free >stuff, for that matters)? Can you quote which part of the policy describes this criteria? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >If the driver does not provide any significant functionality without the >firmware, it belongs in contrib. The driver provides all of its functionality without the firmware, the firmware never becomes part of the driver. The hardware device may or may not provide useful functionality, but debian is not in the business of distributing hardware. >If there are some cards which the driver drives which work without the >firmware, it can go in main. I can affirm with reasonable certainty that there is a very tiny number of devices in your computer which works without a firmware. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >I think it's a question of what "dependence" means for contrib. If the >driver absolutely _depends_ on using the non-free firmware, it should be >in contrib. If the non-free firmware is optional, it should go into >main. Again, please explain which part of the policy defines this criteria. >Of course, there's shades of gray, here. If all the driver does is emit >a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware, >it's hard to say that it doesn't depend on the firmware. But if the This applies to almost every driver in the Linux kernel. Are you ready to move most of the kernel to non-free too? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >On the other side, if it is possible to distribute the firmware in the >non-free section (I have to ask that to Texas Instrument), the package >of the driver will have a Depends: or at least a Recommends: on the >firmware package. In that case it seems that the driver has to go in >contrib. Right, the package in main should not depend on an hypothetical package from non-free. -- ciao, Marco
Re: firmware status for eagle-usb-*: non-distributable
[EMAIL PROTECTED] wrote: >This package should be removed from Debian before Debian gets sued for >copyright infringement. Can you cut this bullshit please? You know well that Debian is not going to get sued. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >>>Of course, there's shades of gray, here. If all the driver does is emit >>>a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware, >>>it's hard to say that it doesn't depend on the firmware. But if the >> This applies to almost every driver in the Linux kernel. >Less than 14% of the driver source files in 2.4.26 even mention the word >'firmware'. Hardly 'almost every driver'. You obviously missed the point. Almost every driver talks to a device which needs some kind of firmware, but you obviously noticed the ones which do not have it on a non-volatile medium. Why should debian adopt a different policy if the vendor provides this firmware on a CD instead of on a flash EEPROM chip? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> Right, the package in main should not depend on an hypothetical package >> from non-free. >So rather than ship the driver in contrib and the firmware in >non-free, you're suggesting that the driver go in main and the >firmware not be shipped at all, even though that reduces the >functionality of the driver to "Error: no firmware found." Yes. I believe that this better serves our users. I can think about at least two common situations in which an hard dependency would not be appropriate or even possible: - when distribution is restricted by copyright, so we cannot distribute it even in non-free (usually when the driver has been developed from scratch by a third party) - when the firmware is used by a device needed to install the system, like a network card or a modem (if the user has got the Debian system on a CD it may be easier for him to get the firmware from the vendor CD than downloading it and the transfering it to the target system using some removable media) >That seems as clear a dependence as any other foo and foo-data package >in the repository. Probably because you did not think much about real-life issues... -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
On Oct 11, Evan Prodromou <[EMAIL PROTECTED]> wrote: > > I think it's a question of what "dependence" means for contrib. If the > > >driver absolutely _depends_ on using the non-free firmware, it should be > > >in contrib. If the non-free firmware is optional, it should go into > > >main. > > Again, please explain which part of the policy defines this criteria. > http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib I still cannot see anything in policy which would support the above statement. Can you make your reasoning explicit? > > This applies to almost every driver in the Linux kernel. Are you ready > > to move most of the kernel to non-free too? > I'd probably dispute whether it's _every_ driver in the kernel, and it's > not my decision, but as I understand it that's exactly what we're doing. So you understand that we will remove from the kernel e.g. ide-cd and the ACPI subsystem? This does not appears to be correct to me. -- ciao, | Marco | [8494 inqrUeKSSNzr2] signature.asc Description: Digital signature
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >It's a perfectly reasonable means to discriminate. One is *in the >hardware*. If I buy a widget, I don't care whether it uses firmware >in an eeprom or a well-trained gerbil. It's a box. Software on my >CPU is different. Firmwares do not run on your CPU. Your poing being? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> Why should debian adopt a different policy if the vendor provides this >> firmware on a CD instead of on a flash EEPROM chip? >Because of the reasonable expectation that the user already has the >EEPROM chip, and it's part of the hardware. It's not something Debian >could ship or will. So? I can't follow your logic. Please be more verbose exaplaining your reasoning. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Anyways, here's the relevant quote: > >"Examples of packages which would be included in contrib or >non-US/contrib are: [...] free packages which require contrib, >non-free packages or packages which are not in our archive at >all for compilation or execution, " > >As I said, there's some wiggle room on what "require... for compilation >or execution" means. But not a lot. As I explained, I do not think that "execution" covers what may or may not happen in a different program in a different CPU. The purpose of a device driver is controlling a device, and these drivers are fully capable of doing this without the need of anything else. This is the same situation of IM programs. >I think you'd like to make the point that kernel drivers that depend on >firmware flashed to an eeprom are functionally equivalent to kernel >drivers that depend on firmware blobs that are uploaded at runtime. I >don't have much opinion on this. You should, because if you were to conclude that both classes are equal you would have to ask moving the whole kernel to contrib. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >If you want to argue that a package in contrib should be included on CDs >or in the installer, feel free to argue that. Please do not conflate >that issue with the entirely non-technical decision of whether a package >goes in main or contrib; otherwise, you are doing a disservice to >another important class of users, namely those who count on Debian to be >true to its stated values and keep the clear distinction between main, >contrib, and non-free. I consider doing a disservice to our users (and an insult to the developers of such drivers) keeping free software out of debian because of, at best, unclear and not consistent criteria. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Marco, it seems to me that there's a parallel case to non-free >firmware: dongleware. Perhaps you could explain how this philosophy >applies to that. If a piece of software is distributed under the GPL, >can I add functionality by putting it into firmware on a dongle and >having GCC call that? I'm not sure: it may or it may not. If you want my opinion please show me a complete example. E.g. I do not consider non-free the openssl code which talks with crypto accelerators cards. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >I think that requiring a hardware upgrade to support behavior is >irrelevant to free software. Firmware that's part of the hardware is >part of the hardware. Firmware that looks like software is software. >If Debian *could* ship it, it's software. This distinction is not clear at all to me. What if I take a dump of the flash EPROM chip? Does this magically makes the firmware a software? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >In both cases, the quantity of non-free software used has remained the >same. The purpose of contrib is to discourage free software with >non-free dependencies. Deciding whether software falls into it or not >purely based on another vendor's choice of media seems mad. Either we >disapprove of hardware that requires non-free firmware, or we don't - >whether it has to be on the user's hard drive is a hardware >implementation issue, not a philosophical difference. This is my position too. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >I find the criteria extremely clear and consistent: if it depends on >stuff that is either non-free, or that is too non-free to even ship, it >goes to contrib. If a user can install and run it (and be able to But, as I already explained, the driver does not depend on the firmware and is fully functional without it. So you are the one who is arguing to force a dependency. >non-free firmware also goes to main. Now, what differentiates the case >of requiring non-free firmware from the case of requiring non-free NDIS >drivers? NDIS drivers are drivers running on your CPU, and writing free drivers from scratch without support from the hardware vendor is plausbile (and useful). Firmwares do not run on the host CPU (they are /data/ for the host system), and reverse engineering one is not plausible and probably not useful either. And again, almost every device needs a firmware, either already on board or uploaded by the host, so the quantity of non-free software used does not change. So, if a driver for a network card with on board firmware is in main, why a driver for a network card with uploadable firmware should be in contrib, if in both situations the same quantity of non-free software is being used? >separately. Why not let ndiswrapper go to main? And if you think ndiswrapper should go in main because I'm sure that there are free NDIS drivers around. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >That would probably depend on the license on the non-free drivers. We are not discussing non-free drivers, but 100% free (usually GPL'ed) drivers. >One problem with "non-free drivers in downloaded firmware" is that they >can be licensed such that not everyone who owns the hardware can use >the firmware. Why should this be worse than firmwares distributed on flash, which is not even explicitly licensed at all? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Marco d'Itri wrote: >> So you understand that we will remove from the kernel e.g. ide-cd and >> the ACPI subsystem? This does not appears to be correct to me. >Is it completely impossible to have an IDE CD drive or an ACPI hardware >system without keeping part of it under proprietary copyright or patent >control? (i.e. is there a patent issue or an issue with restrictive >standards licensing?) I expect CD players to be subject to many patents, but I have never investigate the issue (some may be expired). -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >>>If Debian *could* ship it, it's software. >> This distinction is not clear at all to me. What if I take a dump of the >> flash EPROM chip? Does this magically makes the firmware a software? >There's no magic about it. If I build a simulator for some hardware, >then my simulator's software. It's also a different thing. Your point being? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> Your driver can be compiled and successfully executed without the >> firmware, >But does it do anything useful when executed?... I don't know how you define "useful". All its functionality is already there, but probably the controlled device will only respond to a subset of the available commands until its firmware is uploaded. But again, this is a "limitation" of the hardware device, not of the driver. >Actually, I'm inclined to be very broad-minded on that point. If the >driver, for instance, can load arbitrary microcode to the hardware at Sure, it will upload whatever you feed it. >> A similar issue was raised for clients for proprietary instant messaging >> protocols like AIM and MSN: long ago it was decided that as long as they >> are DFSG-free they can be part of Debian, even if they are obviously >> useless without the proprietary servers they connect to. >Interesting. Do alternative servers exist for these protocols? Not that I know. -- ciao, Marco
Re: firmware status for eagle-usb-*
In article <[EMAIL PROTECTED]> you wrote: Loïc, I suggest you read the whole debian-legal thread named "non-free firmware: driver in main or contrib?", because it answers many of the points you raised. I will summarize the points relevant to the eagle-usb-* packages: - distribution of firmwares with no source code available in debian/main has been forbidden by the second-last general resolution, but the last general resolution removed this restriction just for sarge (as long as the license allows distribution) - the GPL issue is probably a non-issue: if the copyright owner (Sagem) stated that what the binary blobs they provide is source, I think that the ftpmasters team will accept the package (the ftpmasters decide what goes in debian, not debian-legal...) - notwithstanding the disagreement of a few people here, even if post-sarge eagle-usb-data will have to be moved to non-free, there is nothing in our policy which prevents to downgrade the hard dependency to a suggestion, to be able to keep shipping the free driver in main The effect of this is that, as long as the ftpmasters team is happy with the license clarification from Sagem, you can keep eagle-usb-data too in main for sarge. > I'm really sorry I re-started a long-discussed troll again, and I'm sad > Debian won't provide support for a lot of hardware in a close future. Do not mistake the opinion of a few vocal debian-legal users with the one of all developers. Many other developers share your concern and will fight to not let this happen. Please join debian-legal and keep defending the freeness of your package. -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >Given that the entire purpose of the driver is to actually *drive a >device*, and that it can't do that at all without the firmware, then the No, apparently you do not understand how the driver, hardware and firmware interact. The driver is fully functional as is: the firmware is needed by the hardware device, not by the driver. -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >Is there a dependency relationship between the package that provides >the driver and the firmware itself? I already explained some days ago why it's good and useful to not have a strong dependency. Also, for some drivers there can be no package at all providing the firmware files. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> Firmwares do not run on the host CPU (they are /data/ for the host >> system) >Ah. You seem to be labouring under the misconception that non-program >data files aren't subject to the same rules for inclusion in main as >executable programs. That's an incorrect assumption. No, I'm not. We are not discussing distribution of firmwares. >A program that requires a non-free data file to run -- be it a firmware >blob, a graphics image, or some other beast altogether -- depends on >that file and thus belongs in contrib. Drivers do not require firmwares, hardware devices require firmwares. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> Drivers do not require firmwares, hardware devices require firmwares. >Well, actually, there are cases where the communication between firmware >and driver is tight and both need each other, i.e driver won't work with >another firmware and vice versa. This is applicable to many other programs in main too (and is not one of the criteria specified by the policy), so I can't see your point. -- ciao, Marco
Re: a legal problem with 'filters' in germany
[EMAIL PROTECTED] wrote: >A broken law in Germany prohibiting the utterance of a pair of words >does not make something non-free. If that line of logic held--"if Agreed. This is so obvious that I can't see why this should be on topic here. The only problem I can see is that some mirror operators may want to not publish this package, and from my (admittedly not very deep) understanding of the law involved this is probably not an issue. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >The point is, some drivers DO require firmwares. I'd rather say: Some But, as I explained, this is not correct: hardware devices require firmwares, not drivers. -- ciao, Marco
Re: ITP some 13 years old code with unknown license
[EMAIL PROTECTED] wrote: >Atari game, and he said its OK. Of course I tried to contact >der Mouse, but without luck. And since "Mouse" is widely used >in computing, Google didn't return something usefull. You need to know what to look for... der Mouse is well known in some circles. :-) mailto:[EMAIL PROTECTED] -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: "drivers do not require firmwares, hardware devices require firmwares". -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >The total amount of non-free software on a user's system is different if the >firmware comes pre-loaded on the device than if we have to load it from the >OS, isn't it? No. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >>>Huh? If a driver requires a firmware blob be copied from a driver CD, >> Please repeat after me: "drivers do not require firmwares, hardware >> devices require firmwares". >And the driver requires a functioning hardware device. Thus, the This is not an use of the verb "require" I'm familiar with. >loadable firmware is in the dependency tree of the software Debian >ships. I can't find which part of policy estabilishes this criteria. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> On the other hand, if it's clearly software when it's on CD then it's >> clearly software when it's on eeprom. >False. That's why we call it firmware, not just "software living on a device". Get real. Software does not change its nature depending on the media it's stored on. >It's an implementation detail of the hardware that they happen to have >shipped a microprocessor and a hardwired program. If the program had >been burned into a circuit in an FPGA, would you still call it >software? I'm not sure if a FPGA description should be considered a program. >If it's a single-use PROM, is it still software? Yes, sure. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Oh, wait, maybe you're suggesting that they had some OTHER reason for >putting those bits in rom? If that's the case, your claim that it >doesn't help our users is a bit specious. It's not obvious that this would be an improvement which benefits users. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> >Huh? If a driver requires a firmware blob be copied from a driver CD, >> Please repeat after me: "drivers do not require firmwares, hardware >> devices require firmwares". >Then, how do you explain the ipw2200 case where driver version 0.5 and >less will only work with a certain firmware and version 0.6 and more >will only work with an other firmware ? Isn't that what we could call >a requirement ? No, why? I can't see how this could be related to my argument. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
On Oct 25, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > "Marco d'Itri" <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > >>>>Huh? If a driver requires a firmware blob be copied from a driver CD, > >>> Please repeat after me: "drivers do not require firmwares, hardware > >>> devices require firmwares". > >>And the driver requires a functioning hardware device. Thus, the > > This is not an use of the verb "require" I'm familiar with. > The driver has no useful functionality without a device to drive. > What's unclear about this? It's not clear how this is related to the argument. Obviously any kind of device driver has limited practical use[1] if you do not own the hardware device, and so are programs like ICQ and AIM clients if you do not have access to the proprietary servers they connect to, but still policy does not require to keep this kind of free software out of Debian. [1] But it may be an invaluable source of code and ideas to use in other projects... -- ciao, | Marco | [8732 stX1et.crwkrc] signature.asc Description: Digital signature
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >be provided while keeping the packages in contrib), but I didn't see >anything where you argued that a package in main that requires software >not in our archive was not a violation of Policy and the Social Contract >(other than many unsupported assertions that only the hardware required >the firmware, not the driver). I obviously consider this assertion well supported and central to my point. -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >So if you don't have the firmware installed (into >/usr/lib/hotplug/firmware/something_or_other), the driver will only >print an error message and return an error code. If that is your >definition of "fully functional", then perhaps we should include all the >programs in contrib that link to non-free shared libraries in main; >after all, someone might just want to see a linker error message. :) These two cases are well different: the first driver already contains all code needed to manage the hardware device (even if it chooses to not send some commends to the device until it will be ready to process them), in the second case the program is not complete and lacks some parts. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Heck, for all I know there's a device out there where the "firmware on >disk" is verilog code, and it's compiled by the driver and loaded to >an FPGA on the device. > >Surely that's software. I'm not so sure that an FPGA design is software (for sane definitions of software). >Why draw the line at software, then? Why not wish for open specs for >all the chips, so you can modify the CPU or GPU? I do, don't you? But still this does not make it true, and I have to accept reality. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >While this is true, it is incomplete: the driver Depends, in the >policy sense, on the device, and the device Depends on the firmware. I do not think policy can justify this. >> Obviously any kind of device driver has limited practical use[1] if >> you do not own the hardware device, and so are programs like ICQ and >> AIM clients if you do not have access to the proprietary servers >> they connect to, but still policy does not require to keep this kind >> of free software out of Debian. >It's not just the proprietary server code, but the actual servers that >are necessary. That is, you need the machines running them -- >hardware, a black box outside Debian's control. So what? User's hardware is outside Debian control as well. Or you think that Debian should control user's hardware? This sounds a bit like DRM to me. >I do think that closed-system clients don't belong in Debian >(differentiating OSCAR, for example, from whatever the closed AIM >protocol of the week is -- I don't follow technical developments >there very closely.) You are entitled to your opinions however stupid they are, but they are off topic in the context of interpreting policy. >> [1] But it may be an invaluable source of code and ideas to use in other >> projects... >That source of ideas is not enough to change a Depends to a Suggests, >or we'd have nothing in contrib. I did not propose this. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote: >> >> Please repeat after me: "drivers do not require firmwares, hardware >> >> devices require firmwares". >> >Then, how do you explain the ipw2200 case where driver version 0.5 and >> >less will only work with a certain firmware and version 0.6 and more >> >will only work with an other firmware ? Isn't that what we could call >> >a requirement ? >> No, why? I can't see how this could be related to my argument. >I'm telling you some drivers *do depend* on a certain firmware. You're >still repeating the opposite. Now explain me how in ipw2200 case the >driver doesn't *depend* on the firmware, since you seem to know the >truth. You are using a different meaning of "depend" than the one used by policy. I can't see why it should matter if a device driver is designed to use features present in a specific firmware revision. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri wrote: >> >Huh? If a driver requires a firmware blob be copied from a driver CD, >> Please repeat after me: "drivers do not require firmwares, hardware >> devices require firmwares". >The driver is opening a block of data on disk, reading it and sending it >to the hardware. If that data does not exist, the driver will be >incapable of driving the hardware. For the driver to work, in addition >to installing it and the hardware device, you have to find and install >a copy of the firmware to where the driver expects to find it. No, this is not correct. If the firmware is not loaded the hardware device will not provide some features, but the driver is still capable to use them, if they were available. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >In cases where firmware is basically indistinguishable from hardware, >we treat it as hardware, and not as software. Really? Which part of policy states this? -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >Perhaps then you can provide an example of what the driver can do in a >world where all the Windows driver-CDs have vanished, and there is >only a device plaintively calling out for a firmware download in my >machine. Can the driver do anything? Uploading or not uploading the firmware does not change in any way the capabilities of the driver, only the ones of the device. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Then there's no point continuing this conversation. An FPGA design, >living as a file on disk and possibly even shipped by Debian is >clearly software under Debian's definitions. Runtime-loaded firmware I was not discussing Debian's definitions now. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> >In cases where firmware is basically indistinguishable from hardware, >> >we treat it as hardware, and not as software. >> Really? Which part of policy states this? >Historical practice. OK, thank you for confirming that this has no foundation in the policy. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >> >I'm telling you some drivers *do depend* on a certain firmware. You're >> >still repeating the opposite. Now explain me how in ipw2200 case the >> >driver doesn't *depend* on the firmware, since you seem to know the >> >truth. >> You are using a different meaning of "depend" than the one used by >> policy. I can't see why it should matter if a device driver is designed >> to use features present in a specific firmware revision. >Let's "port" this sentence into an other context. >"I can't see why it should matter if a program is designed to use >features present in a specific library revision" So? What is your point? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Yes, Marco. We all understand the model you propose, based around the >idea "all firmware is essentially hardware, even if it's clearly a >file that has to be there on disk for a driver to function". An Now it's quite clear that you did not understand at all what I have been proposing for months now, because I have never believed what you write here. (BTW, please stop sending me copies of every mail, even if you never managed to read the debian document which asks to not do this it should be obvious by now that I read this list.) -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >> These two cases are well different: the first driver already contains >> all code needed to manage the hardware device (even if it chooses to not >> send some commends to the device until it will be ready to process them), >> in the second case the program is not complete and lacks some parts. > >The driver contains code to interact with the firmware in operating the >hardware device, just as the program contains code to interact with the >library in performing its function. No, this is again wrong: a program and the libraries it use are a single entity (why do you think it's called linking?) while drivers and devices are different entities. They interact the same way IM clients and servers interact. > The driver does not contain all the >code needed to manage the device; it contains code that can interact If the quantity of code in the driver is the same before and after the firmware has been uploaded to the device then the driver obviously contain all code needed to manage the device. >with the firmware. This particular driver interacts exclusively with >the firmware, not the device (except for handing the firmware to the >device). The firmware is not part of the driver nor of any other program running on the system, so I have to conclude that it's now part of the device. -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >> No, this is again wrong: a program and the libraries it use are a single >> entity (why do you think it's called linking?) while drivers and devices >> are different entities. >> They interact the same way IM clients and servers interact. >From the point of view of userspace, a driver, device, and any >firmware on it are one abstract entity. Your point being? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote: >> >In cases where firmware is basically indistinguishable from hardware, >> >we treat it as hardware, and not as software. >> Really? Which part of policy states this? >It's very interesting how quickly people who fail badly at backing their >arguments on principle fall back to using Policy as a stick--despite the >fact that the governing document here is the Social Contract, which I should >hope still takes precedence over policy ... I explained my principles at the beginning of the discussion, and I do not feel the need to state them again because they are not relevant here: even if some people like to use it to invent new rules they think should be applied to debian, debian-legal is not the right place to update or augment the policy and social contract. I refer to policy because it's the document which explains how the SC should be applied, if it fails this job then it has bugs and you are encouraged to point them out. (I'm obviously happy to see you resorting to ad hominems as it probably means you have no more arguments.) -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Argh. Yes, but the firmware in these eeproms is something that we're >entirely logically capable of shipping. Claiming that firmware is >sometimes software (when it's on a compact flash card, say) and >sometimes hardware (when it's on an eeprom, say) is the sort of argument >that the social contract changes were meant to deal with. If it's a >string of bits encoded on something, we're meant to apply the DFSG to >it, not argue about whether it's software or not. Again, I fully agree with this. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote: >> I explained my principles at the beginning of the discussion, and I do >> not feel the need to state them again because they are not relevant here: > >How about something that is relevant, then? > >If that's not possible, maybe you don't want to post here? You too have no more arguments? -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >In the goal of seeking consistency, I think this requires mass bug >filing against packages with unmet dependencies, including: If dependencies really have to be followed outside the borders of software manages by the OS then I agree that this is the only logical consequence. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: >Does anyone know if it is possible to obtain an IDE disc drive that >contains no non-free software, I do not believe that this is possible. -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote: >> > BIOSes are in the EPROM case that I've described--part of the hardware, >> > already present--and go in main. >> How does this exception follow from either the SC, DFSG or Policy? >Hardware is not part of Debian, and the fact that Debian depends on >non-free pieces of hardware has never been considered to violate any of >the above. (And, as I've said a few times, stuff tucked away in an >EPROM acts like part of the hardware.) And every time you failed to explain why software magically is not software anymore when stored on a flash EPROM. > I acknowledge that this isn't >the only possible interpretation, but I believe it's the one that Debian >is currently acting on, I believe it follows without any stretches of No, currently drivers for devices without permanently stored firmware are accepted in main. >> I understand that position, but I do not see why the distinction >> follows from a foundation document or from policy. The "where's the >> data?" case is avoided by pointing the driver at /dev/zero. >At which point the program says "server closed connection: data is bogus", >or the hardware device tries to run null data and crashes, and they do >nothing useful. I can't see why this should matter. The driver implements a firmware loader, which is something useful in itself and is also the first element needed to develop a free firmware. All other functions of the driver are still available, but if the hardware is not willing to interact with it I can't see why this should impact the freeness of the driver. Which criteria are you applying to decide that this is not "useful" enough? >> > This is distinct from software which merely interacts with a non-free >> > server, >> > but--as far as that functionality is concerned--is complete and able to do >> > so on its own. >> >> I do not see how this is different than the firmware case. > >Please be more specific; there are at least two significant categories >of "firmware case". Software that merely interacts with a remote server, >but is able to do so on its own, is analogous to the EPROM case (drivers >which are able to make a device do useful things on their own). Software >that interacts with a remote server, and has to send a block of non-free >data to it for it to do anything, are analogous to the RAM case (hardware >that must receive a block of firmware to do anything at all). I can't see the rationale behind this. If you agree that the hardware devices are beyond the dependency barrier then I do not understand why it matters if their firmware is provided by the manufacturer on a CD or a flash EPROM. BTW, if everything is software I can't see how that non-free data used for authentication is different from a password or SSL certificate used for authentication. >I'm not sure that this disagreement is important to the comparison: a >client requiring a non-free piece of data to make use of a server is not >complete without that data, and (going back to the reason for making >this comparison) a driver requiring a non-free piece of firmware to make >use of a piece of hardware is not complete without that piece of firmware. > -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >On Thu, Oct 28, 2004 at 10:10:47PM -0400, Michael Poole wrote: >> Conflict in what way? It says "contrib" and "non-free" are for works >> that do not conform to the DFSG. Packages in "contrib" conform to the >> DFSG but depend on software that does not. If I interpret the SC's >> statement about "contrib" and "non-free" so it agrees with Policy, I >> see no conflict. Boot loaders currently in "main" conform to the DFSG >> but depend on a BIOS, and there is no free BIOS in "main." > >You can't build those boot loaders on a system which hasn't been booted. > >If those boot loaders can be in main, then everything else that's in >main can be in main. Then let's forget for a minute boot loaders. What about all drivers which interact with non-free software stored in computers and their peripherals? -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >> Then let's forget for a minute boot loaders. What about all drivers >> which interact with non-free software stored in computers and their >> peripherals? > >I think you're forgetting about more than boot loaders, since this has >been explained more than once. However, I'll try to summarize: > >If we have reason to treat that software as part or a potential part of >the debian system, then our system has a dependency on that software. > >If that software is outside the scope of our system (by virtue of there >being no logical way for our system to change that software or for that >software to replace anything within the system), then it's outside the >scope of our system. So, following from this why you think that the motherboard firmware (the BIOS, which can be reflashed by users) or the CD reader firmware (which can be reflashed as well, with the right tools) and e.g. a modem firmware are different? -- ciao, Marco
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: >On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote: >> >Hardware is not part of Debian, and the fact that Debian depends on >> >non-free pieces of hardware has never been considered to violate any of >> >the above. (And, as I've said a few times, stuff tucked away in an >> >EPROM acts like part of the hardware.) >> And every time you failed to explain why software magically is not >> software anymore when stored on a flash EPROM. >By that logic, the same piece of data stored on an involatile ROM (that >the driver can't upload at all) is also to be considered software. It's >non-free and we require it--I guess we should just give up! Yes, sure! If some stream of bits is considered software when stored in RAM then I can't see why it should not be software anymore when stored in some other media. I have not seen any convincing argument about why software should lose its nature if stored in ROM. If the conseguences of this are that some interpretations of the policy or social contract are inconsistent then maybe you should start considering that they may really be, after all. >Looks like hardware, acts like hardware. To me, it looks like software stored in hardware. >Of course, it's a boundary case--it's neither strictly hardware nor software. Really? I think it's quite clear. >That's where the word "firmware" comes from in the first place, and that's >why there's disagreement on it--for things which are unambiguously hardware >(my printer) and things which are unambiguously software (/bin/ls), we >have clear boundaries, but for things which are neither hardware nor >software and yet both at the same time, things aren't so clear. I'm sorry, but the policy revisionists forced Debian to think that there is only software and they have been very clear about this. >> I can't see why this should matter. The driver implements a firmware >> loader, which is something useful in itself and is also the first element >> needed to develop a free firmware. All other functions of the driver are >> still available, but if the hardware is not willing to interact with it >> I can't see why this should impact the freeness of the driver. >This isn't a question of whether the driver is free or not, it's a question >of whether it goes in main or contrib. Yes, this is what I was talking about. >> I can't see the rationale behind this. If you agree that the hardware >> devices are beyond the dependency barrier then I do not understand why >> it matters if their firmware is provided by the manufacturer on a CD or >> a flash EPROM. >I've already explained this. If it's on a CD, the driver depends on it >to give to the device; the driver doesn't work unless you have the CD to >get the firmware. In fact, if you don't have the CD, you might not be >able to get the firmware at all, and you won't be able to use your device >at all. The driver could upload /dev/zero as well, I don't think this is important. The firmware modifies the capabilities of the hardware device, not of the driver. I don't believe the theory about "indirect dependencies" has any foundament in the policy or the SC, or it would have to be applied to any kind of software interacting over any communication channel. >> BTW, if everything is software I can't see how that non-free data used >> for authentication is different from a password or SSL certificate used >> for authentication. >This is irrelevant. Why? -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: >On Fri, Oct 29, 2004 at 05:50:29PM +0200, Marco d'Itri wrote: >> So, following from this why you think that the motherboard firmware >> (the BIOS, which can be reflashed by users) or the CD reader firmware >> (which can be reflashed as well, with the right tools) and e.g. a >> modem firmware are different? > >You're asking why I think "can be flashed, but works just fine without >being flashed" is different from "won't work without being loaded"? > >Fundamentally, the latter case forces us to not ignore it. The equipment >won't work if we ignore the issue. So you say that non-free software is OK with you as long as you can pretend it's not there? Which part of the policy or SC justifies this theory? -- ciao, Marco
Re: Non-free package licenses and replacements
On Jan 24, Russ Allbery <[EMAIL PROTECTED]> wrote: >[mrouted] >If anyone actually cares, I may be able to get this relicensed and am >willing to at least try. I'm mildly surprised that anyone is still using >this. Two weeks ago I opened #227146 but the maintainer did not reply: The OpenBSD people managed to have stanford relicense it: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/mrouted/LICENSE OTOH DVMRP is useless in the modern Internet, so the package could just be removed from debian. So I suggest again to kill the package. Other non-free packages I know about: rar: this is needed to unpack rar 3.x archives. There is no alternative. unicorn: partially non-free ADSL modem driver. There is no alternative. mwavem: free driver, but it contains a binary firmware executed by the device CPU. If there is a consensus on the hypocrisy of refusing to distribute firwmares then I think removing the files and keeping the driver in main is the best solution. OTOH, it has been reported that the driver may be obsolete. -- ciao, | Marco | [4281 ca6C4eQ76UGbY]
Re: Font and hinting problem
[EMAIL PROTECTED] wrote: >this program use postscript program that is really short and >copyrighted by adobe. It's trivial enough that probably you do not need to worry about copyright. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pre-ITP - LARN and Noah Morgan
[EMAIL PROTECTED] wrote: >> In an email on Aug 15 2005, Kevin wrote to Alex: >> > I proceeded on the casual assumption that Noah Morgan >> > and Don Kneller would have no issues with changes >> > being made and posted. They posted to a public forum, >> > and I seem to vaguely recall that their licensing >> > permitted changes and redistribution as long as their >> > original copyright statements were preserved. I never >> > heard anything from anyone to the contrary, but that >> > doesn't mean that it was "OK". >> >> Accordingly, we believe Noah and Don's intentions met DFSG. > >The problem is that Noah's intentions are no longer relevent. The I read here that (somebody recalls that) he distributed the code with a free (even if not attached) license, so whatever his heirs want to do is not relevant. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
[EMAIL PROTECTED] wrote: >> Hope to have answered to your question. I am sorry but I did not succeed >> in asking Berkeley's Regents for a license change. >Didn't they issue a blanket license change for _all_ code owned by them >under the old bsd license? Yes. But the original spice code was not under the old BSD license. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 08, Sven Luther <[EMAIL PROTECTED]> wrote: > 2) Any argument i may have are only the lame repetition of the opinion of a > single person here on debian-legal. Indeed, the "choice of venue is a fee" argument is just that: an opinion which has at best no clear roots in the DFSG, therefore it cannot make a license non-free. -- ciao, Marco signature.asc Description: Digital signature
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 08, Sven Luther <[EMAIL PROTECTED]> wrote: > > Indeed, the "choice of venue is a fee" argument is just that: an > > opinion which has at best no clear roots in the DFSG, therefore it > > cannot make a license non-free. > Yeah, but there is certainly more than a single person arguing that we should > not distribute software with such licence. There is nothing wrong with this, and I'm not a fan of choice of venue clauses either, but they should try to modify the DFSG then. -- ciao, Marco signature.asc Description: Digital signature
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 09, Josselin Mouette <[EMAIL PROTECTED]> wrote: > > There is nothing wrong with this, and I'm not a fan of choice of venue > > clauses either, but they should try to modify the DFSG then. > Could you explain why DFSG#5 couldn't be invoked in this case? It does not work this way. If you believe that a license is not free it's up to you explaining why. -- ciao, Marco signature.asc Description: Digital signature
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 09, Josselin Mouette <[EMAIL PROTECTED]> wrote: > > It does not work this way. If you believe that a license is not free > > it's up to you explaining why. > Well, I'm explaining that it isn't free because of DFSG#5. However, it > seems that you are refusing such arguments de facto. I am refusing them as long as you cannot clearly show how DFSG#5 forbids some restrictions present in the CDDL. -- ciao, Marco signature.asc Description: Digital signature
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 10, George Danchev <[EMAIL PROTECTED]> wrote: > > Not "now". Debian (and I think every other distribution) has been > > distributing software with this kind of licenses for years, without any > > apparent ill effect on users. > Not true. Many licenses that failed to comply with DFSG [0] has not been > accepted. Many packages entered the Debian archive by incident has been > removed. Past experience shows that licenses having choice of venue has been > avoided [0][1]. You show that the same 5-6 debian-legal@ contributors do not believe that some licenses are free, but I do not see ftpmasters removing from the archive packages with a choice of venue clause in their license (I will not believe that they do not know about licenses like the MPL and QPL). > Note: I wont reply to all your redundant mails, you can find the answers in > past discussions. This is another argument popular among the DFSG-revisionists: "we already agreed about this last year, so shut up unless you can prove we are wrong" (nevermind that there is nothing to be proved, since most of their points are just opinions). -- ciao, Marco signature.asc Description: Digital signature
Re: CDDL
[EMAIL PROTECTED] wrote: >This might fail the Dissident test (and thus discriminate against Which is not part of the DFSG, so it does not matter. >[clause 3.3 goes on] >> You may not >> remove or alter any copyright, patent or trademark notices >> contained within the Covered Software, or any notices of >> licensing or any descriptive text giving attribution to any >> Contributor or the Initial Developer. > >This could open the possibility to include GFDL-style Invariant >Sections, if "descriptive text" is interpreted broadly enough. In that >case this would fail DFSG#3. I fail to see how this could happen, "descriptive text giving attribution" looks clear enough to me. >This is choice of venue and fails DFSG#5. This is not true. >> The application of the United Nations Convention on Contracts for the >> International Sale of Goods is expressly excluded. >This license claims to have the Power To Nuke Laws(TM). I do not remember any part of the DFSG which would prevent this, do you? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 09, George Danchev <[EMAIL PROTECTED]> wrote: > Debian has always been full of software licensed that way ;-) Now you want > (unintentially) to leave possible holes thru new 'a-la sco insane cases' to > enter the scene... all over the world. Not "now". Debian (and I think every other distribution) has been distributing software with this kind of licenses for years, without any apparent ill effect on users. And do not forget that there are many places (e.g. California) which allow big companies (e.g. the MPAA or Adobe) to sue there people from other states or countries (e.g. people accused to violate the DMCA) without even the need for a license... If you look at the big picture, choice of venue clauses are not much important. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sep 09, George Danchev <[EMAIL PROTECTED]> wrote: > > It does not work this way. If you believe that a license is not free > > it's up to you explaining why. > here they are: So finally we are up to the good old "every restriction is a discrimination" argument. Even if in the last two years it has become popular among some debian-legal@ contributors while the rest of the project was not looking, I believe that it is based on a misunderstanding of the meaning of DFSG #5. The purpose of this clause is to forbid licenses which provide the required freedoms only to some people (e.g. forbidding commercial use of the software), not to require that all recipients will receive the same set of rights which are not required by the DFSG. > I also think this abreaches the Debian Social Contract#4, since you expose > your > users on baseless charges of license violation for no good reasons all over > the world. Breaks "We will place their interests first in our priorities." This is not relevant. This way you could use the SC to forbid just about everything you do not like, while the SC itself and many years of practice define the DFSG as the criteria to be used to evaluate the freeness of licenses. > [1] claiming that Debian has already accepted cddl by having cddl'ed star is > weak arg because it easily could be clasified as bug. While it is obviously true that the ftpmasters are humans and therefore fallible beings, the fact that they have been accepting this kind of clauses in licenses since many years ago (QPL...) makes this interpretation unlikely. -- ciao, Marco signature.asc Description: Digital signature
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
[EMAIL PROTECTED] wrote: >This is, in my opinion, the natural and direct extension of the >explicit language that a license cannot require "royalties or other >fees" to be paid in exchange for the rights described in the In my opinion, this is not natural nor direct. Looks like we are down to opinions again... -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dissident test (was re: CDDL)
[EMAIL PROTECTED] wrote: >>Which is not part of the DFSG, so it does not matter. >The Dissident test is a test for DFSG #5, so it does matter. See: No, it is not. The "dissident test" is something which a few debian-legal@ contributors invented, but which has no grounds in the DFSG. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dissident test
[EMAIL PROTECTED] wrote: >DFSG#5 is very plain and very broad: it prohibits discrimination >against *any* person or group. If you think it should be narrowed, >propose an amendment to the SC. Until the DFSG-revisionists came here, the meaning of the DFSG #5 was to forbid licenses which provide the required freedoms only to some people. I do not consider acceptable the extended interpretation that you are proposing, and this should be obvious since it would lead to declaring the GPL to be non-free. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
