I'm glad that you answered to may mail.
LGPL license is not suitable for closed source embedded world. It says
that the owner of the code should:
- publish the source code of the complete product (not only changed
library code), which means that all code is open source or
- publish the product in a way that the user can relink it with the
newer version of library: publish the object code. This is not
applicable since the relinked code has to be somehow programmed into a
memory device (EPROM, Fleash memory, CPU, ...). This requires special
tools, which are usually not available to the end user of the product.
- dynamically link the product with the library. This method is most
commonly used with the "real" OSes (*nix, Linux, Windows, ...), but it
is not applicable for embedded world, since the proprietary code is
statically linked with the library. Usually there is no way to use
dynamic linking in small embedded devices.
The only feasible option is the first one, which is not acceptable by
the definition of "closed source". This means that LGPL doesn't bring
any additional value in comparison with GPL for embedded applications.
We, (currently active) SDCC developers, decided to make it possible to
use SDCC also for proprietary projects, so we choose the licenses which
are suitable for such purpose. LGPL is not on the list. The closest is
the GPL+LE (GPL with library (or runtime) extension). This is the
license used for GCC runtime library (not glibc, which is usually
dynamically linked), GCC C++ library, libjava, ...). This license has
currently the highest number of votes on the list (see
Karl, if you agree to give the possibility to use SDCC in proprietary
projects, please vote for one of the licenses on the list.
If you are against, just say it. This would mean a red light for
changing the license for the complete SDCC library, or somebody will
have to rewrite the code you already wrote.
Thank you again for your response and waiting for an other one,
Mr Karl Bongers wrote:
> Hi Borut,
> Have not kept up with the SDCC list/project the last few years,
> so I don't have a strong opinion. I would vote LGPL, I don't
> see much downside to this as you can use it to produce proprietary
> software, but must stick with the GPL spirit concerning the source.
> I would guess if you HAD to tweak the printf routine for your
> proprietary product, you could just open source or contribute that
> back and keep the project itself proprietary, so I don't see any
> problems with LPGL. The BSD license is annoying because it says
> I have to includes license material in my documentation. MPL is
> too long and involved to read, the X11 seems nice enough but LGPL
> seems to fit better with the rest of the project.
> I recall having some dealings with this years ago, and I though LGPL
> was acceptable and the planned action.
> Best Regards,
> I'm Borut Razem and I'm working as a developer on SDCC project since
> 2002. I'm addressing you in the name of SDCC developers and users since
> you are the co-author of the SDCC library code.
> For the SDCC 2.7.0 release we plan to change the sdcc library license
> from GLP / LGPL / "who knows what else" to an unified license, which
> allows to use the SDCC library in "non open source" (proprietary)
> projects. Currently the most promising license is GPL plus Library (or
> Runtime) Exception. The license of the SDCC compiler will remain GPL.
> Mark Swayne prepared a voting table with description of licenses at
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.