On Tue, Jan 27, 2004 at 10:39:59PM -0800, William Chops Westfield wrote:
> On Tuesday, Jan 27, 2004, at 09:07 US/Pacific, Byron A Jeff wrote:
>
> >True. But as you well know that with the LGPL if you statically link,
> >you
> >still don't have to release the non library source. But you do have to
> >have a way for a user to relink the applications code to an updated
> >library.
> >And the current PIC tools can support this.
>
> Not if the PIC in your device is not reprogrammable and not replacable.

I can't put my finger on it, but I distinctly remember reading that you are
not obligated to provide a mechanism for the user to actually put the updated
code on a chip. However you must provide a mechanism for them to generate a
new executable with the freee code.

>
> Sure, I can ship a relocatable binary with my encapsulated blob of
> epoxy,
> at the expense of a lot of trouble and ... expense.  But it doesn't do
> anyone any good.

I know. I not sure the issue is as much the end user as it is other potential
developers.

It's starting to become clear to be that there needs to be some serious thought
to the concept of an Embedded GPL license. If needs to do two main tasks:

1) Decouple the fixation of the final executable to the hardware and the
   freeness of the free code.
2) Ensure that changes to the free code remains free.

Essentially it needs to be the LGPL, dropping the end user update requirement
and explicitly allowing for free and non free code to be comingled via
compilation without affecting the applications code so long as no modifications
are made to the free code. Also there may need to be an explicit extension
stating that it's OK for free and non free code to reside in the same memory
space on a chip.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics