This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
rbtree licence dilemma
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: eCos Maintainers <ecos-maintainers at sources dot redhat dot com>
- Cc: David Woodhouse <dwmw2 at infradead dot org>
- Date: Tue, 21 Jan 2003 01:16:02 +0000
- Subject: rbtree licence dilemma
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