Milan Jurik wrote: > Hi, > > "C. Bergstr?m" p??e v p? 15. 05. 2009 v 19:35 +0300: > >> 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) >> >> > > I understand your concerns but I do not see benefit for separating it > from the source tree. Many drivers will just stop to work without this > firmware, or old, crappy, buggy original firmware from ROM on the card > will be used. By separating these blobs from source tree you will > receive nothing, only complicate building/maintainance of the source > tree. > > >> 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./" >> >> > > I do not see how this statement has something with the problem of binary > blobs (which can be firmware microcode or just set of some values) in > our source tree. > > >> 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. >> >> > > I think both are possible security risk but I do not still see the > benefit to separate such files from the source tree. If you are afraid > of them, then you can maintain the list of OS parts which depends on > them and do not distribute in your distribution. > > >> 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? >> >> > > I am not aware of some policy around binary blobs. Again, I do not see > benefit in pushing these blobs outside of the source tree, they are not > problem there. They can be problem for some distros, of course. > > In the last email I was more or less agreeing that in practice distributions, even openbsd, allow firmware, but not blobs. With this I'm /wrong/ about my original point and now more or less indifferent about what's there now. The other stuff mentioned is all freely available in source and should probably be replaced with source, but that's a janitor item for a package maintainer or bored gatelining. The fact that a Sun employee may have seen the original source for the microcode and it's then shipped under a binary only license in binary form still makes me look at it as something that should be a part of closed bins. If I'm not mistaken it would simply be changing a path to where elfwrap points in the build process. (I'd have to look at the build log and may be completely wrong) Doesn't matter and a dead thread, because I doubt anyone on this list finds it important.
Apologies for the noise. ./C
