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 compiler
a 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 above
3) a compiler which takes a "how to install this product" script, a
bunch of product files, and makes an executable out of them.
