This is the mail archive of the
mailing list for the eCos project.
Re: rbtree licence dilemma
- From: Bart Veer <bartv at ecoscentric dot com>
- To: jifl at eCosCentric dot com
- Cc: ecos-maintainers at sources dot redhat dot com, dwmw2 at infradead dot org
- Date: Tue, 21 Jan 2003 10:11:47 +0000 (GMT)
- Subject: Re: rbtree licence dilemma
- References: <3E2C9F52.70803@eCosCentric.com>
>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
Jifl> Recent versions of JFFS2 now require a red-black tree
Jifl> implementation. It originally used the GPL version from the
Jifl> Linux kernel. That obviously made it impossible to include
Jifl> in the standard eCos sources.
Jifl> David has now suggested an alternative of using a red-black
Jifl> tree implementation from libstdc++ (stl_tree.h). That is
Jifl> covered by the GPL and the normal libstdc++ exception, which
Jifl> "// As a special exception, you may use this file as part of a free software
Jifl> // library without restriction. Specifically, if other files instantiate
Jifl> // templates or use macros or inline functions from this file, or you compile
Jifl> // this file and link it with other files to produce an executable, this
Jifl> // file does not by itself cause the resulting executable to be covered by
Jifl> // the GNU General Public License. This exception does not however
Jifl> // invalidate any other reasons why the executable file might be covered by
Jifl> // the GNU General Public License.
Jifl> This is similar but not quite the same as the eCos
Jifl> exception. One reason is that they don't require libstdc++
Jifl> to be distributed regardless. We require it in eCos, whereas
Jifl> with libstdc++ people take it that the above means if you
Jifl> change the source, the new version must be distributed.
Jifl> The other dissimilarity is that it says "you may use this
Jifl> file as part of a free software library without
Jifl> restriction". This may imply if it is not part of a free
Jifl> software library, the exception does not apply. I'm not
Jifl> sure. The fact that eCos compiles to a libtarget.a sounds
Jifl> like a technical detail not necessarily to be relied on -
Jifl> not least if people did include non-free source in the
Jifl> library (which may happen in future with third party EPKs).
Jifl> I would be interested in other's opinions.
The restriction makes it impossible to provide any sort of commercial
license, without the permission of the copyright holder. I assume that
libstdc++ is (C) FSF, who are very unlikely to agree to any such
commercial license. So this code could not go in until we abandon the
idea of commercial licenses.
Proprietary third party EPK's are indeed a problem IMHO, because as
you say libtarget.a/libextras.a may not be totally free. CDL does make
it possible for such EPK's to build to their own libraries, so that
free and proprietary code end up in separate libraries, but right now
there is no way to enforce that. A new license property in cdl_package
would help, but would still not be a 100% guarantee.
So there is a real risk of license infringement, albeit minor and
accidental on the part of the user, but theoretically it could lead to
users being forced to disclose their application code. Hence I believe
we should not risk including this code.
Instead we could turn jffs2 (including this code) into its own library
and force users to link explicitly with -ljffs2. It would be analogous
to linking with libgcc and libstdc++. Unfortunately our current linker
script technology is not up to the job of doing this automatically,
so we would be inconveniencing users. It would get us past any legal
One other possibility is to contact the FSF's lawyers and get their
opinion. If we get a statement from them saying that there is no
problem, that would be sufficient defense.