[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Three problems with Chinput



Hi,
You said my pinyin module violates LGPL, then could you please point out where such case is mentioned in LGPL license?

I had read LGPL again but find nothing about the two points that you mentions in early mail. But there is a paragraph in LGPL said:

=======================================================

5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)

Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.

=======================================================

Please notice that LGPL does not forbid a "work that uses the Library" from using numerical parameters, data structure layouts and accessors and small macros and small inline functions of a LGPLed library without violating the license.

And pinyin module fits in this situation perfectly.

Regards
James Su


Yong Li wrote:

On Fri, 2 May 2003, James Su wrote:

Then, how do you think about the relationship between the linux kernel and close sourced modules, like NVidia kernel driver? Don't they obay those two rules?

Ha! You don't want to use binary-only kernel module as an example because
it is a beast of its own. This is a very gray area and subject to heated
debate many times a year. AFAIK, there's no legal consensus about this
issue. It's just that Linus have gave his personal blessing to the binary
only modules. However as Alan Cox pointed out in an email sent to lkml
about 2 years ago that "Linus opinion on this is irrelevant". He also said
in the same email that "Anyone releasing binary only modules does so
having made their own appropriate risk assessment and having talked (I
hope) to their insurers". In the 2.5 series a EXPORT_SYMBOL_GPL is introduced such that a new internal kernel interface can be marked as only available to modules with a GPL compatible license should the developer decide to do so. Practically this will make binary only modules even harder. So the future of binary only modules is uncertain.

From what I understand the basic assumption about a binary only modules is
that it can not use any header file, data structure, macros, etc. from the kernel source. If you can do that, the module itself is not a violation of anything, albeit non-free. You can redistribute it as long as the author permits you. Only when you link this module into kernel, the kernel becomes non-distributable! So no one does that.

The crucial difference between kernel module example and your case is that
your pinyin module obviously uses data structures and macros from scim proper which is covered by LGPL. So even the module alone is not legally distributable.

Regards,
rigel









Reply to: