Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)

[Erik van Pienbroek]

Op zondag 12-07-2009 om 12:22 uur [tijdzone +0100], schreef Richard W.M.
Jones:
> On Sun, Jul 12, 2009 at 12:49:25AM +0200, Erik van Pienbroek wrote:
> > About integration in Fedora: I noticed that the Feature Freeze for
> > Fedora 12 is just 2 weeks away [3]. I don't think that will be enough
> > time to get all the legal issues cleared up, so I'm afraid we have to
> > postpone the darwinx toolchain as a feature until Fedora 13. AFAIK
> > nobody has started on getting the legal issues cleared up so that's the
> > next major roadblock ahead of us. Help in this area is really
> > appreciated. If somebody can help with getting these packages in
> > RPMFusion then that would also be very appreciated.
> 
> Could you give a quick summary of the remaining legal
> issues?

The darwinx toolchain consists of at these base packages:
- cctools/odcctools (the darwin equivalent of binutils)
- the Mac OS X SDK (containing system headers and libraries)
- gcc (Apple's forked version)

The cctools are provided by Apple [1], but these are mostly targeted for
real Mac OS X environments. So some patches were collected to get it
operational on other environments in a project called odcctools. The
script to patch the cctools and the individual patches are maintained at
[2]. The odcctools development seem to be reasonable active these days.

The cctools project (and thus also odcctools) is licensed under the
APSL2.0 license. Upon a closer look (a grep on 'license') I've noticed
that all the files from the 'as' part are licensed under the GPL1+
license (whoa, that's old!) or the GPL2+ license (the code is forked
from the GNU Assembler/GAS project).

There are also some other files in cctools/odcctools which are licensed
under the GPLv1+/GPLv2+:
include/coff/syment.h (GPLv2+)
include/coff/scnhdr.h (GPLv2+)
include/coff/aouthdr.h (GPLv2+)
include/coff/ms_dos_stub.h (GPLv2+)
include/coff/filehdr.h (GPLv2+)
include/opcode/arm.h (GPLv1+)

Unfortunately, also some APSL 1.0/APSL 1.1 files are involved:
include/foreign/libkern/machine/OSByteOrder.h (APSL 1.1)
include/foreign/libkern/OSByteOrder.h (APSL 1.1)
include/foreign/architecture/i386/sel.h (APSL 1.0)
include/foreign/architecture/i386/frame.h (APSL 1.0)
include/foreign/architecture/i386/fpu.h (APSL 1.0)
include/foreign/mach/ppc/thread_status.h (APSL 1.1)
otool/notify.h (APSL 1.0)

The APSL 1.0 and APSL 1.1 files are a no-go for Fedora.. We might want
to ask Fedora Legal to get Apple to relicense these files.

For GCC I didn't do a license audit, but I don't foresee any problems
with it (as Apple is bound to publish their changes to GCC in a
GPL-compatible license).

The major license problem lies in the SDK. The SDK is only available for
registered users from the Apple website (free registration) and is
bundled along with XCode.

The SDK contains a bunch of header files and (binary) libraries. The
header files are published under an open source license so I guess that
we are allowed to redistribute them. The problem lies in the licenses
involved. The SDK contains a mix of various licenses like APSL 1.0, APSL
1.1, APSL 2.0, GPLv2+ and LGPLv2+. I didn't make a list yet of header
files which contain a forbidden license (APSL 1.0/APSL 1.1). But for
these files, we might also want to ask Fedora Legal to get Apple to
relicense these files.

Another problem with the SDK is that the libraries bundled with the SDK
are only available in binary format. For most libraries we could work
around this by creating stub libraries (so that the compilation of other
libraries and applications can succeed). Something similar is also done
with MinGW so we might find useful code or scripts there to generate
such stubs.

I think that some libraries can't be stubbed like static libraries which
provide program initialization code. IIRC, the source code for such
static libraries is available, but again published under a forbidden
license.

To summarize:
- We need to create a list of header files in the SDK which contain
  an forbidden license
- We need to create stubs for the libraries bundled with the SDK
- We need to get Apple to relicense the forbidden files

So that's basically where we're at right now from a legal point of view.

Regards,

Erik van Pienbroek

[1]: http://opensource.apple.com/release/developer-tools-313/
[2]: http://svn.macosforge.org/repository/odcctools/trunk/