Re: Support script exceptions

[Ralf Wildenhues]

Hi Brett,

* Brett Smith wrote on Mon, Jun 21, 2010 at 04:22:28PM CEST:
> RMS and I have been looking at some of the GNU programs that are still
> on old licenses with exceptions, and figuring out whether and how they
> should be updated.  We had some unique ideas about some of the support
> scripts that a lot of GNU packages use, and we wanted to check with you
> to see if there's some "gotcha" that we're missing.
> 
> First, the scripts we're talking about are:
> 
> * compile
> * depcomp
> * elisp-comp
> * mdate-sh
> * missing
> * py-compile
> * symlink-tree
> * ylwrap

These scripts are all maintained in the Automake source tree; the
canonical upstream for symlink-tree is the GCC source tree.

When these files are dealt with, within the Automake package, there
is only lib/config-ml.in (also shared with GCC) which has the same
exception text as the above scripts.  Assuming it may be dealt with
in the same manner, that means Automake will be able to move to GPLv3+!
:-)

> After reviewing the intended uses of these scripts, and their licensing
> history, we believe that an exception is not really necessary to allow
> proprietary software developers to use the scripts in the ways we expect
> them to.  Thus, to keep our licensing as simple as possible, we think
> that the best thing to do for these scripts would be to remove their
> exceptions entirely -- and then upgrade them to GPLv3 while we're at it.

What if users modify these scripts and distribute the modified scripts
along with their non-free packages?  How is that expected to work?

> We understand that in the past, some proprietary software developers
> have had concerns that they would not be able to use these scripts in
> the usual way as part of their compilation processes without some kind
> of exception.  We believe these developers are mistaken, but we don't
> want to cause them any undue concern.  So while we'd still like to
> remove the exception, we think it would be appropriate to provide
> documentation explaining our position that even without it, proprietary
> software developers can still use these scripts.  If we can keep it
> short enough, that statement might even appear in the headers, in place
> of the exception.  That would still be better for us because we wouldn't
> have to worry quite *as* much about making sure the language was legally
> precise, etc.

Yes, I think such a statement would be prudent, if it is decided that an
exception is not needed.

Thanks for getting back on this topic!

Cheers,
Ralf