gnupic: gputils license query
Subject:
Re: gputils license query
From:
Craig Franklin ####@####.####
Date:
17 Jan 2005 01:39:54 +0000
Message-Id: <41EB17BD.50009@users.sourceforge.net>
Byron A Jeff wrote:
>On Mon, Jan 17, 2005 at 10:52:57AM +1300, David McNab wrote:
>
>
>>Hi,
>>
>>On responding to a license query regarding pic18forth, I looked up the
>>license for gputils.
>>
>>According to gputils website, gputils is issued under the GPL.
>>
>>I need to ask - does the GPL 'infect' any binary code generated by
>>gputils? For instance, would the GPL automatically apply to:
>>
>> - .o files generated by gpasm from user-written .asm files?
>>
>>
>
>No.
>
>
>
>> - .a files generated by gplib?
>>
>>
>
>No.
>
>
>
>> - .hex files generated by gplink?
>>
>>
>
>No.
>
>
>
>>and let's not forget:
>> - .o/.hex files generated by gpal?
>>
>>
>
>And no.
>
>
>
>>If so, then for developers writing firmware for commercial PIC-based
>>hardware, it would become mandatory to make the firmware's source code
>>available to end customers of the hardware.
>>
>>For instance, if Joe Bloggs built and sold a 'smart Christmas tree
>>lighting system' based on PIC, and wrote the firmware in GPAL, and
>>compiled the runtime image with gpal/gpasm/gplib/gplink, then this
>>firmware could be seen as a 'derived work', which would mean that Joe
>>Bloggs has to enclose a CD of his source code with the product, or write
>>a URL into the manual for downloading this source code.
>>
>>I'd like some clarification on this. If it's not the gputils developers'
>>wish for GPL to 'infect' user-created firmware, then it might be an idea
>>to add a special exclusion to this effect to the gputils website and doco.
>>
>>
>
>Moot point. It doesn't apply.
>
>Now getting back to your PICforth, there are some potential issues there.
>You stated in your announcement that the threaded interpreter will be
>included with the users object. The license on that piece of code could cause
>issues because it's not the users code, but is linked to the users code.
>So that's a derived work and therefore the user's code is subject to that
>license.
>
>It is an issue that the LGPL specifically addresses in section 6. It's known
>as the relink requirement. It makes three points:
>
>1) The author can distribute the derived object as they see fit.
>2) However the user has the right to update the LGPL code so...
>3) The developer must provide a mechanism so that the user that LGPL code.
>
>For regular systems shared libraries solve the problem. Even the linker can
>help as the user only needs to provide objects.
>
>But if the only way to generate the executable is to assemble all the code
>together, then the only way to update is to provide the source.
>
>
>
If you use gplink, you also have the option of distributing object files
instead of source code.
>It's a bit of a problem.
>
>The ZPL license attempts to rectify that issue. But I'm not sure if it
>continues to defend the freeness of the free side of the code.
>
>BAJ
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>
>
>
>
