From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Date: Fri, 27 Apr 2007 14:00:39 -0500 Subject: [U-Boot-Users] Proposal for a make option to include an additional stand alone program directory In-Reply-To: <20070427093848.6AAC0353A31@atlas.denx.de> References: <20070427093848.6AAC0353A31@atlas.denx.de> Message-ID: <46324857.2020904@freescale.com> List-Id: 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. > 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. 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? > Please do yourself a favour and re-read the GPL. I don't think just reading the GPL is enough to understand it. Some parts of it are vague, and their interpretations are debatable. -- Timur Tabi Linux Kernel Developer @ Freescale