tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] Using TinyCC with GPL


From: KHMan
Subject: Re: [Tinycc-devel] Using TinyCC with GPL
Date: Mon, 16 Jun 2008 11:36:48 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

Rob Landley wrote:
> On Friday 06 June 2008 15:34:41 Ivo wrote:
>> If you use Rob Landley's fork, your application must be GPL as Rob switched
>> to the GPL for all of tinycc.
> 
> Thanks for the FUD, but if you'd bothered to read the README:
> 
>> License:
>> -------
>>
>> Tinycc is distributed under GPL version 2.  (This is a specific version of
>> the GPL, included in the file LICENSE in this tarball.  It may not be
>> distributed under later versions.)
>>
>> The license on tinycc does not apply to output files produced by tinycc
>> (which are under whatever licenses the corresponding source files were
>> under), nor does it affect the header files in the include directory (look
>> up "Scenes a Faire" and the merger doctrine).
> 
> By your logic, #including standard headers out of /usr/include would make 
> your 
> program GPL.  For example, the glibc /usr/include/errno.h includes the glibc 
> bits/errno.h, which includes linux/errno.h which is a file taken from the 
> Linux kernel and licensed under GPLv2 (not LGPL).  So any code that #includes 
> the standard header errno.h is sucking in source code from the Linux kernel 
> when it compiles.
> 
> If it worked that way then every program ever compiled for Linux would be GPL 
> version 2.  There would be no binaries available under GPLv3, or the artistic 
> license, or mozilla license, or BSD, or any proprietary license.

Ivo is right. Please read Yann Renard's original post again. My
reading of the OP says that he is embedding a scripting language,
not using it with #!. This is not mere aggregation, plus he is
providing tcc as an integral and essential part of the
application, hence Ivo is correct, otherwise FSF wouldn't have a
need to write the LGPL license to cater to applications that
aren't GPL-compatible.

Your (Rob's) position is obviously correct for cases where a
scripting language is used like the way Perl is traditionally
used, but if Ivo and I are correct about the OP's intention of
embedding tcc (where the application is running scripts internally
as one entity and tcc is in no way used as a system library), then
the application would have to be GPL-compatible.

As for header files, I believe it would depend on whether the
scripting language is to be considered a part of the system
libraries or an integral part of the application. In this case,
the intention is for tcc to be an integral element, so the
application has to be GPL-compatible.

Please correct me if I am wrong.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia




reply via email to

[Prev in Thread] Current Thread [Next in Thread]