> I don’t understand the issue BSD licensed code? > It should be compatible with the GPL? > The GPL code could merge bug fixes from the BSD > source base as needed. It is just the BDS source > base that can not take back GPL code.
I'm not sure I understand, I presume you understand all BSD/GPL licensing issues very well. :-) Sure, mixture of licenses makes life more difficult. Not an excuse for ignoring non-BSD innovations and embracing Linux OSV/OEM community with their preferred license. GPL'ed LibreOffice bugfixes can't go upstream to BSD-like, ASF2 license of Apache OpenOffice, but that's life. Even with BSD licensed code, vendor's often don't contribute bugs back, look at XNU. Issue: Linux community uses often uses GPL, UEFI Forum and Tianocore forbids any but BSD (except gives Microsoft freedom to pick any license they want for FAT). Windows and OSX aside, for FOSS OSVs, like FreeBSD and Linux-based ones, the open source community often uses open source licenses other than BSD, including GPL. All of that community contributions are lost to TIanocore and UEFI Forum. And to closed-source IBVs who can't handle GPL taint exposing their code. I'd hope that any new code that the Linux/FreeBSD/FOSS OS community needs could be BSD-licensed, so it could be upstreamed to Tianocore, if they deem to approve it. An IBV (or other group) that helps direct any open source contributions could help manage that. Ungroomed community contributions are much more likely to be unusable by BSD-centric subset of firmware community. Apple and Microsoft are last in the list of big players that don't properly leverage open source community contributions, along with silicon vendors, all of which control UEFI Forum, so likely no change there. :-( >> Look at the coreboot blog, the other week the Purism BIOS developer was >> talking about a "Free Software port of FSP". That should be a shared >> effort by all Linux OEMs/vendors, not shouldered by a single OEM. A >> Linux-centric IBV could be getting help from multiple companies -- like >> Linaro does with ARM -- to help with this effort. It could be part of >> Linux Foundation's Core Infrastructure Initiative, maybe. >> >> They should also tailor Linux-friendly ACPI, like recent thread about >> Linux standardization of _DSD. As well as not include a WBPT table in >> Linux OEM systems, and look at the other tables to see what's should be >> removed. >> > > In general it is not good form to discuss pre-released industry standard > stuff not on the standards group mailing list. The idea is to not have folks > implementing pre released stuff that causes interoperability issues. Sorry, I don't understand this comment. Nothing I mentioned above was pre-released. Coreboot blog post was public. _DSD mailing list post was public. I'm not on any non-public firmware communities. The UEFI Forum only has 1 community, EDK2-devel, to go to for experience. I'd love to see a non-dev discussion list, where I could mention some stifling firmware patent issues that scare me, which I've omitted from discussing on a list with engineers eager to stay ignorant with patents so they can more easily patent more things. :-) >> Alternately, the UEFI Forum should create a non-BSD tree to contain >> this, not just focus on BSD for the fully-closed-source end of the >> spectrum, and work with some FOSS-centric OSVs to better support UEFI >> using their community's models. >> > > The UEFI Forum only publishes the UEFI tests, SCTs. The UEFI Forum > owns the specifications, but does not own or advocate for implementations > (other than advocating conformance to the specification). I guess you could frame it that way. The UEFI forum maintains a BSD codebase where non-FOSS OSVs thrive, and GPL OSVs are stifled. If they chose to help FOSS OSVs, the UEFI Forum could choose to also maintain a codebase with other-than-BSD code, and not ignore the non-BSD contributions from the FOSS community. I just mentioned the UEFI Forum could -- if they chose -- also maintain another codebase, where their FOSS ISVs could also use. I expect an IBV would probably be a better choice than UEFI Forum for anything beyond BSD, given current members anti-non-BSD position. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
