gnupic: Re: Pic18Forth - Licensing and Maillist questions.


Previous by date: 25 Jan 2005 04:32:34 +0000 Pic18Forth - Major Announcement, David McNab
Next by date: 25 Jan 2005 04:32:34 +0000 malloc/free implementation for pic?, David McNab
Previous in thread:
Next in thread:

Subject: Re: Pic18Forth - Licensing and Maillist questions.
From: Byron A Jeff ####@####.####
Date: 25 Jan 2005 04:32:34 +0000
Message-Id: <20050125043230.GA2885@cleon.cc.gatech.edu>

On Tue, Jan 25, 2005 at 12:44:21PM +1300, David McNab wrote:
> Hi,
> 
> Major update for Pic18Forth:
> 
> 2) Change of License
> 
> To cut out the confusion, I've gone for a simpler licensing scheme:
> 
>  - GPL for compiler, test progs and doco

Excellent.

>  - LGPL for library modules (which include code that gets inserted
>    verbatim in final compiled applications)

David,

I know that we hashed this out before, but I'd like to get clarity
on the intent.

I'm playing devil's advocate since I would mostly likely release
anything I write in Open Source anyway.

The LGPL has three major tenets. Two are pretty clear cut:

1) Changes to the LGPL code base itself is treated as GPL.

2) Derivative works can be distributed under the license of the
distributor's choosing.

These are all well fine and good. The sticky one continues to be:

3) The end user has the right to update the LGPL portion of the
deriviative work and the distributor must provide the end user
with both the means and the tools to perform said update. It's
generally known as the relink requirement.

The premise is simple enough. The LGPL code is free even when its
comingled with non LGPL code. So the end user should be able to 
update the free LGPL portion of the code.

With free software none of this is a problem because the end user
has all the source. However it's a bit of a burden for the closed
source developer who wishes not to release their code for open
access.

The implication of the (includes code that gets inserted...) is
that if that code is updated, then the end user has a right to
that updated code. Since it's generated by the pic18forth compiler
then the code that generated the original object must be recompiled.
So then the closed source developer must either recompile the code
for the users and provide to objects to be relinked, or provide
source to the end user so that they can compile it for themselves.

If it were all in a separate link library, then closed source object
file could be linked with the open source library and the job is done.

But with the compiler producing verbatim code that is LGPLed, that 
means that a closed source developer is kind of caught in terms of
maintaining the accessibility of the open source code that is embedded
into the object the compiler produces.

Now that's the implication. I'm just wondering if that was your intent.

Note that applications such as Bison has a specific exception for the
embedded free code that it generates. A section describing it is here:

http://www.gnu.org/software/bison/manual/html_mono/bison.html#Conditions

All in all it depends on intent. I was just curious as to what your 
intent was on this subject.

One last aside. James Newton of PICLIST fame is reposting your 
announcements on Pic18Forth to the PICLIST. If you happen to be a 
PICLIST member maybe you can start posting announcements to that list too.

BAJ

Previous by date: 25 Jan 2005 04:32:34 +0000 Pic18Forth - Major Announcement, David McNab
Next by date: 25 Jan 2005 04:32:34 +0000 malloc/free implementation for pic?, David McNab
Previous in thread:
Next in thread:


Powered by ezmlm-browse 0.20.