LWN.net Logo

Advertisement

Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop.

Advertise here

Debian Weekly News 2004/15

From:  Martin Schulze <joey-AT-infodrom.org>
To:  Debian News Channel <debian-news-AT-lists.debian.org>
Subject:  Debian Weekly News - April 13th, 2004
Date:  Tue, 13 Apr 2004 21:56:03 +0200

---------------------------------------------------------------------------
Debian Weekly News
http://www.debian.org/News/weekly/2004/15/
Debian Weekly News - April 13th, 2004
---------------------------------------------------------------------------

Welcome to this year's 15th issue of DWN, the weekly newsletter for
the Debian community. Several people have discussed the presence of
non-free components in the Linux kernel last week, which has resulted
in some removals already. Robert Millan [1]requested that all packages
which make use of [2]libtool be updated to a newer version, since
this is required in order to support the porting efforts based on GNU
libc and for the kernels of [3]GNU/kFreeBSD and [4]GNU/kNetBSD.

 1. http://lists.debian.org/debian-devel-0404/msg00939.html
 2. http://packages.debian.org/libtool
 3. http://www.debian.org/ports/freebsd/
 4. http://www.debian.org/ports/netbsd/

Request Tracker for Debian. Branden Robinson [5]announced an
experimental [6]request tracker instance for the Debian
infrastructure. It's a resource for the convenience of people who find
it useful and it's not for technical problems, like bugs in packages.
Those belong at bugs.debian.org. However, Joachim Breitner
[7]believed that this software is too complex for Debian and seems to
target full-time support teams, and not part-time developers.

 5. http://lists.debian.org/debian-project-0404/msg00008.html
 6. http://necrotic.deadbeast.net/rt
 7. http://lists.debian.org/debian-project-0404/msg00010.html

New Debian Project Leader elected. Manoj Srivastava [8]announced the
results of this years' project leader [9]election. The winner of the
election is Martin Michlmayr. Manoj thanked Branden Robinson and
Gergely Nagy for their service to the project, for standing for the
post of project leader, and for offering the developers a strong and
viable group of candidates.

 8. http://lists.debian.org/debian-vote-0404/msg00035.html
 9. http://www.debian.org/vote/2004/vote_001

GNU/Linux Security Research. In response to a [10]security survey,
security teams from Mandrake, Red Hat, SUSE and Debian have released a
[11]joint statement. Despite the report's claim to incorporate a
qualitative assessment of vendor reactions to serious vulnerabilities,
it treats all vulnerabilities as equal, regardless of their risk to
users. As a result, the conclusions drawn by Forrester have extremely
limited real-world value.

 10. http://story.news.yahoo.com/news?tmpl=story&cid=1738&e=2&u=/zd/20040330/tc_zd/123143
 11. http://www.debian.org/News/2004/20040406

Back to GNU/Linux Basics. Michael Hall composed a [12]review about
Debian 3.0. He asserted that the Debian project continues to provide a
GNU/Linux distribution that offers organizations the sort of commodity
infrastructure for which Linux was originally known. While other
GNU/Linux variants tend to complete the installation assuming a few
basic configuration parameters, Debian's installer requires the user
to make decisions about security or functionality-related issues
during the process.

 12. http://www.serverwatch.com/sreviews/article.php/3334021

Debian powers Satellite Routers. Rodney Gedda [13]reported about 75
towns across New South Wales (Australian) that access the Internet
through Debian-based satellite routers spanning upwards of 800,000
square kilometers. The local satellite router developer Ursys chose
Debian because of its packaging support, which facilitates the ability
to push updates to the routers remotely.

 13. http://open.itworld.com/4917/040330linuxsat/page_1.html

Debian Package of the Day. Andrew Sweger is publishing [14]daily
descriptions to introduce people to cool packages in the Debian
testing distribution such as [15]proxycheck, [16]pwgen or [17]vtun. So
far over 25 packages have been featured. Syndicated feeds are
available in [18]RSS and [19]Atom formats.

 14. http://www.livejournal.com/users/debaday/
 15. http://packages.debian.org/proxycheck
 16. http://packages.debian.org/pwgen
 17. http://packages.debian.org/vtun
 18. http://www.livejournal.com/users/debaday/data/rss
 19. http://www.livejournal.com/users/debaday/data/atom

