Re: Three problems with Chinput
On my understanding, if SCIM releases under GPL, pinyin will violate GPL. The
plug-in case in GPL FAQ is ONLY for GPL license. In LGPL:
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.
6. As an exception to the Sections above, you may also combine or link a "work
that uses the Library" with the Library to produce a work containing portions of
the Library, and distribute that work under terms of your choice, provided that
the terms permit modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
According to Section 5, pinyin is "work that uses the Library", it can use its
own license, including non-free license. In SCIM case, it dynamically links a
non-free library to a LGPL library. It should be permited by LGPL.
Yu Guanghui <ygh at dlut.edu.cn>
Dalian University of Technology, China
引用 Yong Li <firstname.lastname@example.org>:
> On Thu, 1 May 2003, Yu Guanghui wrote:
> > Hi
> > I didn't see any violation. SCIM is LGPL, the upsteam author (Su Zhe)
> > the source. The upstream author also writes the pinyin module, and decides
> > to release the source. Pinyin module should not be considered as part of
> > It's a standlone program use SCIM API that releases under LGPL.
> > So the SCIM will be put in Debian main (it's LGPL and don't depend on
> > module, there are other input modules), and pinyin will be put to
> Here is why I think it might be a violation.
> As I understand it scim is under LGPL and pinyin is a loadable module. For
> this combination I'm only aware of two possibilities for the module not
> have to be released under LGPL or GPL-compatible license:
> 1. If the aforementioned module is a standalone executable and only
> dynamically linked to the libraries of scim. when started the module must
> run in its own space.
> 2. If the module is not a standalone executable and is dynamically loaded
> the main program (scim in this case). Then the main program must use fork
> and exec to invoke the module to make it a separate program.
> The pinyin module is obviously not a standalone executable! It is
> physically distributed as a so file. So possibility 1 is definitely out.
> All the evidences suggest that scim doesn't fork and exec the module.
> Instead it is loaded in its entirety into the main program's space.
> Function calls are made and data structures are shared between the two
> entities. So, imho, they form a single program. As such the module must be
> treated as an extension to the main program and be released under the LGPL
> or a GPL-compatible license. You might want to refer to the topic on how
> to treat the plug-ins for a GPLed program in GNU's GPL FAQ.
> The uniqueness about this scim situation is that it is the author himself
> who "violates" his own license. For all the years I have been following
> the open source development, this is the first time I have ever seen this
> happen. Strictly speaking it is not a violation for the author himself.
> Because from legal standpoint of view, a license such as GPL/LGPL is a
> contract from the author for the users of his program. The author himself
> is not bound by the license. However I think for everyone else, such as
> Anthony, who want to redistribute the pinyin module, it is a violation of
> the LGPL license.
> Of course this is only my personal opinion based on my own understanding
> of GPL/LGPL license. This is such a rare and unique case. That's why I
> think it's important, if you want to include it in debian distribution, to
> bring this up to debian-legal and hear what those experts have to say.
> Granted even if someone redistributes the pinyin module and violates the
> LGPL license, it's highly unlikely the author will ever pursue him/her and
> enforce the license. After all it's the author's intension of doing so.
> So the legal risk is minimum. However this does not make it right. If this
> is indeed a LGPL violation, I think it's a shame for the debian project to
> put it into its distribution.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
| This message was re-posted from firstname.lastname@example.org
| and converted from gb2312 to big5 by an automatic gateway.