[kaffe] Darwin license vs GPL

[Dalibor Topic]

Kiyo Inaba wrote:
> Hi Dalibor,
>
> Thanks to clarify my question. But, still I'm wondering whether your
> description fits to this situation or not.
>
>   
I wonder, too. Thanks for your reply, more below.
> Dalibor wrote:
>  
>> Kiyo Inaba wrote:
>>    
>>> So, if the comment in darwin derived code is correct, at least 'I' can
>>> not compile and link (in GPL terminology 'forming a work based on the
>>> Program') kaffe with darwin headers. The person who never made any mod
>>> nor distributed kaffe will get different situation, since the person
>>> need not to accept kaffe's license (of course GPL).
>>>       
>> The special exception for major operating system components in section 3
>> of GPLv2 lets you do that, as it takes such components like the kernel,
>> compiler, etc. out of the set of complete sources for the work. GPLv3
>> goes into a bit of more length on it under the 'System Libraries'
>> definition.
>>     
>
> Yes, there is a exception clause exists in GPLv2. But in this situation,
> the code I found is 'independent' from Apple (that's what you suggest
> in the private mail, and I have to say sorry to Apple about that), and
> then this toolchain can not be thought (by my understanding) as 'the
> major components of the operating system'. This is absolutely different
> from compiling Kaffe (or any other GPL'ed code) against SunOS or Ultrix.
> When I compiled Kaffe for Ultrix, I used the major components of the
> operating system (this is clear that I used header files shipped with
> Ultrix itself), but if I want to compile Kaffe for iPhone, I have to
> get separately prepared header files which are not easily recognized
> as 'the major components of the OS'. Since I don't have iPhone handy
> (iPhone has never been sold in Japan, anyway), I may misunderstand the
> situation.
I agree.

Otoh, I think that the intention of the system component exception is 
not cover just the
system components literally distributed as part of the operating system, 
but also those
that are, for the lack of a better word, 'optional but necessary', like 
alternative toolchains.
Otherwise, it would be very hard to bootstrap the GNU toolchain for 
proprietary systems that
don't have their own, self-hosted, manufacturer-blessed publicly 
available toolchain, for
example, like the iphone, or various gaming consoles.

If we look at the question as 'can I use an alternative, potentially 
proprietary toolchain to
build & distribute GPLd applications (without having to distribute the 
toolchain)' as a stricter
version of the iphone toolchain situation, I think that's fine. Beside 
anecdotal evidence, like
Intel's proprietary compilers for Linux being used to build & distribute 
the Linux kernel (or gcc)
by some distributions, GPLv3 clarifies 'major components' of system 
libraries to include
compilers, but does not make restrictions on their origin.

FSF's GPLv2 FAQ wrt to building GPLd applications for Windows also seems 
to indicate that
it's OK to use Microsoft's proprietary toolchain and link to its runtime 
libraries. Moreover, there
are alternative toolchains for Windows, based on gcc, like cygwin, djgpp 
& mingw32, that are
being used to build & distribute GPLd applications for Microsoft 
Windows, so I'd consider an
interpretation of the GPL systems exceptions that only allowed using the 
official, proprietary
Visual C/C++  toolchain from Microsoft for GPLd applications on Windows 
highly
unsatisfactory. :)

If you think we should get a legal opinion from the FSF in this case (we 
aren't actually
distributing any such binaries from kaffe.org, and I don't really want 
to start distributing binaries
of kaffe, it's a lot of work, that's best done by distributions), I'd be 
happy to pass on a question
to their licensing team, and report back their answer.

cheers,
dalibor topic