Use Case: The Register. Aaron Crane of [20]GBdirect [21]reported that
the web servers of [22]The Register are running [23]Apache on Debian
GNU/Linux, with [24]MySQL for the back-end database with a custom
content management system which is written in [25]Perl. The scripts,
HTML, and CSS were created and edited using a combination of [26]Vim,
[27]GNU Emacs, and [28]Mozilla Firefox's [29]EditCSS extension.
GBdirect chose Debian for its stability, reliability, flexibility, and
especially for its superlative support of remote package management
and upgrades.

 20. http://www.gbdirect.co.uk/
 21. http://www.theregister.co.uk/odds/about/website/
 22. http://www.theregister.co.uk/
 23. http://httpd.apache.org/
 24. http://www.mysql.com/
 25. http://www.perl.com/
 26. http://www.vim.org/
 27. http://www.gnu.org/software/emacs/
 28. http://www.mozilla.org/products/firefox/
 29. http://editcss.mozdev.org/

Chinese Book about Debian GNU/Linux. The first [30]Debian book in
Chinese was recently published by a very active Debian [31]community
(Chinese only) in Taiwan. The book is [32]entitled "Debian GNU/Linux,
The Painless Book" (Debian GNU/Linux &#28961;&#30171;&#36215;&#27493;)
and written by Asho Yeh and Moto Chen who also maintain the [33]errata
list.

 30. http://www.drmaster.com.tw/info.asp?no=OS20101
 31. http://moto.debian.org.tw/
 32. http://chuany.net/albums/album19/OS20101.jpg
 33. http://moto.debian.org.tw/viewtopic.php?t=2968

Fine-grained Dependencies. Kevin McCarty [34]announced that he's
working on defining more fine-grained dependencies on libdevel
packages that currently depend upon xlibs-dev. Branden Robinson
[35]added that Moritz Muehlenhoff has been [36]working on this as
well.

 34. http://lists.debian.org/debian-devel-0404/msg00067.html
 35. http://lists.debian.org/debian-devel-0404/msg00141.html
 36. http://lists.debian.org/debian-x-0403/msg03681.html

Namespace for GNUstep Packages. William Ballard [37]started a
discussion on naming GNUstep packages, since some of them use generic
names. Evan Prodromou, however, [38]disagreed and made [39]clear that
he will wait until a global naming standard for GNUstep application
packages is developed.

 37. http://lists.debian.org/debian-devel-0404/msg00125.html
 38. http://lists.debian.org/debian-devel-0404/msg00134.html
 39. http://lists.debian.org/debian-devel-0404/msg00285.html

Distribution of Peripheral Firmware. J.D. Hood [40]summarised the
options about how Debian could handle binary-only firmware components
for which no source code is available. Herbert Xu [41]added his view
on this issue and his preference is to move all kernel packages to
non-free since this pays homage both to our commitment to Free
Software as well as our users' needs.

 40. http://lists.debian.org/debian-devel-0404/msg00309.html
 41. http://lists.debian.org/debian-devel-0404/msg00405.html

PAM Release Status. Sam Hartman [42]reported about problems in current
PAM packages. Upon upgrades from woody the user is forced to answer a
dpkg configuration file question for which Branden Robinson
[43]provided a solution. Since configuration options have been
aggregated installations that end up with an empty root password
prevent root from logging in. Steve Langasek is discussing a change
for pam_unix.so with upstream, to bypass this for console access.

 42. http://lists.debian.org/debian-devel-0404/msg00443.html
 43. http://lists.debian.org/debian-devel-0404/msg00533.html

Debian powers The Gathering 2004. Steinar Gunderson [44]reported that
all central servers in the network of [45]The Gathering 2004 in Norway
are running Debian and the load on each of these machines is usually
under 0.2. Since they're sponsored by Sun, the central machines are
Sun Netra X1 boxes (400 MHz SPARC-based 1U machines) that are running
woody.

 44. http://lists.debian.org/debian-devel-0404/msg00865.html
 45. http://www.gathering.org/

