Eric Blake
2018-09-03 14:13:13 UTC
There has been concern expressed in another (non-public) list that the
AC_PROG_INSTALL macro in autoconf may be causing unnecessary grief to
downstream packagers. This macro requires the existence of an auxiliary
program named 'install-sh' or the older spelling 'install.sh', although
autoconf itself does not install it, and merely recommends that a user
either grab the copy from Autoconf's sources or from Automake (where
Autoconf's copy came from Automake).
Furthermore, when using 'automake --install' (which can be triggered by
Autoconf's 'autoreconf -i'), Automake will install a copy of
'install-sh' that was originally written by the X Consortium. While the
license on that file is permissive enough to be included in the GPL,
there is concern that it might be at odds with projects that use the
Autotools but are relying on the GPLv3 exception that allows the use of
Autotool-provided output in order to license a project under a different
license than GPL.
I am not a lawyer, and do not have an opinion on whether the concern is
valid or spurious - however, I _do_ want to make life as easy for
downstream projects to use Autoconf in such a way that they have a
minimum of legal hurdles to clear, so anything we can do to alleviate
the concern, whether or not the concern has any legal standing, is still
a wise course of action.
On the other hand, note that install-sh is only ever copied verbatim
into a project, and does NOT form the basis of any of the source code
compiled into a final binary, but is ONLY used as a 'make install'
helper script to make installing the final binary easier to do without
relying on the existence of programs that the GNU Coding Standards does
not state to be universally portable. On that grounds, its presence in
a tarball does not change the license of the final binaries created by
compiling and installing the tarball, but MAY be grounds to list that
distinct license/copyright in a manifest describing the copyright of all
files included in the tarball. So on that front alone, we are indeed
making life more complicated for someone trying to generate such a
package manifest, when we recommend the copying of a non-FSF file.
Note that the most recent version of 'install-sh' as installed by
Automake states:
# Copyright (C) 1994 X Consortium
Meanwhile, the autoconf manual states:
Of the other files that might be used with @command{configure},
@file{config.h.in} is under whatever copyright you use for your
@file{configure.ac}. @file{config.sub} and @file{config.guess} have an
exception to the GPL when they are used with an Autoconf-generated
@command{configure} script, which permits you to distribute them under the
same terms as the rest of your package. @file{install-sh} is from the X
Consortium and is not copyrighted.
This is contradictory, and needs to be fixed in the Autoconf manual.
However, the question on the floor is whether the fix is merely
rewording that sentence to describe the actual copyright and permissive
license, or if a better fix might be possible, such as rewriting
'install-sh' from scratch so that we can ship a version of the file that
is completely copyright FSF and therefore uses the identical
GPLv3+exception as the rest of the files we care about, rather than
having to play the legal games of whether the X Consortium copy
introduces any wrinkles in the first place.
Is anyone willing to take on a clean-room reimplementation of the
functionality of install-sh? If so, I can write up a list of
requirements for what your implementation must provide; you must write a
shell script that has that functionality, and without using any
reference to the existing install-sh file, and where your work can have
copyright assigned to FSF; but you can use GNU Coreutils' install
program for a reference on functionality questions (I consider myself
ineligible for such a clean-room reimplementation, since I am one of the
people that has already made edits to the 'install-sh' belonging to
Automake, but I have no qualms in reviewing your work for accuracy and
portability).
For further information, we can look at how the file appears now
compared to the version we originally lifted from X11R5 back in Nov
1995, and ignoring whitespace changes (the original file used TAB, the
current version uses space):
$ cd automake.git
$ git log 042e80a7 -1
commit 042e80a71210ad691473fd7f37ff71c9c376a129
Author: Tom Tromey <***@redhat.com>
Date: Sun Nov 12 23:01:53 1995 +0000
Initial revision
$ git rev-parse --short=8 HEAD
a348d830
$ git diff -w -b 042e80a712..HEAD lib/install-sh | grep @@
@@ -1,238 +1,518 @@
So right away, we see that nearly the entire file has been rewritten in
some form or another over time by contributors that have all assigned
copyright to the FSF, as the differences form a single hunk. What's
more, we can now review which lines remain unchanged from our original
copy into the current age, and see that it is mostly comments or bare
control flow, which on its own doesn't do much:
$ git diff -w -b 042e80a712..HEAD lib/install-sh | sed 's/^[^ ].*//' |
cat -s
#!/bin/sh
# install - install a program, script, or datafile
#
# Calling this script install-sh is preferred over install.sh, to prevent
# when there is no Makefile.
#
# This script is compatible with the BSD install script, but was written
# from scratch.
rmcmd="$rmprog -f"
case $1 in
-g) chgrpcmd="$chgrpprog $2"
shift
fi
esac
done
exit 1
else
fi
dst=$src
else
# might cause directories to be created, which would be especially bad
# if $src (and thus $dsttmp) contains '*'.
exit 1
fi
exit 1
else
fi
else
fi
shift
else
fi
done
fi
fi
# If any of these fail, we abort the whole thing. If we want to
# ignore errors from any of these, just make sure not to ignore
# Now rename the file to the real destination.
AC_PROG_INSTALL macro in autoconf may be causing unnecessary grief to
downstream packagers. This macro requires the existence of an auxiliary
program named 'install-sh' or the older spelling 'install.sh', although
autoconf itself does not install it, and merely recommends that a user
either grab the copy from Autoconf's sources or from Automake (where
Autoconf's copy came from Automake).
Furthermore, when using 'automake --install' (which can be triggered by
Autoconf's 'autoreconf -i'), Automake will install a copy of
'install-sh' that was originally written by the X Consortium. While the
license on that file is permissive enough to be included in the GPL,
there is concern that it might be at odds with projects that use the
Autotools but are relying on the GPLv3 exception that allows the use of
Autotool-provided output in order to license a project under a different
license than GPL.
I am not a lawyer, and do not have an opinion on whether the concern is
valid or spurious - however, I _do_ want to make life as easy for
downstream projects to use Autoconf in such a way that they have a
minimum of legal hurdles to clear, so anything we can do to alleviate
the concern, whether or not the concern has any legal standing, is still
a wise course of action.
On the other hand, note that install-sh is only ever copied verbatim
into a project, and does NOT form the basis of any of the source code
compiled into a final binary, but is ONLY used as a 'make install'
helper script to make installing the final binary easier to do without
relying on the existence of programs that the GNU Coding Standards does
not state to be universally portable. On that grounds, its presence in
a tarball does not change the license of the final binaries created by
compiling and installing the tarball, but MAY be grounds to list that
distinct license/copyright in a manifest describing the copyright of all
files included in the tarball. So on that front alone, we are indeed
making life more complicated for someone trying to generate such a
package manifest, when we recommend the copying of a non-FSF file.
Note that the most recent version of 'install-sh' as installed by
Automake states:
# Copyright (C) 1994 X Consortium
Meanwhile, the autoconf manual states:
Of the other files that might be used with @command{configure},
@file{config.h.in} is under whatever copyright you use for your
@file{configure.ac}. @file{config.sub} and @file{config.guess} have an
exception to the GPL when they are used with an Autoconf-generated
@command{configure} script, which permits you to distribute them under the
same terms as the rest of your package. @file{install-sh} is from the X
Consortium and is not copyrighted.
This is contradictory, and needs to be fixed in the Autoconf manual.
However, the question on the floor is whether the fix is merely
rewording that sentence to describe the actual copyright and permissive
license, or if a better fix might be possible, such as rewriting
'install-sh' from scratch so that we can ship a version of the file that
is completely copyright FSF and therefore uses the identical
GPLv3+exception as the rest of the files we care about, rather than
having to play the legal games of whether the X Consortium copy
introduces any wrinkles in the first place.
Is anyone willing to take on a clean-room reimplementation of the
functionality of install-sh? If so, I can write up a list of
requirements for what your implementation must provide; you must write a
shell script that has that functionality, and without using any
reference to the existing install-sh file, and where your work can have
copyright assigned to FSF; but you can use GNU Coreutils' install
program for a reference on functionality questions (I consider myself
ineligible for such a clean-room reimplementation, since I am one of the
people that has already made edits to the 'install-sh' belonging to
Automake, but I have no qualms in reviewing your work for accuracy and
portability).
For further information, we can look at how the file appears now
compared to the version we originally lifted from X11R5 back in Nov
1995, and ignoring whitespace changes (the original file used TAB, the
current version uses space):
$ cd automake.git
$ git log 042e80a7 -1
commit 042e80a71210ad691473fd7f37ff71c9c376a129
Author: Tom Tromey <***@redhat.com>
Date: Sun Nov 12 23:01:53 1995 +0000
Initial revision
$ git rev-parse --short=8 HEAD
a348d830
$ git diff -w -b 042e80a712..HEAD lib/install-sh | grep @@
@@ -1,238 +1,518 @@
So right away, we see that nearly the entire file has been rewritten in
some form or another over time by contributors that have all assigned
copyright to the FSF, as the differences form a single hunk. What's
more, we can now review which lines remain unchanged from our original
copy into the current age, and see that it is mostly comments or bare
control flow, which on its own doesn't do much:
$ git diff -w -b 042e80a712..HEAD lib/install-sh | sed 's/^[^ ].*//' |
cat -s
#!/bin/sh
# install - install a program, script, or datafile
#
# Calling this script install-sh is preferred over install.sh, to prevent
# when there is no Makefile.
#
# This script is compatible with the BSD install script, but was written
# from scratch.
rmcmd="$rmprog -f"
case $1 in
-g) chgrpcmd="$chgrpprog $2"
shift
fi
esac
done
exit 1
else
fi
dst=$src
else
# might cause directories to be created, which would be especially bad
# if $src (and thus $dsttmp) contains '*'.
exit 1
fi
exit 1
else
fi
else
fi
shift
else
fi
done
fi
fi
# If any of these fail, we abort the whole thing. If we want to
# ignore errors from any of these, just make sure not to ignore
# Now rename the file to the real destination.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org