> BSD is a GPL compatible licence. > GPL is NOT a BSD compatible licence.
Where is the requirement that all OEMs must only include BSD code in their firmware? Why not let Puri.sm or Novena have a downstream UEFI firmware volume that is GPL, will the world end or something? Today, there is some non-BSD code needed to boot Linux on UEFI. Linux OSVs probably don't have the same fear of GPL that closed-source OS vendors do. You're free to ignore that code and focus on the license subset you prefer. >> What about a Tiano way to distribute [L]GPL code, safely separate from >> main BSD branch, like FAT driver is dealt with, so GPL-friendly >> OSVs/ISVs/OEMs -- everyone but Microsoft? :-) -- can safely use GPL >> code? Perhaps other non-BSD, OSI-approved FOSS licensed, and no others? >> > > As you point out we solve issues with licensing by splitting git repos > and having separate projects. That is probably a separate conversation > from what goes in the edk2 project. I thought the conversation was to deal with this current code contribution, not just focus on EDK2 subproject. What about using TianoCore's EDK2share for non-BSD projects? That code isn't bundled into UDK releases. If contributor can relicense to BSD great, but if not, dropping code is rude, a non-BSD friendly area outside main EDK2 project, somewhere on Tiano, would be better than dropping the code, I'd think. >> Users of this code will also have to face their main hurdle, getting >> Microsoft to bless their EFI code, and their current restrictions >> already hinder any GPL code, which gets worse with each Windows release. > > I don’t really understand that statement. Microsoft does not “bless” firmware code. > The platform vendor can have any firmware implementation they want. I was referring to 'pre-OS' ISVs. For firmware that doesn't come built by OEMs/ODMs/IBVs, Microsoft does bless that firmware code, and UEFI Forum does nothing to help, and Microsoft applies it's own biases and uses it's position to compete with vendors. I'd at least hope that an additional techincal and policy restrictions that Microsoft adds to code would be set by UEFI Forum and not by Microsoft. The Microsoft CA really is an ugly pink elephant for UEFI Forum, and it helps let them continue to be a bully in the Intel playground (except in the Apple corner). And for this case of a smartcard driver, I presume the above Microsoft comment won't apply since a SC driver has to be (?) bundled into main FV, not a separate .efi that Microsoft would need to sign. http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx https://msdn.microsoft.com/en-us/library/windows/hardware/dn609883.aspx#reviewprocess http://techrights.org/2012/06/29/traps-behind-uefi/ http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO http://www.itworld.com/article/2737487/it-management/microsoft-washes-its-hands-of-uefi-linux-mess.html Thanks, Lee ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
