On Wed, Nov 06, 2019 at 12:03:23AM +0000, Aaron Williams wrote: > Hi Tom, > > ________________________________ > From: Tom Rini > Sent: Tuesday, November 5, 2019 6:16 AM > To: Wolfgang Denk > Cc: Aaron Williams; Daniel Schwierzeck; u-boot@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@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.
Not needing to worry about how to deal with this support is indeed the best case for everyone, thanks! -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
