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

Jerry Van Baren gerald.vanbaren at smiths-aerospace.com
Fri Apr 27 22:13:39 CEST 2007

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.


3216 More About U-Boot Image Types:
3217 ------------------------------
3219 U-Boot supports the following image types:
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.



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

More information about the U-Boot mailing list