On Fri, May 15, 2009 at 07:35:51PM +0300, "C. Bergstr??m" wrote: > 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.
I have no aspirations whatsoever to be anything like the OpenBSD project. There's also a difference in that it's entirely possible that people within Sun have seen the code in the blobs/firmware, something that I feel is unlikely for the OpenBSD developers. > 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 I don't see why not. Feel free to elide them from your distribution. FreeBSD has a BSD licensed libdwarf which you may wish to look at porting. > 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? What license are you referring to? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/on-discuss/attachments/20090515/7580eeb3/attachment.bin>
