Of late I’ve become the “build guy” in GNOME it seems. One thing I want to clear up is I do not actually care about building just because I think it’s fun or interesting in and of itself. No, the reason I care about building is because if software doesn’t build, then clearly it’s not being run. And if it’s not being run, then it’s not being tested. And if it’s not tested, then it will be crap. In other words, a competent build system is necessary for not producing crap (but not sufficient, obviously).
That motivation established, what I want to talk about is the GPL (and the LGPL). Specifically, this section:
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
The goal (spirit) of the GPL here is that if you receive binaries, you should be able to rebuild those binaries from source. Probably a number of people who work on GPL’d code may simply think that saying “The source is this git SHA1 from this repository” or “The source is this tarball” is enough – but things get interesting with the sentence plus the scripts used to control compilation and installation of the executable. It’s my understanding that this provision hasn’t been heavily explored, but a rough consensus is embodied here.
For example, an interesting question you might ask is – does that GPL provision apply to network build servers, like Open Build Service? I actually don’t know the answer, and OBS is under the GPL itself, so clearly they don’t have a problem distributing it. Now, the Xen stuff aside, OBS is basically just a wrapper around running RPM or dpkg, which in turn are just wrappers around Makefiles, which are in turn wrappers around the stuff that actually matters (the code). But still – were I to run a network build server like that, I’d probably be extra careful and embed in each build log the version of the build server (and link to source for that version), which they don’t appear to do right now.
How about the WebOS sources? There’s no links there to any scripts or details about their build system, or in general any clues for how you’d take those sources and rebuild them, and update your WebOS device with the updated binaries. Maybe that’s covered elsewhere – I didn’t look extensively.
I also recently looked at Zeroinstall, and I think they’re flirting with non-compliance, at least in some cases. For example, there’s little information on the ClanBomber feed about how it was built (with what version of 0install, with what version of what underlying distribution, etc.)
To be clear – I strongly believe in the GPL (and LGPL) – they’re a key foundation of our community and what we’re building. But complying with the provisions are not as easy as one might think, and I’d argue that this requirement is a key driver of “packages” as you see the in Debian and RPM worlds. They’re about having a full story for how you can reliably rebuild software and reinstall it on your computer. All the rest of the stuff they also do (configuration management, being able to dynamically turn a minimal install image into a desktop, etc.) is secondary.
TL;DR – If distributing binaries of GPL’d (or LGPL) software, “packages” (Debian/RPM style) for self-hosting builds are basically the state of the art. For cross builds, the Yocto project exudes competence. If you’re not using one of those systems and you skipped to this TL;DR section, you should go back to the top and read the whole post.
Colin Walters 
I think we can leave discussions about how to do the legal minimum to the lawyers, and just focus on doing the right thing. If you prepare a package or a binary for distribution, you should have a script that will, starting from source, produce those bits. With deb/RPM, there’s a standard way of dealing with source packages; if another build procedure is used, either you can reproduce those bits or you have a bigger problem than noncompliance.
The FLOSS approach is akin to the scientific method: others should be able to independently reproduce your results. This is what the GPL attempts to require, but if you’re a good software engineer you’re doing it already in house, so you just need to share your build script. It’s part of the source by the GPL definition.
Afaik the FSF also considers an RPM spec file to be one of those “scripts used to control compilation and installation of the executable”. Over the years I recall having seen a few projects that released source code and RPMs but not the spec file. I guess not everybody agrees with the FSF. Anyone know if this “scripts” part in the GPL has ever been tested in court? Would be nice to have the final word on it.
The GPL clearly states that “the scripts used to
control compilation and installation of the executable” must be provided. This isn’t some FSF interpretation, it’s in plain English.
If they ship the src.rpm, that includes a copy of the specfile, so shipping the specfile separately is not necessary. Of course, it’s a different story if they only ship binary RPMs.
A bit of off-topic, but I like how Nix handles their builds.
The packages are described in “nix expressions”, which describe all inputs, build-deps, and attributes, and the end result gets a cryptographic hash calculated from these attributes.
http://hydra.nixos.org/build/1597754/download/1/manual/#chap-writing-nix-expressions
So you always have all the elements you need to redo your build, but not only that, as a user you can have multiple versions of the same package (with slightly differring options for instance) installed.
Like Suse’s OBS, their continuous build system (Hydra) is also GPLv3+, btw.
Well, if you want to reproduce a binary rpm exactly, a source rpm is not enough, because you also require all the information for setting up the build environment and the exact versions of packages used both to produce the build environment and as dependencies in the build.
This is pretty much the reason why it is so hard to build any packages for other distros than the one you’re currently running – even if it’s just a different version like F15 vs F16. For all I care this should be a single command invocation and only involve a build service for performance and distribution reasons, but not for build reasons.
Benjamin, that’s what mock does.
I am a big fan of (and contributor to) Zeroinstall, and I it’s worth pointing out that failing to provide build scripts is a failing of the author, not of Zeroinstall. (I’m not disparaging the author of the bomberman feed, I am guilty of this myself for many of my own feeds).
Using 0compile is the preferred way to distribute source packages with 0install (the bomberman feed is a binary package only, see a source & binary example here:
http://gfxmonk.net/dist/0install/node.js.xml)
When used properly, not only will `0compile autocompile` fetch the source code, it will also fetch the required version of any _compile time_ dependency, compile according to the feed’s instructions, and create a local feed with the correct _runtime_ dependencies (which you can upload to a web server of your choice to redistribute). All of which will work regardless of what version your system happens to have installed (it supports using multiple versions of feeds on the same machine, as long as a given program invocation doesn’t require conflicting versions of the same library). Unlike automake and configure which go to obscene lengths to figure out what arcane system you might be building on, the ability to control dependencies (and versions) at build time means far less guesswork.
Note that this is cross platform and distro independent, which is why results may vary right now (since many packages will not actually work on windows, for example, and packaging gcc as a 0install feed is hard so my dependencies often fall back on the system package manager). But as a build _system_, it allows for far more portability and consistency than anything else listed here.
Maybe I should have said “Zeroinstall makes it extremely easy for others generate binaries out of compliance with the GPL”.
Note though that the Zeroinstall web site prominently links to “broken” feeds – the distinction may not be very clear to users.
As far as 0compile goes…it’s not bad. I would just enforce more strongly that complete reproduction instructions are embedded in the feeds.