UEFI 2.4 has been out for a while (18 months to be exact). However, it’s taken me a while to redo the tianocore builds for the 2.4 base. This is now done, so the OVMF packages are now building 2.4 roms
https://build.opensuse.org/package/show/home:jejb1:UEFI/OVMF
Please remember that this is bleeding edge. I found a few bugs while testing the tools, so there are likely many more lurking in there. I’ve also updated the tools package
https://build.opensuse.org/package/show/home:jejb1:UEFI/efitools
As of version 1.5.1, there’s a new generator for hashed revocation certificates and KeyTool now supports the timestamp signature database. I’ve also published a version of sbsigntools
https://build.opensuse.org/package/show/home:jejb1:UEFI/sbsigntools
Which, as of 0.7, has support for multiple signatures.
Any chance the non-free license for the FAT driver will be changed any time soon?
I’m not sure what you mean by “non-free”. The additional terms in the licence seem to me to be consistent with the DFSG.
The “Additional terms” section at the bottom of the license seems to state that it can only be used to implement EFI/UEFI, such a restriction is probably a violation of the DFSG.
If you compare the licence against DFSG: Section 3 says you must allow derivative works and modifications to be made and distributed under the same terms … the terms are they must be implementing UEFI, so that seems to be OK. Sections 5,6,8,9 prohibit certain effects of the terms, but implementing UEFI seems to be consistent with them all.
I would interpret
“all derivative works thereof being used for and designed only to read
and/or write to a file system that is directly managed by Intel’s
Extensible Firmware Initiative (EFI) Specification”
as discrimination against a field of endeavor, a violation of section 6.
OK, so this is where we differ. A field of endeavour restriction to me means that you’re prohibited from using the work in a particular field of endeavour, like Banking or Rocketry or Nuclear science. A restriction to conform to a particular specification would only be a field of endeavour restriction if the specification itself had such a restriction. UEFI has no such restriction, so UEFI can be used in any field of endeavour.
You can ask debian-legal for an opinion if you’re interested.
I just forked it and I have modified it to not work with UEFI. Is that a violation of the license?
If so, the license does not allow for modification.
Also this part “and to create firmware, applications, utilities and/or drivers.” could be interpreted as restricting use.
> I just forked it and I have modified it to not work with UEFI. Is that a violation of the license?
Yes, because the licence says it must be implementing the UEFI spec so you modified it not in conformance with the licence.
> If so, the license does not allow for modification.
It doesn’t allow arbitrary modification (no licence actually does). However, DFSG 3 only requires modifications allowing redistribution under the licence. If you violate the licence to make the modification, then no, you can’t (in the same way you can’t modify a GPL programme and not provide the modified source).
> Also this part “and to create firmware, applications, utilities and/or drivers.” could be interpreted as restricting use.
Not really … it’s not a restriction. It’s actually a relaxation of the restriction on implementing UEFI specification.
However, this is is really just splitting hairs. The real question is does a licence that allows modifications but requires you to implement a standard conform to the DFSG. I think it does because there’s no prohibition on this type of restriction in the clauses that try to regulate restrictions, but others may have different opinions.
By Karen 2013 年 03 月 22 日 – 22:18:41I have iMac 27 late 2009,mountain lion os. Try to install win7 via boot camp but fail beuscae the Mac cannot detect the windows installer disc. The win7 installer disc can be read in pc and the iMac DVD drive can read other disc.Pls advise, thanks
The license is considered non-free under Fedora guidelines, FWIW. I’d expect Debian would make the same determination.
Pingback: Las herramientas « UEFI Secure Boot Tools » han sido actualizadas a la versión 2.4 | Gustavo Pimentel's GNU/Linux Blog
Aren’t the patents for FAT close to expiring by now?
There appears to be a bug in the efitools 1.5.x timestamp month field for sign-efi-sig-list tool. The tool is currently generating month values in the range of 0 to 11 but the UEFI spec uses values 1-12. This causes a problem for January dates in particular because secure boot initialized with a month 0 key cannot be later appended or replaced (at least my AMI UEFI will not allow it). I think adding one to the timestamp.Month value (timestamp.Month = tm->tm_mon + 1;) should fix this.
Yes, that’s a problem. I just put this fix for it into the repository. Hopefully that will fix the problem and I’ll do another release of the tools shortly.