Re: rbtree licence dilemma

[Andrew Lunn <andrew.lunn@ascom.ch>]

What about the re-licencing issue, assuming we decide to go that
way. If you cannot convince some company to use the modGPL version of
eCos and instead decide to offer a version with another licence, it
will probably no longer be "free" and so this exception fails. I also
guess, that since we don't hold the copywrite, we cannot change the
license on this part anyway? So, it would have to be removed.

        Andrew

On Tue, Jan 21, 2003 at 01:16:02AM +0000, Jonathan Larmour wrote:
> Recent versions of JFFS2 now require a red-black tree implementation. It 
> originally used the GPL version from the Linux kernel. That obviously made 
> it impossible to include in the standard eCos sources.
> 
> David has now suggested an alternative of using a red-black tree 
> implementation from libstdc++ (stl_tree.h). That is covered by the GPL and 
> the normal libstdc++ exception, which is:
> 
> "// As a special exception, you may use this file as part of a free software
> // library without restriction.  Specifically, if other files instantiate
> // templates or use macros or inline functions from this file, or you 
> compile
> // this file and link it with other files to produce an executable, this
> // file does not by itself cause the resulting executable to be covered by
> // the GNU General Public License.  This exception does not however
> // invalidate any other reasons why the executable file might be covered by
> // the GNU General Public License.
> "
> 
> This is similar but not quite the same as the eCos exception. One reason 
> is that they don't require libstdc++ to be distributed regardless. We 
> require it in eCos, whereas with libstdc++ people take it that the above 
> means if you change the source, the new version must be distributed[1].
> 
> The other dissimilarity is that it says "you may use this file as part of 
> a free software library without restriction". This may imply if it is not 
> part of a free software library, the exception does not apply. I'm not 
> sure. The fact that eCos compiles to a libtarget.a sounds like a technical 
> detail not necessarily to be relied on - not least if people did include 
> non-free source in the library (which may happen in future with third 
> party EPKs). I would be interested in other's opinions.
> 
> Even if this potential issue isn't a problem, can anyone foresee any other 
> problem with including code based on this libstdc++ licence?
> 
> Jifl
> 
> [1] This has been discussed in the past, and it's not clear to many, 
> myself included, whether this is actually the case or not. That's one of 
> the reasons the eCos exception tries to be a bit clearer.
> -- 
> eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>