From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ulf Samuelsson <ulf@atmel.com>
Date: Fri, 27 Apr 2007 21:32:03 +0200
Subject: [U-Boot-Users] Proposal for a make option to include an
	additional stand alone program directory
References: <20070427093848.6AAC0353A31@atlas.denx.de>
	<46324857.2020904@freescale.com>
Message-ID: <002601c78903$64f47cc0$01c4af0a@Glamdring>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

> 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.


>
>> 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.

> 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.

> Timur Tabi
> Linux Kernel Developer @ Freescale
>


Best Regards
Ulf Samuelsson