General Resolution on the Social Contract. Manoj Srivastava [46]called
for votes on the [47]general resolution to add editorial changes to
the social contract. Since this modifies the [48]social contract, this
general resolution requires a 3:1 majority to pass.

 46. http://lists.debian.org/debian-vote-0404/msg00038.html
 47. http://www.debian.org/vote/2004/vote_003
 48. http://www.debian.org/social_contract

Binary Firmware Components removed. After the kernel package
maintainer has [49]removed the acenic and tg3 ethernet drivers because
they contain an embedded firmware blobs, Marco d'Itri [50]investigated
the Linux kernel and [51]XFree86 packages for [52]other [53]drivers
containing a firmware dump. He added that if Debian will continue with
this policy then the MGA, Rage 128 and Radeon DRM drivers will have to
be removed as well.

 49. http://lists.debian.org/debian-devel-0404/msg00264.html
 50. http://blog.bofh.it/id_27
 51. http://packages.debian.org/src:xfree86
 52. http://bugs.debian.org/242865
 53. http://bugs.debian.org/242866

Security Updates. You know the drill. Please make sure that you update
your systems if you have any of these packages installed.

 * [54]tcpdump -- Denial of service.

 54. http://www.debian.org/security/2004/dsa-478

New or Noteworthy Packages. The following packages were added to the
unstable Debian archive [55]recently or contain important updates.

 55. http://packages.debian.org/unstable/newpkg_main

 * [56]blobwars -- Platform shooting game.
 * [57]gs-gpl -- GPL Ghostscript PostScript interpreter.
 * [58]m2crypto -- Crypto and SSL toolkit for Python.
 * [59]mimms -- MMS (mms://) streaming media download utility.
 * [60]ntlmaps -- NTLM Authorization Proxy Server.
 * [61]qtparted -- Parted frontend using QT.
 * [62]xmms-blursk -- Powerful visualization plugin for XMMS, similar
   to "Blur Scope".

 56. http://packages.debian.org/unstable/games/blobwars
 57. http://packages.debian.org/unstable/text/gs-gpl
 58. http://packages.debian.org/unstable/libs/m2crypto
 59. http://packages.debian.org/unstable/net/mimms
 60. http://packages.debian.org/unstable/web/ntlmaps
 61. http://packages.debian.org/unstable/x11/qtparted
 62. http://packages.debian.org/unstable/sound/xmms-blursk

Want to continue reading DWN? Please help us create this newsletter.
We still need more volunteer writers who watch the Debian community
and report about what is going on. Please see the [63]contributing
page to find out how to help. We're looking forward to receiving your
mail at [64]dwn@debian.org.

 63. http://www.debian.org/News/weekly/contributing
 64. mailto:dwn@debian.org


-- 
To UNSUBSCRIBE, email to debian-news-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


(Log in to post comments)

Debian Weekly News 2004/15

Posted Apr 14, 2004 5:03 UTC (Wed) by jwb (subscriber, #15467) [Link]

I find it pretty unbelievable that Debian would stop distributing the drivers which load firmware into their peripherals. Actually, I believe it fully. But it still amazes me.

The code in question does not even execute on the host CPU, so clearly it is not a derived work of the kernel, and therefore it is not covered by the GPL. Many peripherals need firmware loaded before they can run, namely scads of cheap USB devices.

Consider this exercise. To start peripheral XYZ it is necessary to write 0xf5, 0x02, 0x26, 0xff to its registers. So a driver might have source like char boot[] = {0xf5,0x02,0x26,0xff}; This information would have come from reading the datasheets. It's embedded binary code with no source.

Now, what is the difference between that and char firmware[] = { 4 kilobytes }? The answer: there is no difference. They are both binary code with no source. But nobody would think of suggesting that the former example should be removed from the kernel, and for that reason neither should the latter example.

Debian Weekly News 2004/15

Posted Apr 14, 2004 5:32 UTC (Wed) by Ross (subscriber, #4065) [Link]

If there is a source format for the former then it would be exactly the
same -- except much easier to fix. I thought the kernel developers had
decided on an interface to load binary-only firmware from userspace (and
before you say that is impossible it could include initial RAM images or
the new cpio stuff). That way there is a clear separation of the works.
No worries about derivatives (in either direction) and cleaner kernel
code to boot.

Debian Weekly News 2004/15

Posted Apr 14, 2004 5:32 UTC (Wed) by piman (subscriber, #8957) [Link]

Easy -- those 4 bytes can (and are) written easily by hand, i.e. they are the preferred form of modification. For the purposes of the GPL and the DFSG, that makes them the source.

People (most people, especially those working on commercial hardware) don't write 4k binary blobs by hand anyone, everyone uses an assembler. The assembly code is the source.

The issue is much less about GPL-compatibility (in most cases), than about compliance with the Debian Free Software Guidelines. Debian doesn't want to distribute non-free software, regardless of where that software is executed.

Debian Weekly News 2004/15

Posted Apr 14, 2004 15:03 UTC (Wed) by jwb (subscriber, #15467) [Link]

Okay, I can see your point. But what about other cases of objects that are not distributed with source? Take an image for example. If the artist creates the image using the Gimp, but Debian distributes the PNG, does that mean that either 1) Debian must also distribute the XCF file, because that's the preferred form for modification, or 2) Debian must move all artwork to non-free?

Don't get me wrong, I'd love to have the commented source for all these firmware blobs. Some firmware source for the aic7xxx/79xx SCSI HBA for example is included in the kernel by Adaptec themselves. And short of that I think loading the firmware from userspace is the best idea. But either way I think the project is blowing this issue out of proportion and it will hurt the users eventually.

Debian Weekly News 2004/15

Posted Apr 14, 2004 19:44 UTC (Wed) by piman (subscriber, #8957) [Link]

The answer is, Debian must distribute the XCF, if such a form existed. Sometimes the author of the work doesn't even save an intermediate form (for example, you don't distribute your source code with undo information in it), in which case, that's probably the preferred form for modification. If the author has an XCF that she modifies and then only gives users the PNG, then that image is proprietary, because you don't have source access. But if the author uses a PNG herself as the main form of modification, then it's the source.

In most cases, Debian does distribute the source to non-code, like XCF for image files, if such things exist. If you run across a situation where Debian doesn't, please file a bug against the package.

Non-free firmware in the kernel tree.

Posted Apr 14, 2004 8:59 UTC (Wed) by ballombe (subscriber, #9523) [Link]

Firmware are copyrighted code. Even forgetting the source issue, some firmware were found to carry a license incompatible with the GPL and/or DFSG. Some licenses did not allow for redistribution at all. See http://bugs.debian.org/242895 for an example.

Debian Weekly News 2004/15

Posted Apr 14, 2004 13:43 UTC (Wed) by sholden (guest, #7881) [Link]

The firmware in question clearly doesn't meet the requirements outlined in Debian Free Software Guidelines, so either they go or it goes.

And the difference in your example is that when a firmware change is made chances are the programmer does not edit a 4 kilobyte char array assignment statement by hand, and hence that isn't the "source".

If the 4 kilobytes was derived from datasheets and that is how it is managed then it would be fine, but that clearly isn't the case in some of these cases.

Debian Weekly News 2004/15

Posted Apr 14, 2004 13:57 UTC (Wed) by pizza (subscriber, #46) [Link]

Consider this -- the "firmware" that these drivers include used to be embedded directly into the hardware, usually in the form of an EEPROM or somesuch. Instead now, to save hardware costs, they forego the onboard ROM to save the $1.09 per device and have the host upload the firmware. This is the case with the current crop of prism3 wireless cards, for example.

So while it can be argued that this makes the device "non-free", the device was NEVER "free" to begin with. The hardware is still a magic black box, datasheets or no, because we don't have the, say, VHDL sources of the chips .

This does not make the driver "non-free"; instead it ends up in a similar situation as, say, using Ethereal on Windows -- Free Software that depends on Non-Free components. But when you think about it, does anyone actually run Linux on "Free" hardware? Let's look at that shiny CPU, mmmm?

The only difference now is that parts of that former black box have been transferred to the host. As far as the driver is concerned, it's still just a Non-Free component that's being interfaced to.

All that said, this is purely a matter of redistribution. If there is a binary blob associated with a driver, we need permission from the copyright holder to distribute it, be it with the kernel or from some other source. Otherwise we're breaking copyright law.

deb http://http.debian.org/debian firmware

Posted Apr 14, 2004 15:37 UTC (Wed) by chant (guest, #20286) [Link]

I agree completely. Perhaps debian could use a 'firmware' section, in addition to non-free/contrib/main. Firmware could be put in this section (to be loaded in from userspace via hotplug, like my Atmel 802.11b card) so long as debian has the right to redistribute it. I suppose the key issue is ensuring that every driver that needs firmware load it from user space - not a huge issue as long as you use initrd.

Sure, it's not free , but as pizza points out, hardware has never been free in the first place.

Debian Weekly News 2004/15

Posted Apr 14, 2004 18:20 UTC (Wed) by Peter (guest, #1127) [Link]

So while it can be argued that this makes the device "non-free", the device was NEVER "free" to begin with.

That's not the issue.

The issue is not whether your PC is a completely "open" or "free" platform. We all know it is not, for quite a few reasons. However, there's a great deal of difference between "Debian can run on hardware which itself doesn't meet the Debian Free Software Guidelines" ... and "Debian claims to be distributing 100% free software, but in reality is also distributing software which is not free."

The latter is a convenient little lie, and because it's a lie, it bothers a lot of Debian developers. Maybe you see no problem loading some binary blob into your RAID controller, but then again, maybe you also see no problem running the non-free NVidia XFree86 driver. You're free to do those things, even under Debian, but you'll have to get them somewhere else. Debian claims that their distribution contains only free works, not "only free works, plus whatever non-free components happen to be necessary to use any given hardware".

Debian Weekly News 2004/15

Posted Apr 14, 2004 22:02 UTC (Wed) by mlei (guest, #17766) [Link]

Extremely well-thought out post. If there were moderation on this site I'd mod it up informative.

Debian Weekly News 2004/15

Posted Apr 14, 2004 22:17 UTC (Wed) by Peter (guest, #1127) [Link]

Thanks. The content wasn't original - I already read the flamewar on debian-devel. (:

Debian Weekly News 2004/15

Posted Apr 15, 2004 16:42 UTC (Thu) by pizza (subscriber, #46) [Link]

You ignored the last paragraph of my original post. I agree that the "little lie" runs counter to the DFSG.

But I'm taking that "little lie" one step further -- I see no difference, morally, between a binary blob that has to be copied over to the hardware, versus a binary blob already embedded in the device itself (even if it's just mask ROM!). I consider that blob and the rest of the hardware inserparable, because without it, the hardware is just a paperweight.

But as you said, distributing this binary blob runs counter to the DFSG.

I just hope that, once all of these redistributable (yet non-DFSG-compliant) binary blobs are removed, the Debian kernels are still bootable.

Debian Weekly News 2004/15

Posted Apr 15, 2004 23:36 UTC (Thu) by Peter (guest, #1127) [Link]

I just hope that, once all of these redistributable (yet non-DFSG-compliant) binary blobs are removed, the Debian kernels are still bootable.

Long term, I think it's good for someone to stand up and send a message to these vendors that not everyone thinks they should keep back part of their source code just because it's not executed on the host CPU. Remember, a few years ago, binary-only drivers were quite common, even for things like network cards. But you can't get your driver into a Linus published kernel without giving out your source under the GPL. And these days, nobody in server space wants to be caught without a driver in the standard Linux kernel. So the vendors swallowed hard and did the right thing, contributing docs and in many cases actual drivers to Linux kernel development.

Not that I expect this next round to be won so easily, mind. Mostly because Linus doesn't really care about this part of the issue, so you can't threaten vendors with not having a driver in the official kernel. Debian is considerably less influential. But still, Adaptec proved many years ago that it's entirely possible - even reasonable - to ship full source code for your firmware. (They even went a step further and shipped the source for an assembler capable of assembling it.) And I dunno, maybe it's just me, but this decision doesn't seem to have hurt them in the least.

Since Adaptec proved it can be done, I don't see much reason for other vendors to insist on sending us their binary blobs. Except for the obvious reason: that they really don't care. That is the attitude it would be nice to change.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds