[U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Aaron Williams]

Hi Tom,

________________________________
From: Tom Rini
Sent: Tuesday, November 5, 2019 6:16 AM
To: Wolfgang Denk
Cc: Aaron Williams; Daniel Schwierzeck; u-boot at lists.denx.de
Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support

On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote:
> Dear Aaron,
>
> In message <5376617.97hUrJXovB at flash> you wrote:
> >
> > > Again you don't answer my question.  Why do you need a special new
> > > API for such code?  Why do you not just link that code with the rest
> > > of U-Boot?
> >
> > The code in question that is calling the API is not GPL and hence cannot be
> > linked with U-Boot though the phy code is GPL.
>
> Ouch.  I was afraid to hear that.
>
> Please be aware that your newly created API does NOT implement a GPL
> license exception.  the only interface that allows for non-GPL code
> to be run under control of U-Boot is the standalone program
> interface, which is intentionally very restricted.
>
> In other words: what you are doing here is a clear (and intentional,
> which makes it even worse) GPL license violation.
>
> > > It has been mentioned before, but just to be sure: this code which
> > > uses your new API is licensed under a GPLv2 conforming lincense?
> > >
> > There should be no need. None of the code is linked against U-Boot, either at
> > compile time nor at runtime. The application doesn't even know where it is
> > located except by looking for a named block of memory.
>
> It does not have to be linked.  You access internal interfaces of
> U-Boot that have not been exported for non-GPL use, so your code
> still has to be licensed under GPLv2 or a compatible license.

I'm just following up to say that I agree with Wolfgang here.

Sorry for the broken formatting (our IT department forces the Outhouse web client).

I think there is some misunderstanding here. All of the code we include in U-Boot IS GPL or GPL compatible, including the API.

"Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+,
this does *not* cover the so-called "standalone" applications that
use U-Boot services by means of the jump table provided by U-Boot
exactly for this purpose - this is merely considered normal use of
U-Boot, and does *not* fall under the heading of "derived work"."

No part of U-Boot is included in these applications and no application code is included in U-Boot. We DO have SDK files used in U-Boot, but the SDK files are under a BSD-like license, basically do whatever you want with the code but don't hold us responsible. The SDK code is also used in stand-alone applications as well as the Linux kernel, where derivatives were upstreamed long-ago.

In any event, I think at this point we can remove this support. I don't think it's used any longer. It also looks like EFI does allow for vendor defined services. I hadn't looked at this code for a while but looking at it again it also appears the phy code has been removed. I think the remaining code for QLM configuration could be modified to just use a hook from some environment variables, removing this issue entirely.

--
Tom

Regards,

Aaron