We did some discussion at the board meeting last week about firmware images, such as that used for ipw2200. The decision was made that we're OK with shipping these firmware images based on the guidelines currently in the packaging guidelines:
* The files are non-executable (note: this means that the files cannot run on their own, not that they are just chmod -x)
* The files are not libraries.
* The files are standalone, not embedded in executable or library code.
* Explicit permission is given by the owner to freely redistribute without restrictions (this permission must be included, in "writing", with the files in the packaging)
* The files must be necessary for the functionality of open source code being included in Fedora.
However, these packages will not be (in many cases) fully open source - while they're distributable, the licenses do not permit modification, reverse engineering, etc. So we want to make sure that these packages are easily queryable/findable.
Proposal:
1) Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag) 2) The License tag for any firmware that disallows modification should be set to:
"Redistributable firmware, no modification permitted"
Comments? Note that there is other firmware (zd* USB devices, etc) that is under GPL and wouldn't need this license tag.
Bill
Bill Nottingham wrote:
- Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag)
I think it's reasonable to keep them in the Kernel group.
- The License tag for any firmware that disallows modification should be set to:
"Redistributable firmware, no modification permitted"
Reasonable also.
Comments? Note that there is other firmware (zd* USB devices, etc) that is under GPL and wouldn't need this license tag.
I'm modifying upstream module-init-tools so we can additionally pick up firmware dependency information from modules using modinfo. This will allow us to build initrd images with the correct firmware files inside without including a bazillion optional firmware files for good measure.
Actually, the upstream kernel has only 2 drivers currently using the MODULE_FIRMWARE tag needed so we'll want to encourage that. I told Jeremy the other day that I'm not so worried about ipw2200 because - to be honest - the idea of someone doing a bootpath iSCSI install over IPW makes me want to put my fingers in my ears and sing "la..la..la". But if you've got pet drivers that need "fixing" upstream, now's the time...
Jon.
On 13.02.2007 03:55, Jon Masters wrote:
Bill Nottingham wrote:
- Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag)
I think it's reasonable to keep them in the Kernel group.
I disagree a small bit -- what if we for example start to ship Firmwares for Scanners? They depend on sane, and have nearly have nothing to do with the kernel...
But it's probably a corner case we maybe should simply ignore...
[...]
CU thl
On Tue, Feb 13, 2007 at 06:50:17AM +0100, Thorsten Leemhuis wrote:
On 13.02.2007 03:55, Jon Masters wrote:
Bill Nottingham wrote:
- Firmware packages are given the Group: tag of System Environment/Kernel
(unless we want to make up a new 'Firmware' tag)
I think it's reasonable to keep them in the Kernel group.
I disagree a small bit -- what if we for example start to ship Firmwares for Scanners? They depend on sane, and have nearly have nothing to do with the kernel...
Good catch. Perhaps the tag should be just a suggestion and the packager should be able to use something else. Although, which entry in /usr/share/doc/rpm-*/GROUPS might apply to a scanner firmware?
Perhaps firmware should get their own Group tag different from /usr/share/doc/rpm-*/GROUPS. It would make them easy to filter out, too, which was one of Bill's topics.
But it's probably a corner case we maybe should simply ignore...
No, I think you made a good example, better to lay down a proper layout now, than to reengineer it later.
[...]
CU thl
"BN" == Bill Nottingham notting@redhat.com writes:
BN> 1) Firmware packages are given the Group: tag of System BN> Environment/Kernel (unless we want to make up a new 'Firmware' BN> tag)
I don't see why we wouldn't, given the nearly meaningless nature of Group at the moment.
BN> The License tag for any firmware that disallows modification BN> should be set to:
BN> "Redistributable firmware, no modification permitted"
This seems reasonable. I'm not sure what point coming up with mnemonics for the actual license text would be when the above text succinctly sums up the end-user's rights.
- J<
On Mon, 2007-02-12 at 20:52 -0500, Bill Nottingham wrote:
Proposal:
- Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag)
This is fine. As I've said before, we don't have any guidelines on setting Group properly. You can put "Giant Flying Alligator" in there for all I care.
- The License tag for any firmware that disallows modification should be set to:
"Redistributable firmware, no modification permitted"
Seems right to me.
~spot
On Mon, 2007-02-12 at 20:52 -0500, Bill Nottingham wrote:
We did some discussion at the board meeting last week about firmware images, such as that used for ipw2200. The decision was made that we're OK with shipping these firmware images based on the guidelines currently in the packaging guidelines:
However, these packages will not be (in many cases) fully open source - while they're distributable, the licenses do not permit modification, reverse engineering, etc. So we want to make sure that these packages are easily queryable/findable.
Proposal:
- Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag)
- The License tag for any firmware that disallows modification should be set to:
"Redistributable firmware, no modification permitted"
Comments?
-1, for several reasons:
1. Generally speaking, the "no modifications" goes too far for my taste and is in conflict with Fedora's objectives.
We should stick with "shipping/redistributing binaries (prebuilt binaries) is allowed, provided they are Open-Source (source-code available and modifiable)".
2. "no-mods-allowed" firmware is a controversial corner case wrt. licensing: Is a GPL'ed kernel-module using a "no-mods-allowed" firmware image, legal? "Under which kind of usages" is this legal and when not?
3. The definition of firmware in the FPG is weak. This had been discussed several times before, but IIRC, so far, nobody has been able to come up with a better one (Where does "firmware" end and other "general binary data" start, why should firmware be a special exception from the rules being applied to binaries elsewhere?)
Ralf
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> 1. Generally speaking, the "no modifications" goes too far for my RC> taste and is in conflict with Fedora's objectives.
This and the rest of the points you raise are off-topic for this discussion and beyond our scope as a committee; the board has already decided that this is not in conflict with Fedora's objectives, and is asking is for guidelines on what the specfiles should look like. If you want to have the type of discussion you're looking for, please take it to the board.
- J<
Bill Nottingham wrote :
Proposal:
- Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag)
- The License tag for any firmware that disallows modification should be set to:
"Redistributable firmware, no modification permitted"
Comments? Note that there is other firmware (zd* USB devices, etc) that is under GPL and wouldn't need this license tag.
Seems fine to me. Definitely a big win for end users, and not such a bad compromise overall, although I'd prefer hardware vendors putting firmwares back where they belong... in the hardware... for good, not on every driver load ;-p
For the ipw2100 and ipw2200 firmwares, do updated written permissions still need to be obtained from Intel, or do the current ones match these new guidelines? (I'm asking because I always thought they both were fine, but they weren't)
Matthias
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
For the ipw2100 and ipw2200 firmwares, do updated written permissions still need to be obtained from Intel, or do the current ones match these new guidelines? (I'm asking because I always thought they both were fine, but they weren't)
The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this is a change.)
Bill
On Tuesday, 13 February 2007 at 18:01, Bill Nottingham wrote:
Matthias Saou (thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said:
For the ipw2100 and ipw2200 firmwares, do updated written permissions still need to be obtained from Intel, or do the current ones match these new guidelines? (I'm asking because I always thought they both were fine, but they weren't)
The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this is a change.)
If that is correct, why are #217350 and #217351 still blocking FE-Legal?
Regards, R.
On Tuesday, 13 February 2007 at 19:53, Bill Nottingham wrote:
Dominik 'Rathann' Mierzejewski (dominik@greysector.net) said:
The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this is a change.)
If that is correct, why are #217350 and #217351 still blocking FE-Legal?
'Cos I'm a slowpoke? Feel free to remove the block.
Why, thank you! Removing now.
Regards, R.
Matthias Saou wrote:
Seems fine to me. Definitely a big win for end users, and not such a bad compromise overall, although I'd prefer hardware vendors putting firmwares back where they belong... in the hardware... for good, not on every driver load ;-p
Actually, logically these folks are doing the right thing.
Having firmware *in* the hardware works when you've got years to design the hardware and then have guaranteed sales for years after that. But, these days, hardware manufacturers need to make rapid changes and fix bugs/add new features after release. Not allowing them to do that is like saying "you can never release an update for F7, no matter what breaks" - it's not realistic :-)
So, actually, we should be working to make using loadable firmware easier - because it's going to become much *much* more common.
Jon.
On Tue, Feb 13, 2007 at 12:20:31PM -0500, Jon Masters wrote:
Actually, logically these folks are doing the right thing.
Having firmware *in* the hardware works when you've got years to design the hardware and then have guaranteed sales for years after that. But, these days, hardware manufacturers need to make rapid changes and fix bugs/add new features after release. Not allowing them to do that is like saying "you can never release an update for F7, no matter what breaks" - it's not realistic :-)
So, actually, we should be working to make using loadable firmware easier - because it's going to become much *much* more common.
in other words, from a manufacturer's perspective, disk space is less expensive than flash, because the customer pays for the disk, where you pay for the flash. :-)
Matt Domsch wrote:
in other words, from a manufacturer's perspective, disk space is less expensive than flash, because the customer pays for the disk, where you pay for the flash. :-)
Yup.
There are exceptions to this of course. I used to build NMR (MRI) systems running Linux on custom FPGA platforms we "flashed" via a SystemAce (a magic device from Xilinx - a CompactFlash reader device to Linux, a hardware programmer at other times) that we could use to say "hey, let's redefine the entire hardware platform, replace the firmware, and the kernel and the userland" in one operation...takes...guts.
Jon.
On Mon, Feb 12, 2007 at 08:52:58PM -0500, Bill Nottingham wrote:
- Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag)
I'm for the new tag. Then we can start consolidating all the useless ones into simple classifications like this.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Dominik 'Rathann' Mierzejewski -
Jason L Tibbitts III -
Jon Masters -
Matt Domsch -
Matthew Miller -
Matthias Saou -
Ralf Corsepius -
Thorsten Leemhuis -
Tom Callaway