All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/9] EFI payload / application support
Date: Fri, 15 Jan 2016 04:00:21 +0100	[thread overview]
Message-ID: <569860C5.9070307@suse.de> (raw)
In-Reply-To: <20151225165018.GB4093@bill-the-cat>



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.

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.


Alex

  parent reply	other threads:[~2016-01-15  3:00 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 13:57 [U-Boot] [PATCH 0/9] EFI payload / application support Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 1/9] disk/part.c: Expose a list of available block drivers Alexander Graf
2016-01-14 19:18   ` Tom Rini
2016-01-14 23:11   ` Simon Glass
2016-01-14 23:33     ` Alexander Graf
2016-01-15  0:46       ` Simon Glass
2016-01-15  1:04         ` Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 2/9] include/efi_api.h: Add more detailed API definitions Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 3/9] efi_loader: Add PE image loader Alexander Graf
2015-12-26 16:26   ` Leif Lindholm
2016-01-14 23:45     ` Alexander Graf
2016-01-15 12:29       ` Leif Lindholm
2015-12-22 13:57 ` [U-Boot] [PATCH 4/9] efi_loader: Add boot time services Alexander Graf
2015-12-22 14:15   ` Andreas Färber
2015-12-22 14:31     ` Alexander Graf
2015-12-26 18:09   ` Leif Lindholm
2016-01-15  0:13     ` Alexander Graf
2016-01-15 13:02       ` Leif Lindholm
2016-01-15 14:14         ` Alexander Graf
2016-01-15 14:21           ` Leif Lindholm
2016-01-15 17:04             ` Alexander Graf
2016-01-15  3:40     ` Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 5/9] efi_loader: Add console interface Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 6/9] efi_loader: Add runtime services Alexander Graf
2015-12-26 18:33   ` Leif Lindholm
2016-01-15  0:26     ` Alexander Graf
2016-01-15 13:52       ` Leif Lindholm
2016-01-15 14:15         ` Alexander Graf
2016-01-15 14:22           ` Leif Lindholm
2015-12-22 13:57 ` [U-Boot] [PATCH 7/9] efi_loader: Add disk interfaces Alexander Graf
2016-01-15  1:37   ` Simon Glass
2016-01-15  2:40     ` Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command Alexander Graf
2015-12-24 11:15   ` Matwey V. Kornilov
2015-12-25  9:02     ` Alexander Graf
2015-12-25  9:25       ` Andreas Färber
2015-12-25  9:40         ` Matwey V. Kornilov
2015-12-25 17:04           ` Tom Rini
2015-12-26 18:55         ` Leif Lindholm
2015-12-27 15:33           ` Alexander Graf
2015-12-26 18:45       ` Leif Lindholm
2015-12-25 16:58     ` Tom Rini
2015-12-22 13:57 ` [U-Boot] [PATCH 9/9] efi_loader: hook up in build environment Alexander Graf
2015-12-22 18:28 ` [U-Boot] [PATCH 0/9] EFI payload / application support Matwey V. Kornilov
2015-12-22 20:32   ` Alexander Graf
2015-12-25  3:29 ` Tom Rini
2015-12-25  8:53   ` Alexander Graf
2015-12-25 16:50     ` Tom Rini
2015-12-25 16:53       ` Matwey V. Kornilov
2015-12-25 17:00         ` Tom Rini
2016-01-15  3:00       ` Alexander Graf [this message]
2016-01-15  3:06         ` Tom Rini
2015-12-25 19:34 ` Blibbet
2015-12-26 15:31 ` Leif Lindholm
2015-12-26 16:27   ` Alexander Graf
2015-12-26 19:34     ` Leif Lindholm
2016-01-04 16:25       ` Alexander Graf
2016-01-04 16:56         ` Tom Rini
2016-01-04 18:03           ` Andreas Färber
2016-01-04 18:41             ` Andreas Färber
2016-01-04 19:54               ` Tom Rini
2016-01-04 22:37                 ` Dennis Gilmore
2016-01-04 22:48                   ` Alexander Graf
2016-01-15  3:40             ` Peter Robinson
2016-01-04 20:11           ` Matwey V. Kornilov
2016-01-15  3:32           ` Peter Robinson
2015-12-27 18:10   ` Tom Rini
2015-12-27 18:39     ` Leif Lindholm
2015-12-27 19:48       ` Tom Rini
2016-01-05 20:18       ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569860C5.9070307@suse.de \
    --to=agraf@suse.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.