[U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Fri, Jan 15, 2016 at 04:00:21AM +0100, Alexander Graf wrote:
> 
> 
> On 25.12.15 17:50, Tom Rini wrote:
> > 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!
> 
> I've just read up and apparently it's completely legal and allowed to
> simply remove the LGPL (2.1+) boilerplate from a file and instead put a
> GPL (2.0+) one on it, even if you didn't write the code.

Legal and good idea don't always match up :)

> So even if I had insisted to stick to LGPL v2.1+, you could've just
> written a patch to change it after the fact ;).
> 
> But since everyone seems to be far more happy with GPL rather than LGPL,
> I've spared you that patch and changed the headers myself now.

Thanks, I appreciate it!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160114/1b8e2ec4/attachment.sig>