From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 27 Apr 2007 16:13:39 -0400 Subject: [U-Boot-Users] Proposal for a make option to include an additional stand alone program directory In-Reply-To: <002601c78903$64f47cc0$01c4af0a@Glamdring> References: <20070427093848.6AAC0353A31@atlas.denx.de> <46324857.2020904@freescale.com> <002601c78903$64f47cc0$01c4af0a@Glamdring> Message-ID: <46325973.20201@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 ------------------------------ 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: Examples: >> Timur Tabi >> Linux Kernel Developer @ Freescale > > Best Regards > Ulf Samuelsson