gnupic: gputils license query
Subject:
Re: gputils license query
From:
David McNab ####@####.####
Date:
17 Jan 2005 01:26:20 +0000
Message-Id: <41EB1427.6090004@rebirthing.co.nz>
Byron A Jeff wrote:
> Now getting back to your PICforth
Sorry for being pedantic, but it's called 'pic18Forth' (till someone or
myself come up with a better name). 'PicForth' is an existing product
for PIC16Fxxx chips, developed by Samuel Tardieu.
> 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.
I've thought about this already, and decided that the host compiler
itself can be GPL.
However, the VM core, primitives and lib routines will need to be LGPL,
with an added clause stipulating that in cases where developer-users are
distributing finished hardware products to consumers containing firmware
created via Pic18forth, the developer-user is exempt from providing
source code to the consumer.
Any thoughts on this?
Cheers
David
>
> 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
>
>
