Brian Thomas Sniffen wrote:
But why do I have permission to distribute the GPL'd installer that way (let's say it incorporates Emacs for some reason)? This isn't mere aggregation -- it would be if the files were next to each other on a CD and otherwise unrelated, but it's clear that there are dependencies between them.
borderline. Take an pair of obvious examples - a Zipfile package and a compilera zipfile package can be GPLled, but produce self-extracting archives that are themselves not always GPLled (or contain non-GPLled code) whose status is dubious due to decompression code being bonded to the archive; however you could also bundle the archive with the GPLled tool (straight combination or aggregation of the archive and the GPLled binary) completely legally, and the same tool used on a self extractor archive would cleanly extract the archive without touching the bonded decompator.
a compile will take non-GPLled code, process it, and produce a non-GPLled executable; the exact translation of source to object will by necessity include short sequences of code which are themselves part of the compiler, and of course LGPLled libraries....
At what point does the unpackager/installer become an interdependency? most installers come in three forms 1) a archive containing the product, and a uncompactor capable of extracting the files from the archive, and correctly placing them (possibly under the control of a script embedded in the archive)
2) an archive containing the product *bonded with* the uncompactor as above3) a compiler which takes a "how to install this product" script, a bunch of product files, and makes an executable out of them.