[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support script exceptions

From: Brett Smith
Subject: Re: Support script exceptions
Date: Tue, 22 Jun 2010 09:26:19 -0400

On Mon, 2010-06-21 at 19:33 +0200, Ralf Wildenhues wrote:
> > 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.

Understood.  I should explain: the reason I'm mailing bug-gnulib is that
these scripts are so fundamental -- some of them often used even in
packages that don't use Automake -- that we wanted to get feedback from
more core GNU maintainers.  gnu-prog-discuss seemed like overkill,
though, so here we are.

> 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+!

Unfortunately, I think that one *is* going to need an updated exception.
config.sub, config.guess, and config-ml.in all have the same exception
text as the other files I'm talking about, but we're not so sure that
proprietary software developers can do what they need without an
exception in those cases.  Given this doubt, we would rather have they
still have an exception.  We're working on that too.

> > 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?

The modified version they make *would* be considered a derivative work,
and if they distribute it, they would need to follow the GPL's terms.
But that shouldn't be much of a problem: since they would already be
distributing the script in source code form anyway (unless they're doing
something really bizarre), the main conditions they would have to worry
about are providing a copy of the license, and not messing with any of
the legal notices.  I don't think this will be particularly burdensome.
Programs they write that call these scripts in the usual way still
wouldn't be considered derivative works; those could remain proprietary.

Hope this helps,

Brett Smith
License Compliance Engineer, Free Software Foundation

Support the FSF by becoming an Associate Member: http://fsf.org/jf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]