copyright problem with install-sh, request for clean-room rewrite

[Eric Blake]

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 <address@hidden>
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