Re: [sdcc-devel] sdcc libraries license

[Borut R. <bor...@si...>]

Hello Karl,

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 
http://sdcc.sourceforge.net/release_wiki/index.php?page=Library+License+Selection).

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,

Borut



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,
>
> Karl.
>
>
> ------------------------------------------
> Hello,
>
> 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.
> http://answers.yahoo.com/dir/?link=list&sid=396545367
>
>