Bug#1033227: marked as done (unblock: live-tasks-non-free-firmware/12.0.1)
Your message dated Thu, 23 Mar 2023 13:03:32 +0100 with message-id and subject line Re: Bug#1033227: unblock: live-tasks-non-free-firmware/12.0.1 has caused the Debian Bug report #1033227, regarding unblock: live-tasks-non-free-firmware/12.0.1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1033227: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033227 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: live-tasks-non-free-firmw...@packages.debian.org Control: affects -1 + src:live-tasks-non-free-firmware Please unblock package live-tasks-non-free-firmware This is provides meta-packages on live systems to install non-free firmware packages on those systems. Sorry for it being so late, it depended on the firmware section itself existing and being populated. The package only provides the metapackages, for convenience, I'm including the control file below: """ Source: live-tasks-non-free-firmware Maintainer: Live Systems Maintainers Uploaders: Jonathan Carter Section: non-free-firmware/metapackages Priority: optional Build-Depends: debhelper-compat (= 13) Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/live-team/live-tasks-non-free-firmware Vcs-Git: https://salsa.debian.org/live-team/live-tasks-non-free-firmware.git Rules-Requires-Root: no Package: live-task-non-free-firmware-pc Architecture: all Recommends: amd64-microcode, bluez-firmware, firmware-amd-graphics, firmware-atheros, firmware-brcm80211, firmware-intel-sound, firmware-ipw2x00, firmware-iwlwifi, firmware-linux, firmware-linux-nonfree, firmware-realtek, firmware-sof-signed, intel-microcode Suggests: vrms Description: selection of oft-used non-free-firmware shipped on live systems Provides non-free-firmware packages for Debian live systems. . Its dependencies, along with this package itself, is safe to remove, provided that your device does not depend on them in order to function. Package: live-task-non-free-firmware-server Architecture: all Recommends: firmware-bnx2, firmware-bnx2x, firmware-cavium, firmware-myricom, firmware-netronome, firmware-netxen, firmware-qlogic Suggests: vrms Description: provides firmware for server network and storage devices Provides non-free firmware packages for Debian live systems. . This package installs firmware packages for server devices. . Its dependencies, along with this package itself, is safe to remove, provided that your device does not depend on them in order to function. """ unblock live-tasks-non-free-firmware/12.0.1 thanks, -Jonathan --- End Message --- --- Begin Message --- Hi Jonathan, On 20-03-2023 12:55, Jonathan Carter wrote: Sorry for it being so late, it depended on the firmware section itself existing and being populated. Ugh, you're late indeed. The package only provides the metapackages, ... Ack. And for that reason we'll allow it in. By the way, you may want to improve the description. You're talking about dependencies, while the binaries don't have any. They only have recommends. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Bug#1033227: unblock: live-tasks-non-free-firmware/12.0.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: live-tasks-non-free-firmw...@packages.debian.org Control: affects -1 + src:live-tasks-non-free-firmware Please unblock package live-tasks-non-free-firmware This is provides meta-packages on live systems to install non-free firmware packages on those systems. Sorry for it being so late, it depended on the firmware section itself existing and being populated. The package only provides the metapackages, for convenience, I'm including the control file below: """ Source: live-tasks-non-free-firmware Maintainer: Live Systems Maintainers Uploaders: Jonathan Carter Section: non-free-firmware/metapackages Priority: optional Build-Depends: debhelper-compat (= 13) Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/live-team/live-tasks-non-free-firmware Vcs-Git: https://salsa.debian.org/live-team/live-tasks-non-free-firmware.git Rules-Requires-Root: no Package: live-task-non-free-firmware-pc Architecture: all Recommends: amd64-microcode, bluez-firmware, firmware-amd-graphics, firmware-atheros, firmware-brcm80211, firmware-intel-sound, firmware-ipw2x00, firmware-iwlwifi, firmware-linux, firmware-linux-nonfree, firmware-realtek, firmware-sof-signed, intel-microcode Suggests: vrms Description: selection of oft-used non-free-firmware shipped on live systems Provides non-free-firmware packages for Debian live systems. . Its dependencies, along with this package itself, is safe to remove, provided that your device does not depend on them in order to function. Package: live-task-non-free-firmware-server Architecture: all Recommends: firmware-bnx2, firmware-bnx2x, firmware-cavium, firmware-myricom, firmware-netronome, firmware-netxen, firmware-qlogic Suggests: vrms Description: provides firmware for server network and storage devices Provides non-free firmware packages for Debian live systems. . This package installs firmware packages for server devices. . Its dependencies, along with this package itself, is safe to remove, provided that your device does not depend on them in order to function. """ unblock live-tasks-non-free-firmware/12.0.1 thanks, -Jonathan
Processed: unblock: live-tasks-non-free-firmware/12.0.1
Processing control commands: > affects -1 + src:live-tasks-non-free-firmware Bug #1033227 [release.debian.org] unblock: live-tasks-non-free-firmware/12.0.1 Added indication that 1033227 affects src:live-tasks-non-free-firmware -- 1033227: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033227 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#1031238: debci: fails for source packages in non-free-firmware
Control: tags -1 confirmed
On 13-02-2023 20:45, Andreas Beckmann wrote:
src:nvidia-graphics-drivers recently moved from non-free to
non-free-firmware since the firmware-nvidia-gsp binary package was moved
to that section, too.
Ack.
Tracker reports
autopkgtest for nvidia-graphics-drivers/n/a: amd64: Regression ♻ (reference
♻), ...
not sure whether the version "n/a" comes from tracker or debci.
n/a probably comes from autopkgtest (or indeed debci that interprets a
missing version that way)
Autopkgtest regresses with
https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers/31312665/log.gz
...
autopkgtest [14:12:05]: testbed dpkg architecture: amd64
autopkgtest [14:12:05]: testbed running kernel: Linux 5.10.0-21-cloud-amd64 #1
SMP Debian 5.10.162-1 (2023-01-21)
autopkgtest [14:12:06]: apt-source nvidia-graphics-drivers
blame: nvidia-graphics-drivers
badpkg: rules extract failed with exit code 1
autopkgtest [14:12:06]: ERROR: erroneous package: rules extract failed with
exit code 1
My guess is that it fails since it cannot find the source package
anywhere.
Indeed
autopkgtest [09:56:46]: apt-source
nvidia-graphics-drivers
autopkgtest: DBG: blame += nvidia-graphics-drivers
autopkgtest: DBG: testbed reset: modified=False, deps_installed=[],
deps_new=[]
autopkgtest: DBG: install_deps: deps_new=[]
autopkgtest: DBG: testbed command ['sh', '-ec', 'command -v
dpkg-source'], kind short, sout pipe, serr pipe, env []
autopkgtest: DBG: testbed command exited with code 0
autopkgtest: DBG: testbed command ['sh', '-ec', 'su --shell=/bin/sh
debci -c \'set -e; exec 3>&1 >&2; set -x; cd /; builddir=$(mktemp -d
/tmp/autopkgtest-lxc.julgi3d7/downtmp/build.XXX); cd $builddir;
OUT=$(apt-get source -d -q --only-source
nvidia-graphics-drivers/unstable 2>&1) || RC=$?;\nif [ -n "$RC" ];
then\n if echo "$OUT" | grep -q "Unable to find a source package";
then\nexit 1;\n else\nexit $RC;\n fi;\nfi;\necho "$OUT" | grep
^Get: || true;\ndpkg-source -x nvidia-graphics-drivers_*.dsc src
>/dev/null; chmod -R a+rX .; cd [a-z0-9]*/.; pwd >&3; sed -n "1
{s/).*//; s/ (/\\n/; p}" debian/changelog >&3\''], kind build, sout
pipe, serr raw, env []
+ cd /
+ mktemp -d /tmp/autopkgtest-lxc.julgi3d7/downtmp/build.XXX
+ builddir=/tmp/autopkgtest-lxc.julgi3d7/downtmp/build.3aA
+ cd /tmp/autopkgtest-lxc.julgi3d7/downtmp/build.3aA
+ apt-get source -d -q --only-source nvidia-graphics-drivers/unstable
+ OUT=Reading package lists...
E: Unable to find a source package for nvidia-graphics-drivers
+ RC=100
+ [ -n 100 ]
+ echo Reading package lists...
E: Unable to find a source package for nvidia-graphics-drivers
+ grep -q Unable to find a source package
+ exit 1
autopkgtest: DBG: testbed command exited with code 1
Adding non-free-firmware to /etc/apt/sources.list fixes that problem. In
debci, it's bin/debci-generate-apt-sources that on line 133 sets the
components, but it does so for all suites. This means we'll get
W: Skipping acquire of configured file
'non-free-firmware/source/Sources' as repository
'http://deb.debian.org/debian stable InRelease' doesn't have the
component 'non-free-firmware' (component misspelt in sources.list?)
W: Skipping acquire of configured file
'non-free-firmware/binary-amd64/Packages' as repository
'http://deb.debian.org/debian stable InRelease' doesn't have the
component 'non-free-firmware' (component misspelt in sources.list?)
in our logs on stable (bullseye) if we add it without further logic.
Just above there's already code that uses the suite, so probably we can
borrow a bit of that.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Foo2zjs-maintainer] Bug#449497: foo2zjs: getweb script depends on non-free firmware
Hi Michael! Adding the d-release mailing list to cc:. On Fri, 31 Oct 2008 13:41:25 +0100, Michael Gilbert wrote: i'll go ahead and start the discussion since no one else is running with it. this matter is rather urgent since the problem is now being considered release-critical for lenny. [...] let me again stress that action is URGENT since this is release-critical for lenny. Can you please stop dealing with this bug and let the tech-ctte [1] do their work? About the urgency and lenny: the bug is marked as serious, which means that if the tech-ctte does not fix it before lenny (something which I do not think is going to happen), the Release Team must deal with it. FYI, other people have already started to work on it, check the thread on the d-ctte mailing list [2]. Thx, bye, Gismo / Luca Footnotes: [1] http://www.debian.org/devel/tech-ctte [2] http://lists.debian.org/debian-ctte/2008/10/msg0.html pgpq3IlIbwAko.pgp Description: PGP signature
Re: foo2zjs: application depends on non-free firmware
Hi there! BTW, Joost, it seems that for the BugSprint [1] you got quite a nasty bug, sorry :-D On Sun, 26 Oct 2008 14:08:03 +0100, Steffen Joeris wrote: severity 449497 important Thanks to Steffen for the downgrade. To everyone else: please don't change the severity anymore: while it can be less than important [2], it's *anyway* not more than that. On Sun, 26 Oct 2008 11:40:34 pm Joost Yervante Damad wrote: Hi Luca, [3] not that I checked with such printers, I'm only in touch with one that needs a non-free firmware http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466758#15 So you don't think that your usage of the package is more contrib then main? No, foo2zjs as it's *in* Debian [3] is OK for main. Personally I find it a rather grey unclear situation. It seems the package can be used without any external files, yet in practice, for a lot of people it is only usable with external files.. It doesn't matter how many people needs external files to fully use foo2zjs: if only one person can use it without, then everything which is completely DFSG-free *must* be in main. Since the package is currently lives in main, I personally can live with how it is currently... the bug submitter seems to think differently though... Bottom line is, that dependant on the hardware ,the package as it lives in main is usable or NOT. This is another point, exactly like the firmware issues in the kernel: the Intel iwl3945 driver is not usable on my ThinkPad X60 [4] without the non-free firmware, yet the correct place for the driver is main. Maybe we should mark the bug lenny-ignore ;) I guess it would be up to the release team to set this tag. I added the d-release mailing list to the cc:. Anyway, I am still not convinced that it is RC. The package works fine for certain printers without any firmware. However, some need it, which is clearly stated in the README.Debian file. Furthermore, we are offering a GUI program and the upstream script to download the firmware for the user's convenience. IMHO this does not justify the move to contrib or non-free. Fully ACK. Now I am lowering the severity of the bug to important (althought I'd rather see it as wishlist). Fully ACK also for the latter. If people still disagree, please bring it to the attention of the technical committee, which can overrule my decision at any time. With my just-got foo2zjs maintainer hat on, in that case the technical committee should overrule the decision of two maintainers. Let's see what the Release Managers say. Thx, bye, Gismo / Luca Footnotes: [1] http://wiki.debian.org/BugSprint [2] important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone; this is exactly the current situation for foo2zjs [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yesbug=449497#63 [4] http://luca.pca.it/projects/ibm/x60_1706-gmg/ pgp4TX3AMnGRi.pgp Description: PGP signature
Re: foo2zjs: application depends on non-free firmware
severity 449497 serious thank you i don't see how this bug can be considered anything less than serious. as i explained in my last message, there are two potential grave problems: security and breakage. and even if neither of these problems exist now, they certainly could arise during the lenny's lifetime. in fact, we don't even know if the upstream files are fully trustworthy right now. also, someone could spoof the upstream site. there are a lot of potential problems, which is why software in main should not have external dependencies. again, if these issues can be resolved before the release, then they should -- they should not be ignored. also, i believe that by reducing the severity, you are covering up the importance of this problem -- and those like it. people in debian really need to put some thought and consideration into the clarity of the current policy on issues like this. you are putting your users at risk and reducing the reliability of the system. some have argued that this issue shouldn't be considered a problem since the majority of the package is dfsg-free. this is an incorrect interpretation. if any part of a package is non-free, then the whole package should be considered non-free until the offending component is fully removed. i am increasing the severity one more time to make sure that this bug is given appropriate consideration by the release team. it should be up to them to mark it lenny-ignore, and if that is their decision, i will not object. otherwise, i believe that the only reasonable solution (that can be completed in time for the release) is to remove getweb and add some documentation on getting getweb upstream if the user needs it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 13, 2006 at 04:01:12AM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? So you can't claim the hexdump (or binary file) is the prefered form of modification (source). Well, i never argued that, i always said that the binary-only firmwares without source, are non-DFSG-free, and should be handled accordyingly. The point is that they are not considered a derivative work of the kernel source, and thus that the presence of non-free firmware inside the kernel binary is no breakage of the kernel GPL. Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. If I just dump my hexcode of the image/sound to my black box (qiv or xmms for example) for (dis)playing then I only transport the file. If I (dis)play it myself then it isn't an aggregation. Intresting. If the image is integral part of your program, it being non-free breaks the GPL of your program, independently of it being included in the same binary or not. displaying some random image doesn't count as 'being integral part of the program'. Or does the black box have to be hardware? nope, the same applies in all case, but i wish you would not mix the problems and provide false argumentation for the case we agree with, in order to disproof a totally different issue. aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. I can imagine a tool that rewrites non-free parts of a binary as free software from scratch without breaking any laws about reverse engeneering too. Does that mean they exist or are even possible? no. Well, what is a bios apart from a tool which runs at system startup and initialises the peripheral procesors in a state which will allow later programs to use it ? I do bios/firmware writing for a living, and plan to embedd exactly such non-free firmware into the flash firmware of my board, to power onboard devices that need them. So, again, what was your argumentation here ? Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. That requires changes in the source. Exactly those changes is what I say must happen. Indeed. and i *NEVER* said that they should not happen, i *NEVER said that this was the point we are discussing, i actually *AGREE* with you there. This is a fully orthogonal issue to the aggregate work status of the firmwares in question with regard to the kernel. So, now that we agreed that those modules need to go into non-free, but that provided their licence is clear enough, like in the tg3 case, they are indeed distriutable in non-free, let's go back to the initial point. This is upstream work, and work which is slowly happening upstream, but will never be ready in time for the etch release. The kernel team has not the ressources to do all that work in a timely fashion for the stated etch release, and delaying until it is ready may mean at least a year of delay for the etch release, which is unacceptable for many. So, if you are really concerned about this issue, start coding, we await your patches impatiently, and will even help you bring them upstream, so they may be integrated in the current debian kernels accordying to our current policy. The firmware loading kernel infrastructure marks a clear lines where an external blob of firmware gets loaded that isn't part of the kernel binary itself. Well, i would say that a single variable symbol is as much of a clean boundary. The firmware loading infrastructure assuredly cannot contain less information than
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: So, now that we agreed that those modules need to go into non-free, but that provided their licence is clear enough, like in the tg3 case, they are indeed distriutable in non-free, let's go back to the initial point. This is upstream work, and work which is slowly happening upstream, but will never be ready in time for the etch release. The kernel team has not the ressources to do all that work in a timely fashion for the stated etch release, and delaying until it is ready may mean at least a year of delay for the etch release, which is unacceptable for many. Upstream is not doing it and Debian has written it on their flag (DFSG and SC) to get it done. That means Debian has to do it. If that means etch will be delayed a year then etch will be delayed one year. THAT fact was the begining of the thread. Showing that the kernel is not ready to be frozen in accordance to the timeline because the firmware is still not removed. If you can't live with that delay then please start a GR to get an exemption like sarge had. I don't think there has to be more arguing about it anymore. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Daniel Dickinson [EMAIL PROTECTED] writes: On Sun, 06 Aug 2006 23:52:01 +0200 Goswin von Brederlow [EMAIL PROTECTED] wrote: They have always been a problem and have always violated the license of the rest of the kernel. It is just that nobody noticed or cared before but now the cat is out of the sack and the issue is a release blocker. Sometimes ignorance is bliss. But now we have seen the (ugly) light. I think there are two separate issues; one is whether debian can distribute the blobls and the other of whether distribution violates the social contract. For the first part, since most of blobs are probably extracted from non-free windows drivers, there probably is no vendor-stated permission to distributed the blobs, which could become the source of lawsuits if some company felt it was worth the bad PR (think SCO only with a legal foot to stand on). If permission is given to distribute the blobs unmodified (i.e. read from disk, upload to device), then the question is about the social contract. Personally I think firmware blobs shouln't be covered, because the reasons free software is important don't apply. As long as you have the hardware for which the blob was written (and the other hardware the device is compatible with), the firmware will work. It's a black box, that happens to be loaded on initialization instead in an ROM (AIUI). Both issues can require the removal of the blob from the kernel image. The difference then only is if it goes to non-free or disapears completly. I hope nobody disagrees that blobs that can not be distributed must be removed no matter how inconvenient it is. There can be no excuse to break the law given that much forwarning since sarge. As for the ones that are distributable but not 100% free I still think a proper SC conform handling should be applied and they should move to non-free. I also, maybe even more strongly, think that they should still be included in the (or one flavour of) install images. Debian provides non-free for the convenience of users where no free alternatives exists. Firmware blobs fit perfectly there. MfG Goswin PS: There is also the issue of comercial use of those blobs. Can I comercialy distribute CDs with those blobs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? So you can't claim the hexdump (or binary file) is the prefered form of modification (source). Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. If I just dump my hexcode of the image/sound to my black box (qiv or xmms for example) for (dis)playing then I only transport the file. If I (dis)play it myself then it isn't an aggregation. Intresting. Or does the black box have to be hardware? aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. I can imagine a tool that rewrites non-free parts of a binary as free software from scratch without breaking any laws about reverse engeneering too. Does that mean they exist or are even possible? no. Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. That requires changes in the source. Exactly those changes is what I say must happen. The firmware loading kernel infrastructure marks a clear lines where an external blob of firmware gets loaded that isn't part of the kernel binary itself. Err, is not this latest one what you are suggesting we do ? So, if i understood you well, your own argumentation is hitting you back there, and this is usually proof that there is something terribly wrong in your argumentation to start with. No. You just argumented my point. The source changes to seperate the firmware and to use the firmware loading kernel infrastructure makes a difference imho. Also notice that with the firmware loading kernel infrastructure you can just delete the firmware file and the loader will give a simple error. Good luck trying to remove the char *firmware from a kernel image and not have it crash. Best you can do there is fill it with dummy data. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. Indeed, and this was done for tg3/broadcom, and the qlsomething ones. Those files are now correctly licenced, but are still non-free, and it is this second issue that we are discussing here. And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support I would propose something even more advanced, and not put the kernel .udebs into the main debian-installer thing, but into a separate section. The way i envision this, we would create a debian/sid/main|non-free/kernel section, where the kernel .udebs would be hold, and we start building them from the main kernel package. Ideally, we would go a step further, and have debian/sid/main|non-free/kernel/flavour sections, so we can split the kernel .udeb packages in a finer grain, and each running installer will only be seeing the modules corresponding to the kernel flavour he is running. This was my proposal from the start, and if you think down to it, it is the best solution for all the kernel/d-i related problems, and would allow to complete the work started with the common packaging, into a solution where there will be only a single package build, easily doable on the usual buildd network, will allow the most flexible solution for abi bumps and security upgrades. But then, i was not able to complete these ideas, due to my mothers illness and death, and the inexcusable behaviour of the d-i folk, frans at the foremost of them. They prefer to keep the status quo, and do lot of work, and complain about abi changes, as well as being able to blame the lazy porters (direct quotation of joey hess) for any problem. This is the thing which led me in clash with them. They perfectly knew about various d-i brokeness in the buildd, chose not to say anything to the porters, and because i was not attent enough to the issue to notice immediately, because i was at my mothers ill-bed, they chose to bash me and subsequently kick me out. This is the worse behaviour that i have seen from any DD so far, even jonathan and even Andrew had more decent behaviour than this, and the worse of this is that none of the others involved, not evben the DPL, have found anything wrong with this behaviour, or at least dared to say something about it, in fear to that frans would be pissed and leave, and they would miss the work he has been doing on d-i. So, you see, if i am angry and hurt, and you dislike me repeating it always, you know who to blame. You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. I will only go this way so far, but someday, i will fork d-i, and declare them obsolet, and do my stuff as i see fit, and let them the hurdle to catch up if they like. Friendly, Sven Luther Luckily Debian is about free software so you can do that. But please just do and not repeat the story and fork thread over and over. Even I get sick of it and I liked you when we happened to meet in person. Yeah, but notice that if the d-i team had not chosen to kick me out while i was hurt and crying for the death of my mother, none of this would be happening, and we would all code happily thereafter. I asked the DPL to mediate this, but the only conclusion was that i should fork, which is not satisfactory. It has been going on since april, and the more i came to think of it, the more i feel that their behaviour (Frans, joeyh, but also those others who approved or at least didn't contradict them), was the worse that any DD ever did, even worse thanb Andrew asking we don't offer our condoleances to Jens wife, and that was already very grob. So, if you like to be around with people with total lack of human decency, then you should accept when they are criticized for it. Friendly, Sven
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Goswin von Brederlow [EMAIL PROTECTED] writes: Is it an aggregation with the image linked into the binary? It doesn't matter for Debian's purposes. While the GPL permits shipping a GPL'd program merely aggregated alongside a non-free program, we don't ship the nonfree part no matter what, so it hardly matters to us whether it's also a GPL violation. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. That still leaves the symbol for the variable holding the char array and its size. The code copying the data references that variable and size. I didn't say the code is called. Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. Is it an aggregation with the image linked into the binary? aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. That still leaves the symbol for the variable holding the char array and its size. The code copying the data references that variable and size. I didn't say the code is called. Yeah, thanks very much. I suggest you go over to the FSF site, and read the GPL faq, and then come back and discuss this again. I did so during that discussion last year, and as said, that argumentation convinced the broadcom legal department, and even the FSF had nothing to say against it. A quick clue to help your search, the important parts are the one about the 'significant interface' or something such, and i seriously doubt that having a single variable referencing the non-free stuff is enough for that. Or else, consider this in a different way. On your computer disk, you have a bunch of binary files, those are called partitions, and hold data in a filesystem format. If you have any part of a GPLed binary on that filesystem, which is referenced by an inode or similar, and a non-free work (and you have probably bunch of unlicenced non-free stuff, like this email for example), referenced by another inode, then this doesn't make this email a derivative work of the linux kernel. Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. Err, is not this latest one what you are suggesting we do ? So, if i understood you well, your own argumentation is hitting you back there, and this is usually proof that there is something terribly wrong in your argumentation to start with. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. Indeed, and this was done for tg3/broadcom, and the qlsomething ones. Those files are now correctly licenced, but are still non-free, and it is this second issue that we are discussing here. And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. I will only go this way so far, but someday, i will fork d-i, and declare them obsolet, and do my stuff as i see fit, and let them the hurdle to catch up if they like. Friendly, Sven Luther Luckily Debian is about free software so you can do that. But please just do and not repeat the story and fork thread over and over. Even I get sick of it and I liked you when we happened to meet in person. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 05, 2006 at 11:29:44PM -0400, Nathanael Nerode wrote: I apologize for responding to Marco's post; in retrospect he was clearly trolling and I should not have responded to him. The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Is there a plan for dealing with this fast enough to avoid delaying the release of etch? If so, please post it. Well, there is no way i see that we can deal with this in a timely fashion without delaying etch by a year or so. Remember that d-i and kernel freeze date was planned last week. Furthermore, there is no evidence that future upstream version of the kernel will not add more such non-free firmware, so this would be an ongoing process, and we also have to keep in sync with the upstream efforts to do so. As thus, i think the more reasonable way to handle this, is to not force this to be solved for etch, but let etch be released as is (needs a GR though, but not a 3:1 one), while at the same time start a coordinated process to solve the issue, which would probably be something akin to a never ending work, until upstream uses the no-non-free-firmware policy also. skipped nice plan to file bugs So, the real solution to this would be to setup a, maybe separate, team of folk working on the non-free firmware issue, and proposing patches, patches which have a chance to be merged upstream, to solve this issue. This could overlap with the kernel team, or not, but the patches need to be approved by the kernel team, and forwarded upstream. The kernel team as is should continue focusing on packaging issues and normal maintenance. Now, on how to go forward with this issue, i think the most reasonable way would be for someone caring about the issue (you ?) to take ownership of the wiki page (maybe saving the current content in another page), and start with an exhaustive list, as well as analysis of each individual case. This would be preferable to a bug filing tactic, which would just be lost in the huge load of kernel bug reports anyway, and be more constructive. Maybe open a single bug pointing to said wiki page or something. Once that is done, the real work can start. Notice that the situation has clearly improved upstream with relation to the patches you sent a couple of year back, and which apparently somehow broke the drivers, so now would be a good time to restart that effort. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Nathanael Nerode wrote: [snip] http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. KernelFirmwareLicensing is supposed to track information about mis-licensed firmware. IIRC you mentioned to have found at least one such driver in the Debian kernel, if that's correct, please update the wiki with that information. Please don't use KernelFirmwareLicensing for correctly licensed firmware. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. You can split a page in several ones, probably per driver directory. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: And even for an aggregation of works the DFSG holds and you are still in trouble. Sure, the DFSG says that we need the source code for those, and they are thus non-free, but what i am arguing is that they are not violation of the kernel GPL, since they are separate aggregate works. As part of the source files they are seperate works. When you compile and LINK them all together they become one work. Just like when you link in non GPL static (or even dynamic) libraries. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. Let me make another example. You buy a random bunch of hardware, and either run linux on it, or run a free linux driver running it. This hardware in question happens to have some random bios on it, which is non-free, or some fpga config file hidden in a flash. This is exactly the same case as the one you are describing, with the sole exception of the firmware in question being temporarily transported in the kernel binary and uploaded in the device. No, to get the same case you have to read out the bios/flash and include that in Debian to be distributed by debian in main. If you do that the hardware vendor would sue you in a minute for copyright infringement because you don't even have distribution rights. Finally, what you mention is more akin to the unicorn driver, which is a driver for a soft-ADSL pci modem, which links to a non-free, binary-only, x86-only ADSL library. This is indeed more than just agregation, and after i engaged bewan over it, and we consulted with RMS and the FSF, they released their drivers with a GPL+exception licence, and the package is now happily sitting in non-free, waiting for someone to write a free ADSL library replacement. Indeed. That was one of the bad examples. The non-free library never runs in the same address space as the rest of the program. Does that mean this is just an aggregation of works and GPL compliant? I am not familiar enough with how library are run, but there is some very different way in which libraries called by programs work, and the way the main cpu interacts with a peripheral processor on a pci card, don't you think ? Or do you want also to declare that you can run GPLed Linux kernels only on hardware whose VHDL of every chip on it as well as schematics and gerbers are freely available, not counting that you would also need free PCB design tools which can read the format, as well as free tools running the manufacturing plant, and so on ... _IF_ Debian would distribute the CPU in main then zes, I would require that. But Debian is not a hardware vendor. Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. I've been bugging Bastian about this issue as well since I need this for multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. Ah, nice, i would really be interested in that. Now, the problem is that it needs to be integrated into the main d-i work, and given their over-conservativeness and immobilism, it is way too late for etch, or didn't you hear that d-i was supposed to be frozen this week ? Please stop making this into an attack. Better spend that energy into writing a patch. You've done D-I work before so maybe you even looked at libd-i source before. Nope, i keep pointing out the responsabilities of the current mess to where it belongs. I don't care about the d-i guys, the DPL clearly said i should expect nothing of them (well, of a few of them), and fork d-i, so ... But finger pointing will get no work done. Just annoy people. If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Maybe, but without me stepping up, and pointing the finger to this problem, nobody would have cared, probably they would have been afraid to suffer the same treatement i got at their hands for daring mention those problems. You are not stepping up. So far you are just pointing fingers. And so far I haven't seen anybody care that didn't care already. I care and I'm not afraid to suffer your treatment because I always got the treatment that I deserve from the D-I team and to some extend
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: And even for an aggregation of works the DFSG holds and you are still in trouble. Sure, the DFSG says that we need the source code for those, and they are thus non-free, but what i am arguing is that they are not violation of the kernel GPL, since they are separate aggregate works. As part of the source files they are seperate works. When you compile and LINK them all together they become one work. Just like when you link in non GPL static (or even dynamic) libraries. Please read last years discussion on debian-legal where this was exposed in detail, and a consensus was found which i reflect in my position here. Think of the case of a windows compression program which produce binaries with builtin uncompressor binaries. What you claim is that using those (winzip and co) to compress the linux kernel source would break the GPL, because they are physically housed in the same binary. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. Let me make another example. You buy a random bunch of hardware, and either run linux on it, or run a free linux driver running it. This hardware in question happens to have some random bios on it, which is non-free, or some fpga config file hidden in a flash. This is exactly the same case as the one you are describing, with the sole exception of the firmware in question being temporarily transported in the kernel binary and uploaded in the device. No, to get the same case you have to read out the bios/flash and include that in Debian to be distributed by debian in main. If you do that the hardware vendor would sue you in a minute for copyright infringement because you don't even have distribution rights. Notice that i am not arguing that the firmware is not non-free and doesn't break the DSFG, but that the firmware is not a derived work of the linux kernel, just aggregated on the same distribution media (the linux binary file), i think you are seriously confusing the two in your above argumentation. The first makes the firmware unfit to be in main, while the second is a GPL violation of the kernel source, and forbids all distribution of it. Finally, what you mention is more akin to the unicorn driver, which is a driver for a soft-ADSL pci modem, which links to a non-free, binary-only, x86-only ADSL library. This is indeed more than just agregation, and after i engaged bewan over it, and we consulted with RMS and the FSF, they released their drivers with a GPL+exception licence, and the package is now happily sitting in non-free, waiting for someone to write a free ADSL library replacement. Indeed. That was one of the bad examples. Indeed. It is non-free, and the problematicness of the licencing has been solved. It is an out-of-tree module though, so not something to worry about in this case. The non-free library never runs in the same address space as the rest of the program. Does that mean this is just an aggregation of works and GPL compliant? I am not familiar enough with how library are run, but there is some very different way in which libraries called by programs work, and the way the main cpu interacts with a peripheral processor on a pci card, don't you think ? Or do you want also to declare that you can run GPLed Linux kernels only on hardware whose VHDL of every chip on it as well as schematics and gerbers are freely available, not counting that you would also need free PCB design tools which can read the format, as well as free tools running the manufacturing plant, and so on ... _IF_ Debian would distribute the CPU in main then zes, I would require that. But Debian is not a hardware vendor. Ah, again you are confused. We are not discussing the DFSG-freeness, but the violation of the GPL of the kernel here. Two totally separate matters, please read the debian-legal argumentation of last year about this issue in order to clarify your comprehension of this issue. Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: I am not familiar enough with how library are run, but there is some very different way in which libraries called by programs work, and the way the main cpu interacts with a peripheral processor on a pci card, don't you think ? Or do you want also to declare that you can run GPLed Linux kernels only on hardware whose VHDL of every chip on it as well as schematics and gerbers are freely available, not counting that you would also need free PCB design tools which can read the format, as well as free tools running the manufacturing plant, and so on ... _IF_ Debian would distribute the CPU in main then zes, I would require that. But Debian is not a hardware vendor. Ah, again you are confused. We are not discussing the DFSG-freeness, but the violation of the GPL of the kernel here. Two totally separate matters, please read the debian-legal argumentation of last year about this issue in order to clarify your comprehension of this issue. You misread me. Debian is NOT distributing hardware. Therefore any license of software included with the hardware is totaly irelevant to Debian. If you want to buy only free hardware that is your problem and we are all sorry that you won't be able to so. But it is not a problem with the SC or DFSG that you can't. Hardware is also not included in any GPL software including the linux kernel. Your hardware is not free argument is totaly besides the issue. That is what I ment. Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. Ah, nice, i would really be interested in that. Now, the problem is that it needs to be integrated into the main d-i work, and given their over-conservativeness and immobilism, it is way too late for etch, or didn't you hear that d-i was supposed to be frozen this week ? Please stop making this into an attack. Better spend that energy into Why ? i am only stating facts, and they banned me of the d-i team for daring toeven mention some of the d-i fallacies like this one. They are not facts but your opinion. What you call over-conservativeness and immobilism others call carefullness and stability. You might even be right but you are not helping the issue nor yourself. We all know by now that you were kicked out, you don't have to repeat it. When you take the firmware out of the hardware and into debian / the kernel then it can become an issue, not before. writing a patch. You've done D-I work before so maybe you even looked at libd-i source before. I do have, but that is beside the point. Nope, i keep pointing out the responsabilities of the current mess to where it belongs. I don't care about the d-i guys, the DPL clearly said i should expect nothing of them (well, of a few of them), and fork d-i, so ... But finger pointing will get no work done. Just annoy people. It will not allow anyone to forget the issue and believe that everything is fine, indeed. So you will keep the (rightious or wrongfull doesn't matter) hate against you alive and bruning brightly. Do you believe that will help your cause? (and no, don't answere that) If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Maybe, but without me stepping up, and pointing the finger to this problem, nobody would have cared, probably they would have been afraid to suffer the same treatement i got at their hands for daring mention those problems. You are not stepping up. So far you are just pointing fingers. And so far I haven't seen anybody care that didn't care already. I am forbidden to do kernel/d-i related work by Frans who threatened me on irc about it. You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. Indeed, and this was done for tg3/broadcom, and the qlsomething ones. Those files are now correctly licenced, but are still non-free, and it is this second issue that we are discussing here. multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. Ah, nice, i would really be interested in that. Now, the problem is that it needs to be integrated into the main d-i work, and given their over-conservativeness and immobilism, it is way too late for etch, or didn't you hear that d-i was supposed to be frozen this week ? Please stop making this into an attack. Better spend that energy into Why ? i am only stating facts, and they banned me of the d-i team for daring toeven mention some of the d-i fallacies like this one. They are not facts but your opinion. What you call over-conservativeness and immobilism others call carefullness and stability. You might even be right but you are not helping the issue nor yourself. We all know by now that you were kicked out, you don't have to repeat it. Indeed, so everyone can conveniently forget it, right. When you take the firmware out of the hardware and into debian / the kernel then it can become an issue, not before. There are two issues, and you are confusing both of them and using arguments for the one in defense of the other. writing a patch. You've done D-I work before so maybe you even looked at libd-i source before. I do have, but that is beside the point. Nope, i keep pointing out the responsabilities of the current mess to where it belongs. I don't care about the d-i guys, the DPL clearly said i should expect nothing of them (well, of a few of them), and fork d-i, so ... But finger pointing will get no work done. Just annoy people. It will not allow anyone to forget the issue and believe that everything is fine, indeed. So you will keep the (rightious or wrongfull doesn't matter) hate against you alive and bruning brightly. Do you believe that will help your cause? (and no, don't answere that) Nothing will help my cause. And seriously, i couldn't care less about people who hate me because i wrote a couple of mails, and then indulge in exactly the same thing later on. If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Maybe, but without me stepping up, and pointing the finger to this problem, nobody would have cared, probably they would have been afraid to suffer the same treatement i got at their hands for daring mention those problems. You are not stepping up. So far you are just pointing fingers. And so far I haven't seen anybody care that didn't care already. I am forbidden to do kernel/d-i related work by Frans who threatened me on irc about it. You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. I will only go this way so far, but someday, i will fork d-i, and declare them obsolet, and do my stuff as i see fit, and let them the hurdle to catch up if they like. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Russ Allbery [EMAIL PROTECTED] writes: Please don't lose track of the fact that there's nothing inherently wrong with a sourceless binary if that's all the source anyone *has*. I think in most of the cases under consideration, we have firmware which a hardware manufacturer wrote and then either published or stuck inside a windows driver, and which then found its way into a Linux driver. So while your statement is right, the relevant anyone includes the hardware manufacturer, who quite likely does have source in a more convenient form than a pure binary. If the assembly was painstakingly reverse-engineered, it *is* the source for all intents and purposes [...] Quite right, but assembly code is *not* binary. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 04:49:33PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. Well, its a different sort of screwing. But then my position on this has always been to be clear, and say things plainly as they are, and not like others or other distribs or upstream to ignore the issue and hope it does go away. At this point we have those possible choices : 1) move the kernel to non-free, and be done with it. 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. 3) reverse-engineer and reimplement those firmwares, or convince upstream to free them. 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. 2) (and 1) also mean the cooperation of the d-i team, which we have not been getting on this so far, all to the contrary, since they need to fix d-i to load more than one apt source, and since the d-i folk probably consider the etch d-i as frozen right now, ... So, this leaves us what, as reasonable solution for etch ? 1 and 4, and 1 will be too disruptive, so only 4 is left. It is not as if the issue is new though, we have been knowing about this since almost a year, and many voiced their concern or support at various time, but actual help was few and far between (partly our fault in one case though at least). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. This is certainly the last resort, in my opinion, but it isn't crippled. Merely not supporting particular pieces of hardware, in a world in which Linux *already* fails to support lots of popular hardware, is not a disaster. It's a shame, and we should avoid it if we can, but it's a shame. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. Life is rough. The kernel team has had *ample* warning, since it was midway through *sarge* that the rules became clear. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:57:36AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. This is certainly the last resort, in my opinion, but it isn't crippled. Merely not supporting particular pieces of hardware, in a world in which Linux *already* fails to support lots of popular hardware, is not a disaster. It's a shame, and we should avoid it if we can, but it's a shame. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. Life is rough. The kernel team has had *ample* warning, since it was midway through *sarge* that the rules became clear. Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. Now, this is a long term *UPSTREAM* kind of work, and we simply don't have the ressources of undertaking it. As for me, i have been bogged down into defending against the multiple tentatives to get ride of me since early marsh, and could thus produce no useful work of this nature during this time, Andres Salomon left because his tentative of exclusion of me from debian failed, others have been assortedly busy too. And it is not as if *YOU* had not ample warning about the ressource problems, since we mentioned the lack of manpower and ressources regularly since a almost as long as the issue surfaced. And this is not really a work which can be done without diverting ressources from normal maintenance work, which would be detrimental. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? Well, again, the offer is open, and i already multiple times proposed those like you to start helping and providing an exhaustive list of those files which are involved, as well as a basic classification of the nature of their problem. This is assuredly within the reach of each debian maintainer or associated, and doesn't need any particular kernel-coding skill, but some legal/licencing knowledge. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. However, what started this thread IIRC was a complaint that the kernel team was *closing* the relevant bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 02:01:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. It was discussed *before* sarge was released that there was non-free firmware in the kernel, and we decided to ignore it for the sarge release. We explicitly did *not* decide to ignore it forever. Maybe, but the kernel team was really operational, and not saddled with broken legacy packaging only after the sarge release. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? No. I would be content with a we don't support that hardware decision, though it would be less than the best thing. I'm willing to wait for this work to be finished before etch is released. Yep, but the question is, are the rest of the DDs willing to wait too ? This is best answered by a GR, not sure if it needs 3:1 supermajority or not, i think if it is only a delay-it-once-more, it does not need that, contrary to a changing of the wording of the social contract would be. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Scores in that thread: who how many -- A. Spragg 1 A. Thornton1 B. Gerardo 1 D. Dickinson 1 F. Schueler1 G. Danchev 1 G. von Brederlow 4 J. Smedegaard 2 J. Neal1 M. d'Itri 10 M. Hommey 1 N. Nerode 2 (deserve a bonus as the thread launcher) R. Johnson 2 S. Luther 16 T. Seufer 1 T. Bushnell 15 == Grand total 60 Special mention to the 3 that did (more than) 66% of the noise. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpk9zXSdsxIi.pgp Description: PGP signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Hallo, On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote: We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. then, please, send patches. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On 08/02/06 22:17, Nathanael Nerode wrote: Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's under a BSD license, but it's not free software, because there's no source code. There is no source code, because there never was any source code. What do you think should be done if source code doesn't make sense or can't be made? Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
I apologize for responding to Marco's post; in retrospect he was clearly trolling and I should not have responded to him. The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Is there a plan for dealing with this fast enough to avoid delaying the release of etch? If so, please post it. If not, I suggest the following process improvements: For each driver containing a sourceless binary, someone (probably me) will file a single bug against the source package linux-2.6. Currently there is a single bug (242866/243022) covering multiple issues, against 'kernel', which is a pseudo-package. Looking at the list of antique bugs against 'kernel', I don't think anyone is reading them. Also, with the planned removal of pre-2.6 kernel packages, a bug against linux-2.6 seems sufficient to cover everything. Why one bug per driver? Because each driver's bug is slightly different and I expect each to be fixed in a slightly different way. Some bugs are distributability issues, while some are clearly distributable and simply non-free. Some may be fixed by a new upstream version. Some may be fixed by implementing firmware loading and a non-free firmware package; some may be fixed by moving the driver to an out-of-tree kernel module; others may be fixed by removing the driver entirely; others (where the firmware is unimportant) may be fixed by removing the firmware and the support for whatever feature it enables. In the case of the DRM modules, the result may depend on the implementation of features in X, and bugs may block on that. The point is that each case is going to be different. The progress on the different drivers is already different. This should make tracking the issues significantly clearer: specifically it will make it clear exactly what needs to be done to fix this. It would also make it look a bit less like an infinite tentacled monster, perhaps making it easier for people to bite off one bug at a time. (Certainly I get confused posting fixes for different drivers to the same bug.) We would then convert 242866 to a meta-bug blocking on each individual bug. How does that sound? http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. I prefer the BTS option because it's more permanent, harder to ignore, and better at holding patches and whatnot. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 07:39:21AM +0200, Mike Hommey wrote: On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Where do you read we allow ourselves to distribute non-free software for user convenience ? Well, it reads to me that we won't screw our users without second thought like some here are proposing. But then, i repeat, everyone is very welcome to participate in solving this the nice way, and i am highly impatient to see the extensive listings you and others may produce, and then some plan on how to go forward from there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Yes. There is the option of simply not supporting installation on the devices in question. i.e. screwing our users. Why do you think people use debian? It's not the most up to date distro or the most stable (damn close though). Historically it's been the most free however. I use debian because I see free software as ethical software. From my POV, putting non-free modules into the kernel without labeling them as such is not unlike putting pork in a kosher sausage. It's a betrayal of trust. I'm afraid you'd be screwing your users either way. IMHO you should stick to what makes debian unique, the uncompromising commitment to only distributing under open licenses. Users who find their hardware unsupported can go elsewhere. Open source zealots who want their software pure have debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 8, 2006, at 4:04 AM, Joseph Neal wrote: Why do you think people use debian? It's not the most up to date distro or the most stable (damn close though). Historically it's been the most free however. Hunh. What's more stable? Although I admire the Social Contract a great deal, and I very much like Debian's policy on free software, that's *not* primarily why I use it. I use it mostly for the following reasons, in no particular order: * Variety of packages. If I want something, Debian probably has it, or at least something that will do the job I have in mind. * Much, *much* better package management systems than SuSE/Red Hat * Packages that don't pull in everything-and-the-kitchen-sink as dependencies (SuSE, I'm lookin' at you) * Ability to do a *small* installation--I work largely with Debian on S/390 systems; usually there are a LOT of these running on a single piece of hardware under z/VM, and I want to keep the footprints of the individual guests small. SuSE won't even install on the S/390 without 256M RAM and 4.5 GB disk, I think. I can run a useful Debian guest in 24M/400M, and a single-purpose one with less than 200MB of disk space. * Ability to install the system without a graphical interface. I'm working from rural Canada over a satellite link; OK throughput but AWFUL latency. SuSE pretty much requires you to use VNC to install Linux/390; that's immensely more painful than an ssh + ncurses interface when you have 600ms minimum latency. * And--and this one *does* touch on its being free software--you don't have to pay to play. SuSE and RH do let you get their S/390 distros for free, but in order to apply service you need a support contract to get to the sites that host the service packs[*]. The support contracts, while reasonable for mainframe software, are pretty painful if you're a mainframe user who doesn't necessarily care about using Linux as such, but who wants services that it's easier to provide with Linux. That's really the market I'm targeting with my Debian appliances--we give away prepackaged Debian virtual machines (for use under z/VM on s390) which generally provide one service, and that you can install more or less as a black box with little prior knowledge of Linux. I can get a stable platform--with frequent security updates--to use as my baseline when developing these things, and then we can sell support for these single-function appliances for very cheap compared to what you'd pay RH or SuSE for Linux support. I use debian because I see free software as ethical software. From my POV, putting non-free modules into the kernel without labeling them as such is not unlike putting pork in a kosher sausage. It's a betrayal of trust. I'm afraid you'd be screwing your users either way. IMHO you should stick to what makes debian unique, the uncompromising commitment to only distributing under open licenses. Users who find their hardware unsupported can go elsewhere. Open source zealots who want their software pure have debian. I don't consider myself an Open Source Zealot. Purity doesn't interest me a lot. On the other hand, being confident that I *can* redistribute whatever tools I installed via apt from main to make my appliance work, that's a very nice feature. My position on non-free firmware is that distributing it certainly seems, to my untrained eye, to violate the Social Contract, and this needs to be addressed somehow, whether by dropping support for those devices, amending the Contract, or seeking a temporary waiver (or something else I haven't seen proposed or thought of). I *don't* think it's a good idea to just ignore it and hope no one notices there's a problem. And I don't have enough knowledge of the issues to clearly favor one alternative over the others. Adam [*] Presumably, once the GPL or other Free-Software-Licensed stuff was factored out and identified, other people could make it available, but no one actually does. Probably because if you care enough about running Linux on a mainframe that you want a vendor- supported Linux environment (my company, among others, will sell you support for Debian, but of course this doesn't come from the vendor), the support costs do not seem particularly onerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Adam Thornton [EMAIL PROTECTED] writes: My position on non-free firmware is that distributing it certainly seems, to my untrained eye, to violate the Social Contract, and this needs to be addressed somehow, whether by dropping support for those devices, amending the Contract, or seeking a temporary waiver (or something else I haven't seen proposed or thought of). Actually, we already did have a temporary waiver, to permit sarge to release. There has been plenty of warning here. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 06 Aug 2006 23:52:01 +0200 Goswin von Brederlow [EMAIL PROTECTED] wrote: They have always been a problem and have always violated the license of the rest of the kernel. It is just that nobody noticed or cared before but now the cat is out of the sack and the issue is a release blocker. Sometimes ignorance is bliss. But now we have seen the (ugly) light. I think there are two separate issues; one is whether debian can distribute the blobls and the other of whether distribution violates the social contract. For the first part, since most of blobs are probably extracted from non-free windows drivers, there probably is no vendor-stated permission to distributed the blobs, which could become the source of lawsuits if some company felt it was worth the bad PR (think SCO only with a legal foot to stand on). If permission is given to distribute the blobs unmodified (i.e. read from disk, upload to device), then the question is about the social contract. Personally I think firmware blobs shouln't be covered, because the reasons free software is important don't apply. As long as you have the hardware for which the blob was written (and the other hardware the device is compatible with), the firmware will work. It's a black box, that happens to be loaded on initialization instead in an ROM (AIUI). - -- GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2TIMhvWBpdQuHxwRAg59AJ4r1EHRDM3s9p5z8tEEX0Q1qbVF7gCcDOeh 3vnXstPVVLpHKlqcFm6nM2o= =/HQD -END PGP SIGNATURE-
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Nothing here says that when we have no way to support a user's task with free software, we will go ahead and ship nonfree software to do this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Daniel Dickinson [EMAIL PROTECTED] writes: If permission is given to distribute the blobs unmodified (i.e. read from disk, upload to device), then the question is about the social contract. Personally I think firmware blobs shouln't be covered, because the reasons free software is important don't apply. Many of the reasons certainly still apply. But that isn't the point. The Social Contract does not say when such-and-such reasons apply, Debian is 100% Free Software; other times we ship non-free software and call it free. Moreover, there have been now TWO general resolutions designed to test whether the developers really want Debian to be 100% Free Software or only 99% Free Software, and twice now, the decision has been 100%. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
May I remind you all that debian-release is NOT a discussion list? I think the respective positions are clear. Now can the release team please step in and say what their view on the matter is, which AFAICS is the only reason why this thread should belong to this list? Gerardo
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 06, 2006 at 04:50:54PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. Or, the kernel team could actually comply with the DFSG for the first time ever. These are fine words, but how do you think they can translate into reality ? We don't currently have the ressources to do it the way it should be done, and evne if we did, the deficiencies of d-i will make the work we do useless. But then, you could help, and put your actions where your mouth is, by helping in the elaboration of an exhaustive list of such problematic firmware hexdumps, together with their licencing conditions, their copyright holder, and a summary of what the module is good for. This stands for anyone having a similar discourse to yours too :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 10:23:31AM +0200, Frederik Schueler wrote: Hello, On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote: These are fine words, but how do you think they can translate into reality ? We don't currently have the ressources to do it the way it should be done, and evne if we did, the deficiencies of d-i will make the work we do useless. Sven, can you please finally STOP flaming against the debian-installer team, thank you. Well, its a simple statement of facts, is it not ? I mean, did you find any untruth in what i said above, or in the other mail ? It has a direct bearing over the problem at hand, and a certain subset of the d-i folk exhibited inacceptable behaviour against me over it, so it is only just that their errors and inadequacies are remembered when we speak about these topics, since it was me trying to speak about those topics wich pushed them in the first place to start the witch hunt against me, and nothing i can do can in any way change the current mess, even the DPL in his attempted second mediation came to the conclusion that i should just fork d-i or something. So, no, i will not stop this, and i will never forget what they did to me, nor the circunstances in which they did it, i tried mutliple times, but it was rejected out of hand, so ... But then, you could help, and put your actions where your mouth is, by helping in the elaboration of an exhaustive list of such problematic firmware hexdumps, together with their licencing conditions, their copyright holder, and a summary of what the module is good for. I agree, everyone who wants to see the firmware issue solved should either start doing something about it or be silent. here is an outdated wiki document, where to start with: http://wiki.debian.org/KernelFirmwareLicensing Thanks for the hint. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such aggregated code from the kernel image? And we aren't just talking about firmware here. There are header files and even C source files with issues in the vanilla kernel. I agree with you that firmware included in a kernel deb that gets loaded with the firmware loader just an aggregation. But that is not the issue here. And even for an aggregation of works the DFSG holds and you are still in trouble. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. The non-free library never runs in the same address space as the rest of the program. Does that mean this is just an aggregation of works and GPL compliant? If I put the non-free library into an external plugin and (optionaly) dlopen it then I have a completly different story. The second case is easier, we have simply to remove the non-free firmware, and put it in non-free, and/or remove completely the non-free driver and put it in non-free. In the case of modules vital to boot the machine we are trully screwed here, and by some of ourselves even. The problem is that the installer people, who where told repeteadly by me and others about this issue since over 6 month, and should have worked on enabling the installer to load .udebs from multiple apt/anna sources and not just one, thus enabling to place those non-free .udebs into a separate non-free .udeb archive, and solve this problem neatly. I've been bugging Bastian about this issue as well since I need this for multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. But then, the d-i team, has prefered to ignore this issue, shot the messenger, and go into kicking out, witch hunts and diffamatory tactics in order to not face their own lack of vision and inadequateness, in the same way as their reaction to the kernel module .udeb proposal was over-agressive and now leaves us in mostly the same situation as we where at the sarge release time, with the d-i team incapacity to handle kernel abi bumps and security upgrades in a timely fashion. One problem is that you keep banging on the door, where the watchdog barks at you and the armed guards won't let you in. Try the window or the backdoor. Change your approach. Personaly I think the only way to get D-I to use non-free udebs is to first have some. Preferably something essential. The harddisk driver or network driver of Bastians or Joeys system would be perfect. Since we can't convince the developer to implement this feature for its own merit lets create some desperate need for it. So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such i guess objdump would do it, from most of these cases, the only symbol involved is the position of it in the code, and the incrimated code is just a binary hexdump contained in a single variable + size. aggregated code from the kernel image? And we aren't just talking about firmware here. There are header files and even C source files with issues in the vanilla kernel. Well, we are speaking about firmware hexdumps, i don't know about the others you are referencing, but if there are other suchs, please list them explicitly. And no, a separate header file containing just this single variable doesn't count. I agree with you that firmware included in a kernel deb that gets loaded with the firmware loader just an aggregation. But that is not the issue here. What is then ? And even for an aggregation of works the DFSG holds and you are still in trouble. Sure, the DFSG says that we need the source code for those, and they are thus non-free, but what i am arguing is that they are not violation of the kernel GPL, since they are separate aggregate works. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. Let me make another example. You buy a random bunch of hardware, and either run linux on it, or run a free linux driver running it. This hardware in question happens to have some random bios on it, which is non-free, or some fpga config file hidden in a flash. This is exactly the same case as the one you are describing, with the sole exception of the firmware in question being temporarily transported in the kernel binary and uploaded in the device. If you follow the FSF FAQ about the GPL, you will see that there are a certain amount of criterias which apply here, among them the separate memory pool/area one, as well as the well defined communication interface, which is clearly respected here. So, altough IANAL, i believe without doubts that we are not seing a GPL violation here, and that the non-free firmware and the linux kernel are mere aggregation. After writing this to LKML last year, i also contacted the FSF legal counsel, and altough they didn't give a supportive analysis of this, there was no strong outcry either. Not sure what this means. I believe i got the consensus of debian-legal behind me on this one, as you would see if you consulted the archives, and the broadcom, and QL-something, legal team, also found this analysis reasonable and changed their tg3 and ql-something licencing accordyingly. Also, if you really want to argue the other way, you will end up in a world of trouble, and will end not being able to run linux on any box around i know. Finally, what you mention is more akin to the unicorn driver, which is a driver for a soft-ADSL pci modem, which links to a non-free, binary-only, x86-only ADSL library. This is indeed more than just agregation, and after i engaged bewan over it, and we consulted with RMS and the FSF, they released their drivers with a GPL+exception licence, and the package is now happily sitting in non-free, waiting for someone to write a free ADSL library replacement. The non-free library never runs in the same address space as the rest
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther wrote: On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. Yeah, exact, its mips or arm machine code, uploaded to the embedded core in the chip used for the peripheral in question. Often it isn't, unless you want to call the content of a configuration register bank code. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: untruth in what i said above, or in the other mail ? Yes. There is the option of simply not supporting installation on the devices in question. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Yes. There is the option of simply not supporting installation on the devices in question. i.e. screwing our users. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. I rest my case. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. I rest my case. Your case that... what? That our users will be inconvenienced if we cannot support certain hardware in the installer? Yes, nobody has doubted this. But you have not given any argument for why this should in this one case override our principles, cause us to violate our own Social Contract, and otherwise simply abandon what Debian stands for. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 04:26:45PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: untruth in what i said above, or in the other mail ? Yes. There is the option of simply not supporting installation on the devices in question. Yeah, well, sure there is, but given what those devices are, and the general outcry when we temporarily removed them in the past, i have some serious doubts about this really being a solution. But then, we where speaking about the 'inflamatory' part of those mails, not about the more technical part. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Where do you read we allow ourselves to distribute non-free software for user convenience ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. As to being a problem that depends if anyone ever sues, which is indeed unlikely. But Debian has also made a promise that main will be free. And the kernel breaks that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
In linux.debian.kernel Ron Johnson [EMAIL PROTECTED] wrote:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the debian-legal@ armchair lawyers.
Could they have signed license agreements that we (not being
executives of RHAT and Novell) don't know about?
While it may be possible in theory, it's also very hard to believe.
If there are any signed license agreements, then they will probably drop some
notes in the {src}.rpm packages themselves they distribute to give their
users a clue, since these users are the most interested end to be aware of
that legal situation.
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. There is a problem, as was the case for some of the firmware we where distributing, like the tg3 one, where there was no explicit licence for the firmware hexdump, and as thus, it was defacto placed under the GPL, and this means it is indeed undistributable. But this can easily be solvev by approaching those upstream guys and fixing the licencing issue with them, and before you all laugh about such an idea, this was done by Andres Salomon and me and a few others for such firmwares as the tg3 one from Broadcom, and they indeed did clear up the licencing. As to being a problem that depends if anyone ever sues, which is indeed unlikely. But Debian has also made a promise that main will be free. And the kernel breaks that. Indeed, and that is the problem here. We have two cases, first, there is the firmwares without source placed (by author's ignorance usually) under defacto GPL and undistributable, this we have to remove from both main or even non-free, and go the author contacting route (except in some cases, the copyright holder has been multiple-times bought up, and the new owner doesn't care, and everyone is screwed). The second case is easier, we have simply to remove the non-free firmware, and put it in non-free, and/or remove completely the non-free driver and put it in non-free. In the case of modules vital to boot the machine we are trully screwed here, and by some of ourselves even. The problem is that the installer people, who where told repeteadly by me and others about this issue since over 6 month, and should have worked on enabling the installer to load .udebs from multiple apt/anna sources and not just one, thus enabling to place those non-free .udebs into a separate non-free .udeb archive, and solve this problem neatly. But then, the d-i team, has prefered to ignore this issue, shot the messenger, and go into kicking out, witch hunts and diffamatory tactics in order to not face their own lack of vision and inadequateness, in the same way as their reaction to the kernel module .udeb proposal was over-agressive and now leaves us in mostly the same situation as we where at the sarge release time, with the d-i team incapacity to handle kernel abi bumps and security upgrades in a timely fashion. So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Marco d'Itri [EMAIL PROTECTED] writes: In linux.debian.kernel Sven Luther [EMAIL PROTECTED] wrote: The real issue here is one of freedom and DFSG and not one of legality anyway. Those firmware are not DFSG-free and have nothing to do in main, and this is the real problem. They were not a problem before the SC was clarified, so I do not expect that many people will suddenly care now. They have always been a problem and have always violated the license of the rest of the kernel. It is just that nobody noticed or cared before but now the cat is out of the sack and the issue is a release blocker. Sometimes ignorance is bliss. But now we have seen the (ugly) light. -- ciao, Marco MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Danchev wrote:
On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
In linux.debian.kernel Ron Johnson [EMAIL PROTECTED] wrote:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the debian-legal@ armchair lawyers.
Could they have signed license agreements that we (not being
executives of RHAT and Novell) don't know about?
While it may be possible in theory, it's also very hard to believe.
Because?
If there are any signed license agreements, then they will probably drop some
notes in the {src}.rpm packages themselves they distribute to give their
users a clue, since these users are the most interested end to be aware of
that legal situation.
Do any Debianites read SRC.RPM packages?
- --
Ron Johnson, Jr.
Jefferson LA USA
Is common sense really valid?
For example, it is common sense to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that common sense is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE1mafS9HxQb37XmcRAhFkAJ46nS1OMTb8wfh8o8BhLJcFyBmacACguNyX
E3zH8yiy+axVb6EsSoCsfx8=
=mfDp
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. Or, the kernel team could actually comply with the DFSG for the first time ever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. We already know that the lawyers of SuSE and Red Hat often take a more lenient view than Debian (see the old KDE controversy for an example). I believe that this can be explained by the simple observation that they are content as long as they don't get sued, whereas we do our best to follow the licenses whether there is a likelihood of getting sued or not. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Marco d'Itri [EMAIL PROTECTED] writes: I became a developer long before the NM process was created, and I agreed to follow the unclarified social contract. Are you unwilling to follow the current Social Contract? If so, you should resign, and yesterday. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? First of all, this is false. Most Debian developers agree with me. You This is unproven. think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. agrees with me that this is a problem, and it is explicitly a release blocker. It's not like they had a choice. You probably agreed to uphold the Social Contract in your Debian work. (Or were you grandfathered in before NM?) I became a developer long before the NM process was created, and I agreed to follow the unclarified social contract. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Marco d'Itri [EMAIL PROTECTED] writes: In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? First of all, this is false. Most Debian developers agree with me. You This is unproven. It is also irelevant. The release team has made it a release blocker. Thez have decided this (following the SC discussions for sarge) for the project. You need to convence them or make a GR to change it. think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? agrees with me that this is a problem, and it is explicitly a release blocker. It's not like they had a choice. Exactly, neither do you. :) You probably agreed to uphold the Social Contract in your Debian work. (Or were you grandfathered in before NM?) I became a developer long before the NM process was created, and I agreed to follow the unclarified social contract. 'or any later version'? :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? First of all, this is false. Most Debian developers agree with me. You think not? Prove it by proposing a GR. More importantly, the release team agrees with me that this is a problem, and it is explicitly a release blocker. Further, majority opinion is irrelevant on issues of honesty. Debian is lying to its users. Debian needs to stop doing that. Frankly, I no longer care which way Debian becomes honest: (1) A GR amending the Social Contract to explicitly allow sourceless, non-free binary material in Debian (2) Removing the sourceless, non-free binary material from Debian main. Debian must do one of the two if it is to be honorable. I don't care which. You probably agreed to uphold the Social Contract in your Debian work. (Or were you grandfathered in before NM?) If so *you agreed* to remove this firmware. You have two honorable options: (1) Propose a GR amending the Social Contract to allow it. Please do so! (2) Remove it whenever it falls into your sphere of responsibility. You have historically chosen to take the dishonorable option, and I do not expect you to change, but I can hope. -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
* Sven Luther ([EMAIL PROTECTED]) [060110 21:16]: On Tue, Jan 10, 2006 at 05:19:47PM +0100, Andreas Barth wrote: difference to this. It might however make an difference to GPL-compatibility, unless the license is GPL-compatible anyways. Nope, please read my posts on debian-legal about this topic 6 month or so ago. It might was meant as this mail doesn't make any statement whether or not it has effect. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. You can't decide if it is something which can be executed somewhere. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 signature.asc Description: Digital signature
Re: non-free firmware in the linux kernel
On Wed, Jan 11, 2006 at 12:56:44PM +0100, Bastian Blank wrote: On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. You can't decide if it is something which can be executed somewhere. Sure, but if in doubt, then it is non-free. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
* Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]: On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. You can't decide if it is something which can be executed somewhere. Can you define what execute means? Is it execution if e.g. data is processed that defines a sound-wave for a DSP? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Bastian Blank wrote: On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. Please name them. I could likely be convinced that *those* firmware blobs do not need source code. That's different from *all* firmware blobs. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Andreas Barth wrote: * Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]: On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. You can't decide if it is something which can be executed somewhere. Can you define what execute means? Is it execution if e.g. data is processed that defines a sound-wave for a DSP? OK, let's agree that DSP sound-wave definitions and similar transformation tables of data for sound cards are fine and free, because binary blobs probably *are* the preferred form for modification of those (if anyone actually wanted to modify them). (Of course, that's just based on my minimal knowledge; if a sound card hacker steps up and says no, those blobs are definitely not the preferred form for modification, I would have to defer to his/her superior knowledge.) -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
On Wed, Jan 11, 2006 at 12:14:10PM -0500, Nathanael Nerode wrote: Sven Luther wrote: 2) there are now drivers which contains non-free firmware blobs, with explicit licence, and these are thus distributable. A quick search for fw_ revealed 159 such files in 2.6.15. I would like to add that I have volunteered to (a) assist with converting these to the request_firmware infrastructure (b) package the blobs for 'non-free'. Udebs provided on request. I actually *did* this for tg3 (back when the firmware was undistributable, but before I'd noticed that). However, all my work so far has been rejected by upstream for reasons which I can only call pure hostility (I have seen few technical reasons, and have received no response to requests regarding what would be an acceptable patch). The corresponding patches have been removed from the Debian kernel because the kernel maintainers at the time did not want to maintain patches relative to upstream. This does not exactly encourage me to work on other drivers. I have since misplaced my tg3 work, and would have to retrieve it from an old Debian kernel package. Help doing so would be appreciated :-) Well, i hear the tg3 upstream was not at all happy about this request_firmware, but this doesn't mean other drivers upstream will not be sympathic to such a patch, and the situation changed upstream i believe. Also, the debian kernel team situation may be different if we decide to go this way. d) we go for a new GR, asking for an exception for the linux kernel, in order to still stay in main, even though the firmware is non-free, arguing that said firmware is more akin to hardware, since it replaces firmware on a prom or flash on the expansion card, and you thus lose no freedom if we distribute it, and the pain the other solutions will cause to ourselves and our users. If my DD application ever goes through, I would definitely vote against this, because the argument is completely bogus. For an similar argument, An implementation of BASIC is more akin to hardware, because it replaces IBM BASIC which used to be kept in ROM. This argument might wash if the firmware was not code at all, but in the cases I know of, the firmware is in fact code for MIPS, ARM, and other ordinary CPUs which are on the expansion card. Well, the difference is that we can live without a basic implementation, while living without the kernel is more problematic :) It would be a kind of pragmatic decision, and in line with the user freedom part of the social contract. Ok, i believe this summarizes the discussion of this evening, a log of the irc discussion can be found at : http://people.debian.org/~fs/firmware-irc-log.html You should have invited me, you know. :-) Well, we are now discussing things, there was only a small subset of the kernel team there anyway, maybe it was best so, it was already tense enough like that :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Kyle McMartin wrote: The question is: when you remove the firmware from the driver, and all it is, is a file sitting in /lib/firmware/; and it's contents are just non-executable hex, Sorry, it is executable. For instance, the tg3 code is simply MIPS binary which can be disassembled with binutils. Factual error. Try again! with no C-code structure, is it just a BSD-licensed (in the qla2xxx case) data file, or is it still regarded as a piece of code. This, to me, is no different from a BSD licensed JPEG. I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. Of course, firmwares where the license has not been clarified by the copyright holder/IP owner would still be a problem; or where something is clearly unredistributable (ie: Intel IPW firmwares.) Or where it's licensed without permission to modify, e.g. tg3 firmware. Which is actually a very common result when the licenses do get cleared up with the copyright holder. :-P -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
[EMAIL PROTECTED] wrote: licenced modules. If we don't want to do that, the most honest way to handle it is to get another GR out the door,explaining that this is not easily possible or convenient at this time, and asking for an explicit exception for kernel firmware. I would second such a GR. I would be comfortable with a specific exception for *etch only* for drivers which *may need to load in order to mount root*. I would also be comfortable with an exception for *etch only* allowing the *installer* to contain and install such non-free material. I would not be happy with a general exception for the regular kernel packages in 'main'. Rationale for those rules follows; it is based on practical considerations. It would be dangerous to have a permanent exception, because it would just lead to more and more non-free stuff in the kernel -- because it would encourage the people who don't care to avoid fixing it and to reject patches from other people. :-P Observe the foot-dragging on the GFDL issue. It is dishonest to say that it is not easily possible or convenient to fix this issue for drivers which don't need to load early, particularly if the installer is exempted; the work for this is quite far advanced. First the issues if the installer is exempted: -- For any userspace-firmware-loading driver which does not need to be loaded in order to mount root, it requires only a deb containing the needed file for /lib/firmware (trivial). The kernel firmware loading code and udev/hotplug take care of the rest. For a non-early-loading driver which has embedded firmware, it requires a deb for the driver matching each possible installed kernel (tedious, but certainly feasible, and very straightforward). For a firmware-blob-embedding driver which needs to load before root is mounted, it requires no additions on the installed system, just the debs for the driver module for each possible installed kernel. For a userspace-firmware-loading driver which needs to load before root is mounted, it additionally requires: (1) udev and /lib/udev/firmware.agent available and in the initramfs -- I believe this is being worked on for other reasons anyway, right? (2) patches to yaird/initramfs-tools to install the files from /lib/firmware in the initramfs -- this is easy If these two steps are not ready by freeze time, I would be happy to have an exception for such drivers, as noted above. Second, the issues with the installer -- For any userspace-firmware-loading driver which does not need to be loaded in order to mount the CD or floppy drive, it requires (1) an easy facility for inserting an extra debs CD or floppy in the installer (already present) (2) an easy facility for inserting an extra udebs CD or floppy in the installer (already present, I think?) (3) a udeb (probably the same one) for each such piece of firmware, which puts the file in /lib/firmware on the installer ramdisk (almost trivial) (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) (5) working udev/hotplug firmware.agent in the installer (this is being worked on already for other reasons, right?) The kernel firmware loading code and udev/hotplug take care of the rest. If the infrastructure for this was not ready by freeze time, an exception would be warranted, though I don't see any reason why it wouldn't be ready. For a non-early-loading driver which has embedded firmware, it requires: (1) an easy facility for inserting an extra debs CD or floppy in the installer (already present) (2) an easy facility for inserting an extra udebs CD or floppy in the installer (already present, I believe) (3) a udeb for the driver matching the kernel used in the installer (tedious, but certainly feasible) (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) If the infrastructure for this was not ready by freeze time, an exception would be warranted, but I also don't see any reason why it wouldn't be ready. Yes, you'd have to build a bunch of drivers out of tree in non-free until they were converted to userland-firmware-loading. You already know how to do this, folks. For any driver which needs to load before the CD drive is mounted, it would appear to require (a) provisions in the installer for loading extra udebs (from where?) before mounting the CD, which are almost certainly infeasible (b) or an entire non-free installer release This is the only genuinely impractical case, and an exception *should* be made for it in the interests of installing on as much hardware as possible. This message is public domain. Please feel free to copy it to whereever you think it needs to be read. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
Nathanael Nerode wrote: Second, the issues with the installer -- Your analysis of the modules that would be needed by the installer does not take all possible installation methods and hardware combinations into account, notably missing a) network cards b) pcmcia c) usb d) systems without usable removable media. (1) an easy facility for inserting an extra debs CD or floppy in the installer (already present) No, it's not. (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) Impossible in many cases. (b) or an entire non-free installer release Or the other options for user mergable non-free/free images that I have discussed in prior postings on this topic. -- see shy jo signature.asc Description: Digital signature
Re: non-free firmware
On Mon, Jan 09, 2006 at 08:13:18PM +0100, Sven Luther wrote: current fact is that the qlaxxx firmware is gpl, so on has all it's right in main. It is GPL, except for the binary blob of firmware, as the two constitute separate work, this is not a violation of the GPL. The exact licence, that this one comes under, as pointed out by Frederik and Andres on irc is in Documentation/scsi/LICENSE.qla2xxx : This program includes a device driver for Linux 2.6 that may be distributed with QLogic hardware specific firmware binary file. You may modify and redistribute the device driver code under the GNU General Public License as published by the Free Software Foundation (version 2 or a later version). You may redistribute the hardware specific firmware binary file under the following terms: 1. Redistribution of source code (only if applicable), must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of QLogic Corporation may not be used to endorse or promote products derived from this software without specific prior written permission Which unless someone released a heavily modified GPL licence silently in out back, very very far from the GPL itself. Yes; this is not GPL, this is a simple BSD license. The BSD license is certainly considered free: it grants us all the redistribution and modification rights that we require in order for a work to be included in main. The only thing it doesn't grant us in this case (which is not a license issue, though the license does acknowledge the issue) is source redistribution simply because we don't have any source code. So this work is not acceptable for main if we require source code for firmware; and it is acceptable if we don't require source code for firmware. I have argued previously (on debian-legal and elsewhere) that for some types of works, such as icons, fonts, and documentation, source code is not important to the modifiability of a work in the same way that it is to programs. There are many cases in which the original source form used by the author is *not* the preferred form of modification for the creation of new derivative works, and it seems to me that the DFSG silently acknowledges this reality by speaking about programs (not the ambiguous software) directly in DFSG #2. But of all the forms of software that we distribute which aren't normally considered programs, firmware is certainly the most program-like. I believe the problem currently before us is, therefore, to decide whether we as a project consider firmware to be programs for the purposes of DFSG compliance. I am disposed to accept that they are not, but I'm not comfortable making this decision on behalf of the project ex cathedra as an RM. Instead, my plan had been to, over the next month or two, review the past discussions of this point, talk the issue over with various folks, and propose a GR that would clarify this interpretation of the DFSG where firmware is concerned. If the discussion part is starting now, so much the better. Please respect M-F-T to debian-project. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-free firmware in the linux kernel
On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote: In 2004, there was a GR that decided to put everything in main under the DFSG. We had some discussions, but in the end, the result was that all the non-free firmware bits have to be removed from main before we can release etch. Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? 3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. And this seems like a good thing; for starters it makes it easier to test different firmware versions without having to do irrelevant recompiles of kernel code. Here is a link to the relevant wiki page about the cleaning up of messy licences : http://wiki.debian.org/KernelFirmwareLicensing So, basically this means we have the following options : a) we move the whole kernel to non-free :) Essentially a non-option. b) we move the affected modules to non-free. Well those that have their licencing solved, the others will simply no more be distributed, or distributed form an unofficial source. Probably overkill, and causes significant problems unless we are able to provide better infrastructure for such modules in the installer. c) we move the firmware in non-free, and actively use the request_firmware mechanism. Seems like a pretty good division, but if there are users who *need* the non-free firmware, we still have problems unless there's some way for them to grab it in the installer. d) we go for a new GR, asking for an exception for the linux kernel, in order to still stay in main, even though the firmware is non-free, arguing that said firmware is more akin to hardware, since it replaces firmware on a prom or flash on the expansion card, and you thus lose no freedom if we distribute it, and the pain the other solutions will cause to ourselves and our users. So, see my latest post to -project about that. I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. I don't consider this analogous to the GFDL. The firmware question is what format must a work be made available in for us to consider it free? The GFDL question is what freedoms must the copyright holder have granted to us for us to consider it free? Also, if we go the BSP way, it has to make clear that it had to be a long standing and coordinated effort, since random patches of dubious quality will probably only make matters worse for the kernel team.. Seems like a poor fit for a BSP then, IMHO. BSPs work best when you can put people to work immediately with little learning curve. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-free firmware in the linux kernel
On Tue, Jan 10, 2006 at 02:52:07AM -0800, Steve Langasek wrote: b) we move the affected modules to non-free. Well those that have their licencing solved, the others will simply no more be distributed, or distributed form an unofficial source. Probably overkill, and causes significant problems unless we are able to provide better infrastructure for such modules in the installer. c) we move the firmware in non-free, and actively use the request_firmware mechanism. Seems like a pretty good division, but if there are users who *need* the non-free firmware, we still have problems unless there's some way for them to grab it in the installer. Both will need the same amount of work in the installer. we are speaking network and scsi drivers here, those are used for the install and for the root filesystem. d) we go for a new GR, asking for an exception for the linux kernel, in order to still stay in main, even though the firmware is non-free, arguing that said firmware is more akin to hardware, since it replaces firmware on a prom or flash on the expansion card, and you thus lose no freedom if we distribute it, and the pain the other solutions will cause to ourselves and our users. So, see my latest post to -project about that. Yep, saw it first actually. I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. I don't consider this analogous to the GFDL. The firmware question is what format must a work be made available in for us to consider it free? The GFDL question is what freedoms must the copyright holder have granted to us for us to consider it free? I meant it would provide for a less strong standing on the GFDL front. They will say, see you didn't like the GFDL, but you are accepting non-free firmware, which is worse. Also, if we go the BSP way, it has to make clear that it had to be a long standing and coordinated effort, since random patches of dubious quality will probably only make matters worse for the kernel team.. Seems like a poor fit for a BSP then, IMHO. BSPs work best when you can put people to work immediately with little learning curve. Well, Maks asked this to be added. The learning curve is not that great, i believe, but it needs to be coordinated and done right. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. And this seems like a good thing; for starters it makes it easier to test different firmware versions without having to do irrelevant recompiles of kernel code. The question is: when you remove the firmware from the driver, and all it is, is a file sitting in /lib/firmware/; and it's contents are just non-executable hex, with no C-code structure, is it just a BSD-licensed (in the qla2xxx case) data file, or is it still regarded as a piece of code. This, to me, is no different from a BSD licensed JPEG. I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. Of course, firmwares where the license has not been clarified by the copyright holder/IP owner would still be a problem; or where something is clearly unredistributable (ie: Intel IPW firmwares.) Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
* Kyle McMartin ([EMAIL PROTECTED]) [060110 16:20]: I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. Sorry, but there is no difference regarding DFSG: If the binary blob is actually seperated from the kernel implementation, it can be treated as binary blob (which I personally consider as non-program - but see Steve's mail for details). Whether this binary blob is embedded in the kernel source code (like we have IIRC for the pinguin boot logo) or not (or is linked to the kernel during link time) doesn't make any difference to this. It might however make an difference to GPL-compatibility, unless the license is GPL-compatible anyways. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Tue, Jan 10, 2006 at 01:45:11AM -0800, Steve Langasek wrote: You may redistribute the hardware specific firmware binary file under the following terms: 1. Redistribution of source code (only if applicable), must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of QLogic Corporation may not be used to endorse or promote products derived from this software without specific prior written permission Which unless someone released a heavily modified GPL licence silently in out back, very very far from the GPL itself. Yes; this is not GPL, this is a simple BSD license. The BSD license is certainly considered free: it grants us all the redistribution and modification rights that we require in order for a work to be included in main. The only thing it doesn't grant us in this case (which is not a license issue, though the license does acknowledge the issue) is source redistribution simply because we don't have any source code. It is not BSD license, it does not grant the right to distribute modified versions. So even with the source this would still be nonfree. That is a frequent issue with firmwares, that I personnaly find more serious that lack of source. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Tue, Jan 10, 2006 at 11:38:21AM -0600, Bill Allombert wrote: On Tue, Jan 10, 2006 at 01:45:11AM -0800, Steve Langasek wrote: You may redistribute the hardware specific firmware binary file under the following terms: 1. Redistribution of source code (only if applicable), must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of QLogic Corporation may not be used to endorse or promote products derived from this software without specific prior written permission Which unless someone released a heavily modified GPL licence silently in out back, very very far from the GPL itself. Yes; this is not GPL, this is a simple BSD license. The BSD license is certainly considered free: it grants us all the redistribution and modification rights that we require in order for a work to be included in main. The only thing it doesn't grant us in this case (which is not a license issue, though the license does acknowledge the issue) is source redistribution simply because we don't have any source code. It is not BSD license, it does not grant the right to distribute modified versions. So even with the source this would still be nonfree. Hrm, true. Thanks for catching me on this; regardless of the source question, then, this particular firmware license isn't free enough for main. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-free firmware in the linux kernel
On Tue, Jan 10, 2006 at 10:00:53AM -0500, Kyle McMartin wrote: 3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. And this seems like a good thing; for starters it makes it easier to test different firmware versions without having to do irrelevant recompiles of kernel code. The question is: when you remove the firmware from the driver, and all it is, is a file sitting in /lib/firmware/; and it's contents are just non-executable hex, with no C-code structure, is it just a BSD-licensed (in the qla2xxx case) data file, or is it still regarded as a piece of code. Kyle, i think you know the answer of this one, or you would not have asked. It is irrelevant the form the code takes, or any legal hoops you may try to take around this, code remains code. This, to me, is no different from a BSD licensed JPEG. Well, except, as Bill pointed out, it is no BSD licence at all :) I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. So just because you but a cat in a box, it is no more a cat ? Of course, firmwares where the license has not been clarified by the copyright holder/IP owner would still be a problem; or where something is clearly unredistributable (ie: Intel IPW firmwares.) Indeed ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
On Tue, Jan 10, 2006 at 05:19:47PM +0100, Andreas Barth wrote: * Kyle McMartin ([EMAIL PROTECTED]) [060110 16:20]: I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. Sorry, but there is no difference regarding DFSG: If the binary blob is actually seperated from the kernel implementation, it can be treated as binary blob (which I personally consider as non-program - but see how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. Micro-code being another synonym for the concerned firmware in some cases. So how could anyone honestly claim it is a non-program is beyond me :) I know we all wish it where so, but ... Steve's mail for details). Whether this binary blob is embedded in the kernel source code (like we have IIRC for the pinguin boot logo) or not (or is linked to the kernel during link time) doesn't make any Indeed. difference to this. It might however make an difference to GPL-compatibility, unless the license is GPL-compatible anyways. Nope, please read my posts on debian-legal about this topic 6 month or so ago. The firmware is destined to run on another processor, and thus there is no way you can claim it is a derived work from the actual linux driver, since the communication channel is clearly delimited. The counter-example would make the linux kernel a derivative of any expansion card or motherboard with embedded bios, or even make it a derivative of the actual hardware. So, no, there is no GPL issue there, and things are clearly separate. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Mon, Jan 09, 2006 at 07:00:00PM +0100, Maximilian Attems wrote: On Mon, Jan 09, 2006 at 06:24:34PM +0100, Sven Luther wrote: On Mon, Jan 09, 2006 at 04:35:40PM +0100, maximilian attems wrote: On Sun, Jan 08, 2006 at 11:58:16PM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 09:50:47PM +0100, Frederik Schueler wrote: Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. The firmware is still source-less, and it is not data, as it represents microcode destined to be run on the controller it is uploaded to. we all agree that a line needs to be drawn. The stripped firmwares have questionable licenses and needs to be put in non-free. the problem is that there are two issues : 1) non-distributable modules, because the licence was messy. 2) distributable modules with non-free firmware. tg3 and qla2xxx used to be in the first class, and due to relicencing they now are in the second class, that don't make them free by any stretch of the imagination. the current stripping is chosen randomly by Xu. the stripped usb acenic drivers license is not that bad, it is distributable. Can you please back those claims with some reality ? I believe that the stripping has been done by Andres and some others a bit under a way ago, when they wrote the prune-non-free script. current fact is that the qlaxxx firmware is gpl, so on has all it's right in main. It is GPL, except for the binary blob of firmware, as the two constitute separate work, this is not a violation of the GPL. The exact licence, that this one comes under, as pointed out by Frederik and Andres on irc is in Documentation/scsi/LICENSE.qla2xxx : This program includes a device driver for Linux 2.6 that may be distributed with QLogic hardware specific firmware binary file. You may modify and redistribute the device driver code under the GNU General Public License as published by the Free Software Foundation (version 2 or a later version). You may redistribute the hardware specific firmware binary file under the following terms: 1. Redistribution of source code (only if applicable), must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of QLogic Corporation may not be used to endorse or promote products derived from this software without specific prior written permission Which unless someone released a heavily modified GPL licence silently in out back, very very far from the GPL itself. Notice how this licence speaks of source code of the firmware, and that if you where to have had a copy of it, you are bound under the same licence, and it clearly mentions redistribution as binary only, as opposed to with source. So, now that the facts are there, i would think you would be very very hardpressed to actually claim this to be DFSG free, don't you think ? so, right now, if we are true to ourselves and follow the GR, we would have to put tg3 and qla2xxx modules in non-free, and totally remove the messed up licenced modules. If we don't want to do that, the most honest way to handle it is to get another GR out the door,explaining that this is not easily possible or convenient at this time, and asking for an explicit exception for kernel firmware. I would second such a GR. that's one outcome if one follows you radical thoughts. Ah, no ? I mean, i would be happy with saying that despit this being non-free, it still make sense to keep it in main, but i doubt even the most lenient people would claim the above licence is DFSG free. nobody else seem to back your non-free position, Well, who is backing your position ? I guess they are only bored by this topic or haven't come to write on this one yet. so i'm far from certain that it's the one shared by the d-k team. Well, shall we have a vote ? kernel.org is distributing all of them. i'm sure that a user expects a package called linux-image to contain tg3 for example. Sure, but what has this to do with anything ? yes if you care about what you are distributing, you shouldn't
Re: non-free firmware in the linux kernel
Hi all, I am cross posting to debian-release and debian-boot, since this will affect them too. On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Hi, at least I lost track a bit, so this mail is basically a question to bring me up to speed. Ok, we had a long discussion on #debian-kernel, and altough not all participated (Manoj, maks, fs, dilinger, kyle and me mostly), i think it sums up well the current situation. In 2004, there was a GR that decided to put everything in main under the DFSG. We had some discussions, but in the end, the result was that all the non-free firmware bits have to be removed from main before we can release etch. Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? Basically, the situation is like this : 1) there where drivers under implicit GPL licence with binary only firmware. Since there was no explicit licence for this firmware, it was GPL, and since it was sourceless, it was non-distributable. We started work to get upstreams to relicence their code, which happened with the tg3 and qla2xxx drivers, but failed for others, like the acenic one, partly because of the demise of the company producing them and various acquisitions which left the IP in an unknown state nobody seems to bother with. 2) there are now drivers which contains non-free firmware blobs, with explicit licence, and these are thus distributable. A quick search for fw_ revealed 159 such files in 2.6.15. 3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. Here is a link to the relevant wiki page about the cleaning up of messy licences : http://wiki.debian.org/KernelFirmwareLicensing So, basically this means we have the following options : a) we move the whole kernel to non-free :) b) we move the affected modules to non-free. Well those that have their licencing solved, the others will simply no more be distributed, or distributed form an unofficial source. c) we move the firmware in non-free, and actively use the request_firmware mechanism. d) we go for a new GR, asking for an exception for the linux kernel, in order to still stay in main, even though the firmware is non-free, arguing that said firmware is more akin to hardware, since it replaces firmware on a prom or flash on the expansion card, and you thus lose no freedom if we distribute it, and the pain the other solutions will cause to ourselves and our users. I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. So, Andreas, you proposed help and bug squasing parties focused on this, i guess it is now clear what needs done :), and i can only stress that this needs an additional comitment of help, since any patch which will come up will probably have to be maintained by the debian kernel team for a long time. Also, if we go the BSP way, it has to make clear that it had to be a long standing and coordinated effort, since random patches of dubious quality will probably only make matters worse for the kernel team.. I also CCed the debian-boot team, since it becomes evident that this will mean some work on the d-i part, either to move the whole of d-i into nonfree (case a), or to modify d-i to use non-free .udebs for certain modules or firmware. Ok, i believe this summarizes the discussion of this evening, a log of the irc discussion can be found at : http://people.debian.org/~fs/firmware-irc-log.html Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote: I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. Oh, i forgot, this also means, if we go either b) or c), to create a new non-free-but-distribuable section in out archive, which would more easily be included on CD medias and such, or it will be ways more painful than needed on our users. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
