Make it clear that modified versions may also be distributed.
I am the sole copyright holder for these ELinks files
so I can replace the licence like this.
This version of the licence is used in bind-9.5.0-P2.tar.gz.
Wikipedia claims ISC made the change in July 2007 after a request
from the FSF.
It is not necessary: when a rule has multiple commands in it, GNU Make
(which ELinks requires anyway) runs them one at a time, regardless of
the -j option, and skips the remaining commands when one of them
fails, regardless of the -k option. These options take effect at the
level of targets rather than individual commands.
http://elinks.cz/community.html says bugs should be reported
to elinks-users but patches should be sent to elinks-dev.
I guess elinks-users is more appropriate here.
This is so that contrib/mkdist need not delete that explicitly
(although it still does, in order to do the right thing with
a few older versions too).
The file could apparently be removed altogether (see recent
emails on elinks-dev) but a small change like this is less
likely to cause any surprises.
The primary motivation for this change is that the disclaimer now
refers to the author whereas it used to refer to the copyright holder.
The ISC license is the preferred license for new code in OpenBSD.
http://www.openbsd.org/policy.htmlhttp://www.openbsd.org/cgi-bin/cvsweb/src/share/misc/license.template?rev=1.2
I am also removing the reference to "the same terms as Perl itself"
because those terms are not being distributed with ELinks. Anyway,
Perl 5 is dual licensed under the Artistic License and the GNU General
Public License (version 1 or later), and the ISC license seems GPL
compatible to me.
The Free Software Foundation has distributed the GNU gettext manual
under at least two different licenses (a brief copyleft and GNU FDL),
but neither of those seems compatible with the GPLv2 of ELinks.
These are the same functions whose argument strings xgettext should
add to elinks.pot. I also searched for uses of the functions that are
known to take format strings, in case the callers might take the
format string from the result of another function, but didn't find any
new ones.
I constructed the list by grepping for "..." and looking for related
macros and va_list functions. Also grepped for "*fmt", and "*format"
but the extra functions found that way (add_date_to_string,
format_command, subst_user_agent, etc.) handle format strings that
don't have the same syntax as in printf: in particular, type safety
does not depend on the order of format specifiers like it does in
printf. Therefore, these format strings should not be subjected to
the "c-format" checks of msgfmt.
