746774 - can we redistribute a custom built android gnu toolchain

Status: RESOLVED FIXED

(mozilla.org :: Licensing, task, P3)

Description

[John Ford [:jhford] CET/CEST Berlin Time]

I would like to be able to upload the toolchain that I built in bug 745956 to ftp.mozilla.org.  This toolchain is similar to the one we use with release builds, compiled from the same sources but for mac, compiled with the XCode gcc compiler.

I know that the sources of the toolchain are gnu, but I don't know if the android ndk build tools used to create the binaries are open source.

The NDK sources are from http://developer.android.com/sdk/ndk/index.html and the sources for the toolchain that is built are:

ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.3/gcc-4.6.3.tar.bz2
ftp://sourceware.org/pub/binutils/releases/binutils-2.22.tar.bz2
ftp://ftp.gmplib.org/pub/gmp-5.0.4/gmp-5.0.4.tar.bz2
http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz
wget http://mpfr.loria.fr/mpfr-3.0.1/mpfr-3.0.1.tar.bz2
wget ftp://sourceware.org/pub/gdb/releases/gdb-6.6a.tar.bz2

Is it acceptable to post the resulting binaries to ftp?  If so, how do I satisfy the requirements for providing the source to downstream users.

Comment 1

[Liz Compton [:liz]]

Gerv - Could you please take a look at this?

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to liz from comment #1)
> Gerv - Could you please take a look at this?

Gerv - ping? 

This signoff is blocking deployment of faster compiler/linker to fennec developers, which would speed up their build times. If it helps speed things up by talking on phone/skype with jhford or myself, please ping us on irc.

Comment 3

[Gervase Markham [:gerv]]

So AIUI you want to post binaries of the software in the list of URLs in comment 0 (gcc, binutils, gmp, mpc, mfr, gdb) to ftp.mozilla.org, and want to know how to do that while following the licenses concerned? If that's the question, here's an initial attempt at an answer.

Some or all of the software in that list is under the GPLv3, which has the most detailed requirements, so it seems easiest to follow them for everything.

If you have not modified the source to those packages, you should simply upload the source tarballs next to the binaries (or in a "src" subdirectory, for organizational convenience). We could just upload a README file with links, but that means there is an obligation on us to make sure the links keep working, and it seems easier to just provide sourceballs instead. If you ever ship new binaries from newer versions of the code, don't forget to replace the sourceballs.

If you have modified the source, it seems to me to be good practice, as well as obeying the GPL's requirement to make clear what your modifications are, to provide the modifications as patch files alongside the source, with instructions on how to apply them (which should be pretty trivial :-).

If it is not obvious how you created the binaries from the source, then you should upload a README explaining how you did it. It is not a relevant fact that some of the build tools required to create the binaries you are distributing may be proprietary, although you should explain how to get copies of them.

Gerv

Comment 4

[Gervase Markham [:gerv]]

Moving to an open component; nothing secret here.

Gerv

Comment 5

[Ben Bucksch (:BenB)]

If the NDK and all software used in the compilation is open-source, then I don't see a problem: Just upload 1) the resulting binaries and 2) all third-party sources and scripts you used 3) any scripts or changes you wrote and 4) the instructions how to compile.

Alternatively to 3), some licenses may allow you to just reference a third-party URL for e.g. gnu gcc

Comment 6

[Ben Bucksch (:BenB)]

> Alternatively to 3)

I meant "Alternatively to 2)".
Also, mention the licenses, of course. It wasn't clear to me whether the Android NDK is open-source and under which license.

Comment 7

[Gervase Markham [:gerv]]

OK, sounds like I need to have another go at this :-)

Here are some principles. Some licenses require some of these, others are just good and convenient practice. It's much easier to treat everything the same that read the licenses carefully to work out the minimum you can get away with.

1) Ship source to anything you ship binaries of
2) Provide build instructions (and patches if necessary) so someone else can take that source 
   and get the same binaries

So if we are shipping a binary NDK, we should ship the NDK source it was built from, plus build instructions. We don't have to ship the source of tools used to build the NDK unless they end up in the binary NDK package themselves. However, such tools (and how to build them, if necessary!) should be referenced in the README.

Is that any more help?

Gerv

Comment 8

[Mike Hommey [:glandium]]

So, since things weren't entirely clear to everyone in the irc conversation, here is a summary of what needs to be done to build a NDK for a developer, provided we don't ship binaries:
- Install Xcode and possibly other things, I don't have a complete list, but that really doesn't matter for redistribution, as they are purely build tools.
- Download all tarballs from comment #0.
- Download the NDK tarball.
- Apply a few patches to the gcc and binutils sources from comment #0, as well as to the NDK build script.
- Run the NDK build script, which will build mpfr, mpc, gmp, gdb, the patched gcc, and the patched binutils (thereafter named toolchain).

What we would ship is the result of the above build, so, the toolchain, as well as files from the original NDK. These files include platform libraries and headers that are not built above, and are open source (I think they are under an Apache License), but they are not modified in any way. The only part of the original NDK that is modified is its build script.

Comment 9

[Gervase Markham [:gerv]]

OK, reading comment 8, we need to ship:

- the stuff we want to distribute (NDK libs, headers, plus compiled toolchain)

plus, in a "src" directory or similar:

- NDK source
- toolchain source
- patches to NDK, gcc and binutils
- build instructions, as in a more fleshed-out version of comment #8

Gerv

Comment 10

[John Ford [:jhford] CET/CEST Berlin Time]

I have uploaded the binary and source copies of this NDK to:

http://ftp.mozilla.org/pub/mozilla.org/mobile/toolchains/macosx/gcc4.6.3+gold/

(In reply to Gervase Markham [:gerv] from comment #9)
> OK, reading comment 8, we need to ship:
> 
> - the stuff we want to distribute (NDK libs, headers, plus compiled
> toolchain)

That's in android-ndk-r7c-darwin-x86.tar.bz2

> plus, in a "src" directory or similar:
> 
> - NDK source

included in android-ndk-r7c-darwin-x86-src.tar.bz2 src/ndk-src directory

> - toolchain source

included in android-ndk-r7c-darwin-x86-src.tar.bz2 src directory

> - patches to NDK, gcc and binutils

included in android-ndk-r7c-darwin-x86-src.tar.bz2 src directory

> - build instructions, as in a more fleshed-out version of comment #8

Included in the root of android-ndk-r7c-darwin-x86-src.tar.bz2.  build.sh is the exact script that generated the exact tarballs that I uploaded to ftp.

> Gerv

Comment 11

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

gerv, jhford: is there anything left to do here?

Comment 12

[John Ford [:jhford] CET/CEST Berlin Time]

Given comment 9 & 10, I think we're done here

Comment 13

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to John O'Duinn [:joduinn] from comment #11)
> gerv, jhford: is there anything left to do here?

(In reply to John Ford [:jhford] from comment #12)
> Given comment 9 & 10, I think we're done here

Gerv, you ok with closing this bug as FIXED?