gnupic: gputils license query
Subject:
Re: gputils license query
From:
Byron A Jeff ####@####.####
Date:
17 Jan 2005 00:21:16 +0000
Message-Id: <20050117002111.GA20934@cleon.cc.gatech.edu>
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.
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
