Re: license in generated files

[Ralf Wildenhues]

* Karl Berry wrote on Fri, Dec 11, 2009 at 01:21:12AM CET:
>     But the license concerns Makefile.in only, since the Makefile is never
>     distributed, no?
> 
> We don't do it in GNU packages, but it might be in other cases ...  And
> besides, whether the Makefile is distributed or not, it deserves a
> relevant license statement.  In general, it's good for generated files
> to carry licenses.

I'm not sure what you are hinting at here.  Distributing generated
config.status, Makefile, or config.h files is basically always an error.
Installing a generated and mutilated (name-mangled so the defines are
not generic any more) config.h file is about the most I can imagine.

Let's deal with config.h and config.h.in below; I understand there might
be issues there.

Of the rest of these files, most of them *do* carry some kind of license
statement.  The license refers to the respective .in file.  The files
also carry a prominent notice that they were generated from the
respective .in file.  Are we discussing the question whether this is not
enough of a statement?  If yes, are we discussing the legal value of
these statements, or the human-understandability aspect of this?

The config.status file does not carry a license at the top, only
  ./config.status --version

prints a statement.  But it's basically always an error to distribute
this file.  I assume that this file should carry a license statement at
its top?  FWIW, the current header of this file looks like this:

  #! /bin/sh
  # Generated by configure.
  # Run this file to recreate the current configuration.
  # Compiler output produced by configure, useful for debugging
  # configure, is in config.log if it exists.

The config.log and config.cache files do not carry a license statement.
The former does not consists of any code, the latter only of variable
assignments.  The latter might be useful to turn parts of it into a
config.site file for users/distros/whoever.  I'm not sure whether you
intend for them to carry licenses, and if yes, I couldn't imagine
anything other than (paraphrased) "FSF does not put any restrictions on
the use of these files".

>     > > 2) [More important.]  How about having autoheader add the same 
> statement
>     > >   to config.in?
> 
>     Sounds like a good idea, although the amount of copyrightable content is
>     pretty limited there (thinking of original content, not just pure number
>     of lines).
> 
> I know, but I think it's plenty enough to be copyrightable.  And in any
> case, an explicit statement is highly desirable.

Yes, understood.  Also, since config.h (sic!) is the most likely to have
its contents be copied/mangled into a project_config.h and installed
(and possibly binary packages of the project which carry this generated
file being distributed), we should fix this.

One technical aspect I'm not yet sure of is whether to invent
AH_COPYRIGHT or to try to let m4 turn AC_COPYRIGHT contents into text
suitable for a C comment (i.e., escape instances of `*/').

Thanks,
Ralf