Re: Extended Hamming encode/decode
- From: David Brown <david.brown@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 08 Mar 2010 03:07:48 +0100
David Brown <david.br...@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
To use LGPL'ed code with your own code, anyone receiving your code must
have access to the LGPL'ed code, be able to change and recompile that
code, then link it along with the rest of the binary and run that
software instead. For non-embedded systems (or "big" embedded systems),
that typically means the LGPL'ed code is part of a dynamic library. To
use LGPL code in a (typically statically linked) embedded system means
that the end user will need access to your source code, or at least
compiled and linkable object files. Since that is impractical or
impossible for most embedded systems, the rough conclusion is that pure
LGPL code is very seldom suitable for embedded systems.
Okay, thanks. I guess where we differ is in the opinion that
dynamically linked apps are not suitable for embedded systems. The
ones I work on (Linux-based) tend to use dynamically linked apps more
than statically linked ones. In the early days, I've even had to
force the apps to be dynamically linked to fit everything in flash
(several apps linked with the same library).
I try to be careful to make the distinction between small statically linked embedded systems, where the (L)GPL is almost useless, and "large OS" embedded systems with dynamic linking, which often have LGPL and GPL code. But I don't always manage to make it clear.
So we don't actually differ in opinion at all.
- Prev by Date: Re: Extended Hamming encode/decode
- Next by Date: Re: Extended Hamming encode/decode
- Previous by thread: Re: Extended Hamming encode/decode
- Next by thread: Re: Extended Hamming encode/decode