From: Jonathan Larmour <jifl@eCosCentric.com>
To: eCos Maintainers <ecos-maintainers@sources.redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Subject: rbtree licence dilemma
Date: Tue, 21 Jan 2003 01:16:00 -0000 [thread overview]
Message-ID: <3E2C9F52.70803@eCosCentric.com> (raw)
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
next reply other threads:[~2003-01-21 1:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-21 1:16 Jonathan Larmour [this message]
2003-01-21 8:44 ` Andrew Lunn
2003-01-21 9:02 ` David Woodhouse
2003-01-21 10:11 ` Bart Veer
2003-01-21 10:33 ` David Woodhouse
2003-01-21 10:44 ` Bart Veer
2003-01-21 18:52 ` Jonathan Larmour
2003-01-21 19:31 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E2C9F52.70803@eCosCentric.com \
--to=jifl@ecoscentric.com \
--cc=dwmw2@infradead.org \
--cc=ecos-maintainers@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).