This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: shared object of CDL.
Warning: I am not a lawyer and this is not legal advice. For
definitive answers I would suggest contacting the FSF.
>>>>> "Masato" == Masato Taruishi <taru@debian.org> writes:
>> Is there a specific reason why you want libcdl to become a
>> shared object? If not, my preference would be to keep it as a
>> simple static library for now, in the interest of portability.
Masato> Hmm, I forgot that the CDL library is GPL, not LGPL. If
Masato> people use libcdl.a for their program, then these program
Masato> must be licenced under GPL.
Masato> I have a question. If a program use a CDL plugin which
Masato> dynamically links libcdl, then do the program have to be
Masato> licenced under GPL?
Under GPL, or under another license which is GPL-compatible.
For example tclsh is under the BSD license sans advertising clause,
which is GPL-compatible. Therefore it should be legal for tclsh to
dynamically load a Tcl extension based on libcdl. Of course tclsh will
be running a script of some sort, so the licensing of that script
would also have to be considered. I believe that current Python
releases are similarly GPL-compatible, although there were problems
between Python 1.6 and 2.1.
If somebody wanted to build a proprietary application that used
libcdl, and tried to use dynamic loading as a way of bypassing the
GPL, then there would be problems. There has been controversy about
dynamic loading vs. GPL in the past, a web search should reveal
various comments from Stallman about the issue.
Bart
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss