Milan Jurik wrote: > Hi, > > "C. Bergstr?m" p??e v P? 15. 05. 2009 v 15:13 +0300: > >> James C. McPherson wrote: >> >>> On Fri, 15 May 2009 14:47:27 +0300 >>> "C. Bergstr?m" <codestr0m at osunix.org> wrote: >>> >>> >>> >>>> I'm auditing the source and found a couple closed binaries.. I say >>>> closed binaries because of the wording with the corresponding license >>>> for each. I'm not sure how this could be fixed, but maybe it's best >>>> these be moved to the closed binaries download in the future. >>>> >>>> usr/src/uts/common/io/usb/clients/hwa1480_fw/i1480/i1480-usb-0.0.bin >>>> usr/src/cmd/ucodeadm/amd-ucode.bin >>>> >>>> >>> What exactly are you objecting to in the licensing? >>> >>> >> This isn't a license objection.. More just that it doesn't seem >> appropriate to be in the source tree. It's not source and putting it >> there is misleading imho.. You've pointed out a few more that I haven't >> found yet.. Knowing all of these would be helpful. >> >> Thanks >> >> > > Will it make you more happy if it will be embedded as huge char array in > file with c extension? > > Clearly, all these are: > > a) microcodes for CPUs > b) firmwares for some devices > > All comming from device developers. > > And device driver writers have several different possibilities how to > include them to their drivers. Many of them prefers to have them in > separate files, to simplify manipulation. > > Look at them like on images (e.g. PNG files). What is the benefit to > separate them from source tree? > (I care much less about the source code for foo.gif than some blob which be causing a security or stability issue)
Looking a bit more into what others are doing.. OpenBSD may or may not be sane, but it's a project I have a lot of respect for. To cite one of their developers and possibly answer my own question.. Reyk Floeter explained, "/there is a major difference between binary blobs and firmware images; the blobs are loaded as code into the OS kernel, but the firmware runs directly on the device on crappy embedded micro CPUs./" So there's a distinction being made here for open software and open hardware. Blobs possibly being a security risk, but firmware not executing directly on the host cpu and thus falling into a difference category. So then on there's the edge case of microcode updates. Which generally happen during a bios upgrade, but for convenience can be loaded each time on boot.. usr/src/cmd/ucodeadm/amd-ucode.bin usr/src/cmd/ucodeadm/intel-ucode.txt i1480-usb-0.0.bin is firmware Should these be in the source? usr/src/tools/tokenize/tokenize.exe: data usr/src/tools/tokenize/forth: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), dynamically linked (uses shared libs), stripped usr/src/tools/ctf/dwarf/i386/libdwarf.cpio.bz2 usr/src/tools/ctf/dwarf/i386/libdwarf.so.1 usr/src/tools/ctf/dwarf/i386/libdwarf.a usr/src/tools/ctf/dwarf/sparc/libdwarf.so.1 Maybe some interesting references for the future.. http://kerneltrap.org/OpenBSD/That_Which_We_Call_Free http://www.openbsd.org/lyrics.html#39 http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/00335.html I didn't mean to ruffle feathers, but on first glance and read the license makes it look very ugly and solely like a binary. Is there a kernel developer policy on this anywhere?
