From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 25 Dec 2015 12:00:40 -0500 Subject: [U-Boot] [PATCH 0/9] EFI payload / application support In-Reply-To: References: <1450792676-109541-1-git-send-email-agraf@suse.de> <20151225032939.GA4093@bill-the-cat> <567D0402.6040606@suse.de> <20151225165018.GB4093@bill-the-cat> Message-ID: <20151225170040.GD4093@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Dec 25, 2015 at 07:53:24PM +0300, Matwey V. Kornilov wrote: > 2015-12-25 19:50 GMT+03:00 Tom Rini : > > On Fri, Dec 25, 2015 at 09:53:22AM +0100, Alexander Graf wrote: > >> > >> > >> On 25.12.15 04:29, Tom Rini wrote: > >> > On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote: > >> > > >> >> This is my Christmas present for my openSUSE friends :). > >> >> > >> >> U-Boot is a great project for embedded devices. However, convincing > >> >> everyone involved that only for "a few oddball ARM devices" we need to > >> >> support different configuration formats from grub2 when all other platforms > >> >> (PPC, System Z, x86) are standardized on a single format is a nightmare. > >> >> > >> >> So we started to explore alternatives. At first, people tried to get > >> >> grub2 running using the u-boot api interface. However, FWIW that one > >> >> doesn't support relocations, so you need to know where to link grub2 to > >> >> at compile time. It also seems to be broken more often than not. And on > >> >> top of it all, it's a one-off interface, so yet another thing to maintain. > >> >> > >> >> That led to a nifty idea. What if we can just implement the EFI application > >> >> protocol on top of U-Boot? Then we could compile a single grub2 binary for > >> >> uEFI based systems and U-Boot based systems and as soon as that one's loaded, > >> >> everything looks and feels (almost) the same. > >> >> > >> >> This patch set is the result of pursuing this endeavor. > >> > > >> > So, I owe the whole codebase a real review. My very quick question > >> > however is, aside from what you had to borrow from wine, can you license > >> > everything else as GPL v2 or later rather than LGPL? > >> > >> I'm personally a pretty big fan of the LGPL, since it's a very > >> reasonable compromise between closed and open source IMHO ;). > >> > >> Is there a particular reason you're asking for this? LGPL code is fully > >> compatible with GPL code and the resulting binary would be GPL anyway > >> because FWIW you can't compile U-Boot without GPL code inside. > > > > The general rules for U-Boot code are to be GPL v2 or later. U-Boot is > > (and always will be) a GPL v2 only project as there's simply too much > > Linux kernel code that we want to leverage. We do make special > > exceptions at times for very good reasons (like include/android_image.h > > is the authorative BSD-2 clause copy of that information) and I've even > > told some companies that for crypto-auth-sensitive stuff they can do GPL > > v2 only in their submission (again, due to U-Boot always being a v2 only > > project). > > > > So, I'm not gonig to reject the EFI loader code if you say no, you won't > > re-license it as GPL v2 (or v2 and later) but I'd really appreciate it. > > Thanks! > > If EFI loader is GPLed, then is it possible to use it to run non-GPLed > (proprietary) EFI applications? Yes. Absolutely. We've (pratically) always supported running non-GPL payloads. VxWorks has been supported for ages and ages and ages for example. There may be a thought experiment or two required about callbacks but that's part of why we've had CONFIG_API, iirc. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: