Spec URL: http://ftp.es6.freshrpms.net/tmp/extras/ SRPM URL: http://ftp.es6.freshrpms.net/pub/freshrpms/fedora/linux/6/ipw2100-firmware/ Description: This package contains the firmware files required by the ipw2100 driver for Linux. Usage of the firmware is subject to the terms and conditions contained in /lib/firmware/LICENSE.ipw2100. Please read it carefully. -- The content of this package seems to meet the "binary firmware" exception of the packaging guidelines, thus should be suitable for inclusion into Extras.
License is not currently acceptable as posted.
Bill, would you be so kind as to explain why? I've read all of the LICENSE file again and again, and don't see anything incompatible with the current "binary firmware" exception, so I must be missing something. Some of the relevant parts : "For OEMs, IHVs, and ISVs: [...] (ii) copy and distribute the Software to your end-users, but only under a license agreement with terms at least as restrictive as those contained in Intel's Final, Single User License Agreement, attached as Exhibit A" "Your rights to redistribute the Software shall be contingent upon your installation of this Agreement in its entirety in the same directory as the Software." (which is why the package puts the LICENSE in the same directory as the firmware itself) I see that sub-licensing is clearly forbidden, is this the problem? I don't think we sub-license, but rather redistribute with the same license, which shouldn't be a problem. But of course, IANAL and probably don't understand all these legal terms properly...
Bill, please also read: http://ipw2100.sourceforge.net/firmware_faq.php .
My understanding of the FAQ linked by Dominik is that if we package the LICENSE fail as both %doc and in the same directory as the firmware, as well as including an explicit notification of this in the %description, then we are in compliance with Intel's redistribution licensing. IANAL however, and proper legal counsel should be sought to verify whether or not this is enough for Fedora Extras inclusion.
IANAL as well, but given the point A1.2 in the FAQ the package seems acceptable, _BUT_ with an improved description. As it stands now, it does not seems to comply with: "any description within the package must indicate that the package is covered by the Intel license, and provide the user with information on how to access that license -- making it clear that the user is not granted a license to use the package unless these terms are agreed to."
How does this %decription seem : This package contains the firmware files required by the Intel® PRO/Wireless 2100 (ipw2100) driver for Linux. IMPORTANT NOTICE : This package is covered by the Intel® license found in the /lib/firmware/LICENSE.ipw2100 file. Usage of this package requires agreeing to the terms of the Intel® license.
Yes, this revised description seems to fulfill the license requirements. What else should we do before we can accept this for inclusion?
Maybe wait for a further comment from Bill? I initially thought he meant that the Intel license was unacceptable, but now I think he might have meant that the current package was unacceptable (probably because the %description didn't indicate that accepting the license was mandatory). Bill, would you care to comment quickly?
Sure, make all the commentary in the bug I'm *not* originally CC'd on. :P Warning, I'm not fedora-legal, but: 1 - End-users aren't explicitly given distribution or redistribution rights (they aren't disallowed them, either.) As adherence to that is required for ISVs (which Fedora is), that's a problem. 2 - The contractors provision is just weird. There may have been something else I missed. Basically, we don't doubt that the *intent* of Intel is for it to be redistributable. However, the license *text* isn't quite usable in that regards - what we want is a release of the firmware under a clarified license, or under something similar to the ipw3945 license.
What do you propose then? That someone should ask Intel to clarify the license text inside the tarballs (same applies to ipw2200-firmware, too - bug #217351). Who should that be? Matthias or someone from fedora-legal? Should I block FE-Legal here until then?
Probably FE-Legal, yes. We'd like a clarified license text inside the tarballs.
This was discussed at some length yesterday. The firmware FAQ as posted is not enough, as it does not (at minimum) have any attribution that actually states it comes from the copyright holder/licensor; this would need fixed before it could be considered freely redistributable. (i.e., the statement needs to clearly come *from Intel*, not just a page @ SF that Intel presumably edits.) Aside from that, we noted that the EULA for Fedora Core states: 1. THE SOFTWARE. Fedora Core (the "Software") is a modular Linux operating system consisting of hundreds of software components. The end user license agreement for each component is located in the component's source code. With the exception of certain image files containing the Fedora trademark identified in Section 2 below, the license terms for the components permit User to copy, modify, and redistribute the component, in both source code and binary code forms. ... Note the 'modify' and 'source code and binary code' sections above. Obviously, we don't want to break our own EULA. The Fedora board is planning to look into how to address this issue at the upcoming FUDCon in Boston; the outcome of this will probably be alterations of the firmware guidelines and something more clear as to whether or not this is acceptable.
Thanks for sharing all this with us Bill. I'll wait to know the outcome of the FUDCon discussions.
Green light from Bill, removing FE-Legal.
All set for a formal review, then. Updated packages here (minor cleanups) : http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ipw2100-firmware-1.3-4.src.rpm http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ipw2100-firmware.spec
http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ipw2100-firmware-1.3-5.src.rpm http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ipw2100-firmware.spec * Wed Feb 14 2007 Matthias Saou <http://freshrpms.net> 1.3-5 - Don't mark the LICENSE in /lib/firmware as %%doc since it could be excluded when using --excludedocs, symlink a file in %%doc to it instead.
Dominik - feel free to jump in, but I thought I'd kick-start it. MUST items: - Package meets naming and packaging guidelines - OK - Spec file matches base package name. - OK - Spec has consistant macro usage. - OK - Meets Packaging Guidelines. - *** ** Group tag should probably be 'Firmware', per discussion on fedora-packaging. - License - OK - License field in spec matches - *** ** Per fedora-packaging discussion, License tag should be 'Redistributable firmware, no modification permitted' - License file included in package - OK - Spec in American English - OK - Spec is legible. - OK - Sources match upstream md5sum: - OK - Package needs ExcludeArch - *** This packge is noarch. However, it is only relevant for certain architectures. Therefore, it may be helpful to add: ExclusiveArch: i386 x86_64 to tell composition tools to only include the package on those arches. - BuildRequires correct - OK - Package has %defattr and permissions on files is good. - OK - Package has a correct %clean section. - OK - Package has correct buildroot - *** It is suggested to change to: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - Package is code or permissible content. - OK - Packages %doc files don't affect runtime. - OK - Package compiles and builds on at least one arch. - OK - Package has no duplicate files in %files. - OK - Package doesn't own any directories other packages own. - OK - Package owns all the directories it creates. - OK - No rpmlint output. - **** source rpmlint: E: ipw2100-firmware hardcoded-library-path in /lib/firmware/LICENSE.ipw2100. W: ipw2100-firmware setup-not-quiet E: ipw2100-firmware hardcoded-library-path in %{buildroot}/lib/firmware E: ipw2100-firmware hardcoded-library-path in %{buildroot}/lib/firmware/ E: ipw2100-firmware hardcoded-library-path in %{buildroot}/lib/firmware/LICENSE.ipw2100 E: ipw2100-firmware hardcoded-library-path in /lib/firmware/LICENSE.ipw2100 E: ipw2100-firmware hardcoded-library-path in /lib/firmware/LICENSE.ipw2100 E: ipw2100-firmware hardcoded-library-path in /lib/firmware/*.fw hardcoded-library-path is OK, as /lib/firmware is the defined dir. Feel free to fix the setup warning. Binary package: W: ipw2100-firmware symlink-should-be-relative /usr/share/doc/ipw2100-firmware-1.3/LICENSE /lib/firmware/LICENSE.ipw2100 Any reason it's a symlink as opposed to just a file? - final provides and requires are sane - OK SHOULD Items: - Should build in mock. - OK - Should build on all supported archs - OK - Should function as described. - not tested - Should have dist tag - OK - Should package latest version - OK
Whoops, it doesn't have a dist tag - feel free to add.
http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ipw2100-firmware-1.3-6.src.rpm http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ipw2100-firmware.spec * Sat Feb 24 2007 Matthias Saou <http://freshrpms.net> 1.3-6 - Fix group and license tags. - Add (partially useful) exclusivearch. - Quiet %%setup. About the LICENSE and the dist tag, see #217351.
http://ftp.es6.freshrpms.net/tmp/extras/ipw2100-firmware/ * Mon Mar 5 2007 Matthias Saou <http://freshrpms.net> 1.3-7 - Change group and license fields to reflect latest firmware guidelines.
Reassigning to myself, to finish review - I want to get this stuff in. Issues in bug addressed, matches approved firmware guidelines - APPROVED. Feel free to request fedora-cvs, and then build when done.
New Package CVS Request ======================= Package Name: ipw2100-firmware Short Description: Firmware for Intel® PRO/Wireless 2100 network adaptors Owners: matthias Branches: devel FC-6 FC-5 EL-5 EL-4 InitialCC:
Thank you, Bill.
Adding to CVS now. Please wait for the next CVS ACL sync at :30 before importing.
All finished. Thanks to all involved! FYI : I've rebuilt the package only for devel (F7) and it has been hardlinked to all the other supported branches. It doesn't make as much sense as for a HUGE noarch package, but since the package will probably not be updated very often (if at all), I think it still does make enough.