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/