Bug 258681
Summary: | Review Request: bluez-firmware - Bluetooth firmware distributed by the BlueZ project | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Will Woods <wwoods> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | bugzilla, fedora-package-review, K9, notting, opensource, tcallawa, tuju |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | NotReady | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-04-30 06:01:04 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 182235, 201449 |
Description
Will Woods
2007-08-28 01:04:02 UTC
The source tag should point to a full URL, here it seems that http://downloads.sourceforge.net/bluez/%{name}-%{version}.tar.gz would be the correct one. Did you build this package once for a 64bit arch? There %{_lib} expands to lib64, so maybe configure should be invoked wiht --libdir=/lib, because e.g. the ipw2000 firmware is also everytime in /lib. ./configure --libdir=/%{_lib} [...] /lib/firmware/BCM-LEGAL.txt Changed the spec to match your suggestions, thanks. New files: Spec URL: http://wwoods.fedorapeople.org/review/bluez-firmware.spec SRPM URL: http://wwoods.fedorapeople.org/review/bluez-firmware-1.2-2.src.rpm - rpmlint: ok E: bluez-firmware hardcoded-library-path /lib in configure options this is intended and ok here. - Naming: ok - license: bad There is no indication that this package is redistributable, there is only contact information for the broadcom firmware but no information at all for the ST Microelectronics firmware. I guess this review should block FE-Legal or you should make upstream include license information for the firmware that states that redistribution is allowed. The link to packages.debian.org is imho not enough. 1cc3cefad872e937e05de5a0a2b390dd bluez-firmware-1.2.tar.gz 1cc3cefad872e937e05de5a0a2b390dd bluez-firmware-1.2.tar.gz.1 Suggestion: You can use %%{_lib} in %changelog to show the full name of the _lib macro. At Mark Webbink's suggestion, I've added a BCM2033-license.txt file that will further explain the agreement with Broadcom. He is currently in contact with Broadcom Legal and will advise on how to proceed there. As for the ST Microelectronics firmware, I can't find any information anywhere regarding its licensing. Upstream believes that both sets of firmware are freely distributable, but did not give any details beyond the email exchange that's reproduced in the link on packages.debian.org. Updated spec: http://wwoods.fedorapeople.org/review/bluez-firmware.spec Updated SRPM: http://wwoods.fedorapeople.org/review/bluez-firmware-1.2-3.src.rpm Yeah, that license is not "freely redistributable", which fails to meet the criteria for firmware: http://fedoraproject.org/wiki/Licensing/#BinaryFirmware Well, that license was added at Mark Webbink's suggestion; since it's not part of the upstream source I can just drop it. The best thing would be a statement from Broadcom Legal saying that redistribution of their firmware is explicitly permitted. But I haven't been able to get a response from them. The debian copyright info file (see comment #1) says: "The BlueZ project has permission from Broadcom Corporation to distribute this firmware in conjunction with the BlueZ GPLd tools, available in Debian as bluez-utils, as long as the notice contained in /usr/share/doc/bluez-firmware/BCM-LEGAL.txt accompanies the firmware." So - maybe these files are freely redisitributable *if* we put them in the bluez-utils package. Or maybe we're OK as long as we're also shipping bluez-utils. Guess I'll try emailing broadcom again. You could try to ask BlueZ project instead ? (to ask Broadcom ). This method seems to work better in some case. (already experienced with Ralinks). Did anything ever happen with this package? I think bluez itself was submitted recently; doesn't it need this firmware? Re comment #7 - I *did* ask the BlueZ maintainer, and he told me that he believed that the license granted to Debian covered redistribution for any party. But he's not a lawyer. Re comment #8 - This package is only needed for certain bluetooth chipsets, primarily those using the bcm203x driver. It also includes firmware for some ST Microsystems bluetooth devices, but we don't appear to ship a driver that requires that firmware - at least not in F9. Without some word from Broadcom, I don't think we can safely move forward here. Will, any word from Broadcom? Still haven't heard anything. I guess I could try again but they don't seem particularly eager to talk to me about firmware distribution. I just want to note that Broadcom's pre-existing agreement seems to cover this case: "The BlueZ project has permission from Broadcom Corporation to distribute this firmware in conjunction with the BlueZ GPLd tools ... as long as the notice contained in /usr/share/doc/bluez-firmware/BCM-LEGAL.txt accompanies the firmware." To me it seems fairly clear - freely redistributable, so long as that file is included. But I'm still not a lawyer. So I'd suggest that someone who *is* a lawyer email the folks listed in the message from comment #1: http://packages.debian.org/changelogs/pool/non-free/b/bluez-firmware/bluez-firmware_1.2-1/bluez-firmware.copyright and get someone to confirm that. Will, the problem here is that we do not have permission to distribute that firmware without it being "in conjunction with the BlueZ GPLd tools". Putting that firmware in a separate "bluez-firmware" package would violate that license, thus, it is not freely redistributable. We need permission from Broadcom to be able to distribute this firmware without any sort of "bundling" restrictions. So, 15 months later, can we make any progress or should this just be closed out? Closed FE-DEADREVIEW. *** Bug 849339 has been marked as a duplicate of this bug. *** |