> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-09-09 16:05:20, Andrew Fish wrote: >> >>> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: >>> >>> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: >>>> The recent expansions beyond BSD where all permissive licenses (BSD >>>> like) as far as I can tell. >>>> >>>> I agree with Andrew, opening the door for GPL licensed code in EDK2 >>>> will have severe consequences for products that are built using >>>> EDK2. >>> >>> I don't think simply having a GplDriverPkg in the tree would have any >>> consequences for a platform that doesn't use any code in that package. >>> Obviously we could not make any core packages rely on that package. >>> >> >> So you have a legal degree and are speaking on behalf of your >> employer on this subject? > > No and no. How about you? :) >
No but I have to review any code contributed to the open source project to make sure it follows the corporate polices. > Nevertheless, I have not heard the interpretation that just having GPL > in a source tree would impact your code, even if you do not include, > nor link to it. Is this Apple's interpretation of how GPL works? > No but thanks for making my point for me. 1st off the rules are made by lawyers and managers so you trying to argue logic is kind of funny. What does logic have to do with it. Your company started this edk2 project as a BSD project, and I assume there was a reason for that. The reasons rules like this end up getting made is that developers like you are confused about the company policy regarding open source, closed source and protecting intellectual property rights. So your very smart and well versed and you are confused, so some more jr. engineer has no hope of getting it right and would copy the GPL code and be clueless to what he just did. As I always say a development process exists to slow down the best developer, at the price of preventing the most jr. developers from doing something stupid. >>> FWIW, I don't mind if the consensus is that GplDriverPkg must live in >>> a separate repo. But, it would be nice to hear a good reason why it >>> must live elsewhere. >> >> Because GPL is not a permissive license. An accidental git grep and >> copying some code can change the license of the code that gets the >> GPL code pasted into it. > > I like this argument. It is slightly tempered by the fact that git > grep always shows the source path, and thus 'GplDriverPkg' would be > obviously visible. > If the developer is even paying attention, or using a tool that highlights path vs. filename. Or maybe the path is too long to display and gets shortened in a way that Gpl is not obvious. Not to mention if this was so easy why not include the source for the FAT driver with the GPL sources? We could add EvilNonGplCompatibleLicence to the path and that would solve everything. >> Thus having GPL code in the same repository as BSD code can end up >> accidentally converting BSD code to GPL code over time. > > I would be more worried about the GPL based drivers becoming too > featureful over time, and the permissively licensed code not being > very useful. For example, I'm worried that the non-GPL OVMF may end up > missing a lot of features. > Then logically you should just make OVMF a GPL project? Thanks, Andrew Fish > -Jordan > _______________________________________________ > edk2-devel mailing list > edk2-de...@lists.01.org <mailto:edk2-de...@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=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU&s=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E&e= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU&s=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E&e=>
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
