Re: Question about automatic generation of GPLv3 COPYING file

[Ralf Wildenhues]

* Brian Cameron wrote on Wed, Sep 17, 2008 at 06:05:57AM CEST:
>
> Indeed, it isn't uncommon for a module to have differing licenses.
> That is pretty normal.  However, I would think that the authors of the
> source code should be the people deciding how their code should be
> licensed, rather than an artifact of the build tools being used.  It
> seems hard to ensure that such differing licenses are indeed compatible
> in any sort of automatic fashion.

Certainly.

> Ralf Wildenhues wrote:
>>
>> You can use 'automake --foreign' or AM_INIT_AUTOMAKE([foreign]) to avoid
>> installing GNU-related files.  Without the 'foreign' option, automake by
>> default installs GNU defaults.  Not just for the COPYING file, but
>> several other things as well.  One of Automake's expressed goals is to
>> create packages that match GNU's rules.
>
> Thanks for the pointer.  I hadn't ever read the "GNU Coding Standards"
> document until you highlighted this point, and I found the document via
> Google.

> If automake's goal is to enforce GNU coding standards, then I could
> understand if it failed to work unless the file is present.  Thus
> forcing the authors to create the file or use the 'foreign' option
> (or not use automake).

Yes.

> However, just populating the file with an arbitrary license seems an
> error-prone way to enforce the standard.

It's not arbitrary.  Actually, until the switch to GPLv3, I cannot
remember anyone complaining about this feature of Automake.  I don't
think anybody ever complained that automake did not cater to BSD-
licensed projects here by default, for example.

This issue really is about setting the defaults in the presence of a
license that is not universally accepted.

>>> It seems a very unfriendly way to
>>> propagate a "viral" style license, and a way that could be really
>>> damaging to some users, and could generate bad feelings about the free
>>> software community.
>>
>> That to me really sounds a bit over the top.  Given there are very easy
>> ways to avoid this, and given that the current mode of operation is
>> documented very clearly, 
>
> While I do agree that it is documented reasonably, many people do not
> always read all related documentation.

The question is: do we need to cater for people who both don't read the
documentation and don't take care of writing a COPYING file themselves?
(Yes, this is a bit pointed.)

> People who might decide to use
> autotools to build non-GNU programs might not be familiar with the
> "GNU Coding Standard" or be aware that automake silently enforces a
> license.

But it doesn't "enforce" it!  It merely adds a sensible default COPYING
file (and what we're discussing is whether that "sensible" is good).  It
doesn't scribble in your README "This package is licensed under GPLv3,
see the COPYING file", neither does it put copyright notices at the top
of your source files.  Really the presence of some license in the
COPYING file is not sufficient to declare the project's license fully,
I think we've already agreed to that.

>> and a COPYING file has forever been installed
>> in the default mode, it would be confusing to many users if automake
>> would stop doing this now.
>
> There might be some confusion.  However, as I already explained there is
> already clearly some confusion about the way it currently works.  Note
> the following bug reports.  Clearly the authors of these modules were
> not aware of the ramifications of automake changing its default license
> to GPLv3:

Were any of them aware of the feature at all?  I.e., that COPYING was
added, but in prior automake versions is contained the GPLv2 text?

> To me, this sort of confusion is really more serious than any confusion
> like "where did my autogenerated COPYING file go".

None of the bug reports were about COPYING files that were gone or
overwritten.  That would be really bad style.

> Putting incorrect
> and unintended licenses in a module is more confusing than putting no
> license.


> As you probably noticed, I work for Sun.  Nobody at Sun has yet made any
> decisions about how automake on Solaris should behave.  I was just
> curious about whether disabling the feature by default might be possible
> so all options can be considered.

Sure.  I would ask you not to change Automake's mode of operation from
the default one, though.

> Currently Sun does not allow GPLv3 code to integrate into Solaris, which
> is why this is a particular issue at Sun.  So, until this issue is
> resolved, I guess Sun will probably have to avoid updating to the latest
> versions of automake which generate a GPLv3 license.  Though, disabling
> the feature by making 'foreign' the default might also be an option.
> Hopefully, Sun will approve of the GPLv3 license soon, so this issue
> just goes away.

Ah, so this is the heart of the matter: Sun hasn't approved of GPLv3
code, and Automake might, if the developer was not diligent enough to
take care of the license, add a GPLv3 file.

Look, I'm really the wrong person to discuss license matters with.
I hate the topic, I generally try to stay out of these discussions,
and could personally care less about the default mode of operation
of Automake.  I'd prefer a poll of all users, were this question not
one where FSF might have an interest in.

>> Changing the automake sources should be a one-line patch.
>> Getting this patch into FSF Automake sources will probably
>> be hard (i.e., I'd guess RMS will likely disapprove of it).
>
> I've cc:ed him.  Perhaps he can let us know his thoughts about this
> matter.

FWIW, the Cc: doesn't appear in the message I received.  You might want
to send him the whole discussion per mail.

> However, it does seem that the authors of any source code should be
> "free" to pick the license of their choice and never have a tool
> silently and automatically license code for them.

Which is what automake does: if you have chosen, it will not override
your choice.  Please, don't twist the facts.

Cheers,
Ralf