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
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
