On Mon, 18 Jun 2012 15:35:40 +0200 Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > Am 18.06.2012 15:30, schrieb Seth Johnson: > > > > I stand corrected. Jay's point is that Microsoft will be in a > > position to change policy, on either platform. That could happen > > once it is in a position to do so. > > EXACTLY this is the problem > > and wre are playing them in the hands > > * NOW secure boot is optional on x86 > * we support it with the MS keys > * the next HW generation my have it mandatory > * the argument for make it mandatory may be "see, even free OS has no > problem" > > who can make sure that we get forever keys from MS? Nothing in life is sure or forever. ;) > if we take opensource and free software seriously we should not do > anything to bring MS or any other single company in a position > making us depending on their goodwill over the long I don't understand this argument, as if/when MS changed their certification (say for windows 9, as I think it's pretty much impossible for them to change the windows 8 client certification at this point), to require secure boot not be disable-able or disallow client keys to be enrolled, we could simply at that point stop signing our bootloader shim with MS'es key. This is what some would prefer we do now, but right now since you CAN disable secure boot and you CAN enroll your own keys, I think the gains in supporting secure boot outweigh the small (and easily workaroundable) loss in redistribution rights. Additionally, I can't see what MS would gain by making the above changes you posit, and in fact, it would be likely bad for them. IMHO (IANAL), if secure boot was non disableable folks would have a much better case for a class action suit. "This general purpose hardware I bought doesn't work for general purpose computing". As it is now, they could just say "disable secureboot". We really can't know whats going to happen down the road, we can only act on it as we know it. kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel