Re: rbtree licence dilemma

[Bart Veer <bartv@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> is:

    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> "

    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[1].

    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
difficulties. 

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.

Bart