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:
- 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...
- 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
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.
Timur Tabi Linux Kernel Developer @ Freescale
Best Regards Ulf Samuelsson