rbtree licence dilemma

rbtree licence dilemma

[Jonathan Larmour]

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

Re: rbtree licence dilemma

[Andrew Lunn]

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
> 

Re: rbtree licence dilemma

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]


andrew.lunn@ascom.ch said:
> 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.


/me Googles... How about http://users.footprints.net/~kaz/kazlib.html ?

We'd need to contact the author and ask to make sure he wouldn't then want 
_all_ users of it in eCos to mail him as described in the MUST_READ file 
(attached), but I suspect that won't be a problem.

--
dwmw2


[-- Attachment #2: MUST_READ --]
[-- Type: text/plain , Size: 1141 bytes --]

Greetings, Programmer!

I gather that because you are reading this, you are probably considering using
the C language translation units included here in your own software.   If that
is the case, I would like to know who you are and urge you to contact me.

Here is why: I rove over this code periodically looking for defects. In fact,
I use it in my own programming projects.  If I discover a defect, I will
notify everyone who I know is a user of this software. If there is a serious
defect in some code that you are using in your software project, wouldn't you
want to be informed? In fact, there is no question that you _need_ to be
informed!

Here is what you do: simply send an e-mail message to kaz@ashi.footprints.net
with the subject "kazlib" and the body "I am a user". Be sure that your message
has a good return address. I will manually add your e-mail address to a list
which I will use only for the purpose of notifications regarding Kazlib.   You
will receive a reply to the effect that you are added. 

If ever you should wish to be removed from this list, simply ask and it shall
be done.

Yours in earnest,

    Kaz Kylheku

Re: rbtree licence dilemma

[Bart Veer]

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

Re: rbtree licence dilemma

[David Woodhouse]

I assume this licence is more acceptable? :)

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.7

--
dwmw2

Re: rbtree licence dilemma

[Bart Veer]

>>>>> "David" == David Woodhouse <dwmw2@infradead.org> writes:

    David> I assume this licence is more acceptable? :)

    David> http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.7

That looks like vanilla current BSD, so yes.

Bart

Re: rbtree licence dilemma

[Jonathan Larmour]

David Woodhouse wrote:
> I assume this licence is more acceptable? :)
> 
> http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.7

Now _that_ is a lot better! If you can do it with that implementation, 
that would definitely be okay.

Thanks for looking around!

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

Re: rbtree licence dilemma

[David Woodhouse]

On Tue, 21 Jan 2003, Jonathan Larmour wrote:

> Now _that_ is a lot better! If you can do it with that implementation, 
> that would definitely be okay.

It's working. I sent you a linux compatibility EPK earlier with it in. 
The JFFS2 code I'm working with is taken straight from the master JFFS2 
tree at cvs.linux-mtd.infradead.org. We even agree with Linux about how to 
store mode bits on the medium now :) 

-- 
dwmw2