> On Sep 10, 2015, at 7:22 AM, Blibbet <blib...@gmail.com> wrote: > > >> 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. > > I spent the night trying to figure out how I probably misunderstand > Andrew's BSD/GPL comments yesterday. :-( > > When I think of GPL additions to Tiano, I am thinking new modules, > ProtoeonOSPkg, NanoBsdPkg, RefindPkg, new file systms, new smartcard > drivers, etc. I'm thinklng less of GPL forks of existing Tiano BSD > modules. Unlike the Apache OpenOffice/LibreOffice situation, any GPL > variant would have some control over the shared Tiano code and could > encourage BSD contributions to the shared code. Some forks may be > necessary, but unlike AOO/AOO it is a single community and the common > upstream code would be in interest of both communities. Back to the > AOO/LO example, it is not just two separate communities. Some developers > contribute patches to both codebases, which helps unify the two. There > are problems when mixing code of two licenses.
I think we seem to be agreeing. The thing that makes the most sense seems to be keeping a common edk2 BSD project that is as compatible as possible with all the down stream customers. There have historically been closed source down stream customers of the edk2, and some of them even contribute back fixes to the edk2 BSD project. Now we are getting GPL down stream customers having a close working relationship with the primary down stream GPL project, and having some folks that could span the world and post back BSD patches to the edk2 BSD project is probably the best we can achieve. Having the two projects means some innovation in the GPL project may not be available to every one, but the reality is all the down stream customer will have the choice to use the down stream GPL innovation if they want to play by the GPL rules. > But ignoring GPL is MUCH > harder for Linux OSVs than it is for closed-source ISVs. Long-term, I > don't see how Linux OSVs can properly use UEFI without a Linux-aware IBV. > From those of us coming from the PC industry standard world this is kind of hard to parse. Industry standards, and a lot of work, have enabled Linux to boot a massive number and diversity of platforms in todays world…. I assume you are making a point about customers who want all the firmware to be Free Software? I don’t think the edk2 BSD project or the industry standards hurt or help. Free Software advocates seem to think it hurts, but you know there a lot of property code floating around that is based on the edk2/standards. Seems to me all you need to do is copy paste the header to change the license, so it is really just up to the owner of the IP…. Thanks, Andrew Fish PS Sorry I got a little off the rails yesterday. I got baited into a ridiculous argument about mixing BSD and GPL code together, and I should have just ignored it. > Thanks, > Lee > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=s2DXhS4W0NGU6kgZXmUeH12tq0DgY2brl-RBjO5PSew&s=TGxSjSIELDlyaqhK_83ZV63Yqb_Ka5rXnRfg5SDh_h4&e= > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
