[U-Boot-Users] Proposal for a make option to include an additional stand alone program directory

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Ulf Samuelsson wrote:
>> Wolfgang Denk wrote:
>>
>> I really don't want to be arguing the GPL, but I am interested in a 
>> technical solution to
>> a problem that is also legally permissible.
> 
> If you follow the rule that you cannot execute U-Boot code
> after you have executed non GPL code you will most likely not violate GPL.
> 
> Your technical solutions are obvious:
> 
> * Explain your problem to code owner and request code to be GPL.
> * Drop the code, ask for interface info, and rewrite GPL code from scratch
> * Write a program which calls the loader function, and then calls U-Boot.
>    This can be non-GPL.
> 
> What you can't do is to have U-boot call a subroutine inside the non-GPL 
> code,
> nor can you from non-GPL code jump to any point except the start of u-boot.

Not exactly true...

>>> Merging two binaries into one, so that A can make function calls into
>>> B *is* linking if the function of A depends on  the  results  of  the
>>> function calls of B.
>> How do you determine "depends"?  If B enables the 2nd Ethernet port, but 
>> you never
>> actually use it, then A doesn't really depend on B.  Takes these two 
>> scenarios:
>>
>> 1) U-Boot runs the binary application that enables Ethernet 2, but it 
>> doesn't load the
>> driver for Ethernet 2.  Therefore, the functioning of U-Boot does not 
>> depend on the binary.
> 
> Your violation occurs when you make a subroutine call.
> A pure jump which never returns is no violation.
> 
> If you, from U-boot enable some H/W using  call to non-GPL code,
> and then jump to an application which uses the H/W, then
> again you have violated the GPL.

Not exactly true...

>> 1) U-Boot runs the binary application that enables Ethernet 2, and it 
>> loads the driver for
>> Ethernet 2.  Therefore, the U-Boot can do Ethernet I/O on this device.
>>
>> By your definition, scenario #1 is not a GPL violation, but scenario #2 
>> is.  So I can
>> merge my closed-source proprietary binary in with GPL as long as I don't 
>> enabled the 2nd
>> Ethernet port.
>>
>>> Linux system calls is an explicitely exported interface so it  is  OK
>>> to use this from application code.
>> So it's okay for a non-GPL binary to call GPL code, but not the other way 
>> around?
>>
> 
> U-Boot does not have any explicitly exported interfaces except its entry 
> point.
> If you in any way make the address of a subroutine inside U-boot available
> to another application you link the application with U-Boot and the
> application must be GPL.
> You can jump to a binary which loads non-GPL stuff into another MCU
> but you cant return to u-boot.

Not exactly true...

U-Boot has a documented application interface that non-GPL "stand alone" 
applications may call.  This is equivalent to the linux system call API, 
that non-GPL applications may call.
   <http://www.denx.de/wiki/UBootdoc/StandalonePrograms>

<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=README;h=90ef2c2eba66be9d011c84f34ca44cc637b76095;hb=HEAD#l3257>

3216 More About U-Boot Image Types:
3217 ------------------------------
3218
3219 U-Boot supports the following image types:
3220
3221    "Standalone Programs" are directly runnable in the environment
3222         provided by U-Boot; it is expected that (if they behave
3223         well) you can continue to work in U-Boot after return from
3224         the Standalone Program.

API:
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/exports.h;h=8f7f61703c6c47519794996d65931018b3216d86;hb=HEAD>

Examples:
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree;f=examples;h=3b95ec59ee8e58fc459596dfd32b3c3b2a881d77;hb=HEAD>

>> Timur Tabi
>> Linux Kernel Developer @ Freescale
> 
> Best Regards
> Ulf Samuelsson