Dear David, dear AMSTech team,
(CC: - Free Software Foundation licensing team
- gnewsense-dev mailing list
- Debian bug report)
this is a collection of concerns and comments - numerated with small
letters - concerning your license proposal for the amslatex package. The
pieces were taken from the gnewsense-users mailing list [1] and the
Debian bug report [2]. Sorry for all the comments I forgot to paste.
The complete license proposal can be found at the bottom of this email [3].
We are CCing the FSF licensing team because your license proposal raised
legal and technical questions which seem to be off high impact. We
would hence ask the FSF to comment and clarify wherever possible.
Before each comment I'll put the part of the license it is concerned with.
(a)
> This includes -- but is not necessarily limited to -- the
> following files:
[... long list of .dtx and .ins as well as unpacked files snipped]
One question remains: Are all files currently marked
as "Copyright by AMS"? Some at least have; but if not all, then the AMS
should either claim in their 00LICENSE file to have the copyright or to
have the permission of the copyright holders.
(b)
> Incidentally, a number of the associated files (especially various
> documentation files and release notes) do not have any included
> license statement. Is that something that we need to address or is it
> understood that they are are covered by the same license in associated
> files?
If the documentation is generated from a dtx file, but has no license
statement in the readable text, I don't see a need. However, any other
documentation (e.g. READMEs) should have a copyright statement unless
the content is trivial.
(c)
> I suspect that the safest thing for us to do in the future is
> include a 00LICENSE.txt file with wording similar to the above in all
> of our distributions.
Yes, ideally covering docs, too.
For clarity it would be nice if each file could contain a simple (1 or 2
line) header stating the licence, or 'see licence at $PATH/to/LICENCE'.
(d) The biggest issue is about the renaming condition for modified files:
> Unlimited copying and redistribution of this file are permitted as
> long as this file is not modified. Modifications, and
> distribution of modified versions, are permitted, but only if the
> resulting file is renamed.
For the moment, I have two questions/comments:
- How does this licence apply to downstreams (eg, the 2nd level of
distribution from AMS). Do they need to create a new file name (thereby
having 3 file names for code thats potentially 95% the same)
- As a result of the file renaming, anything which wants to source the new
version will need to be updated to source the new file name.
If they're going to go through with this then some form of documentation
about how to do this renaming properly would be nice. Or better yet: a
script.
Source code of LaTeX files would have to be modified in order to use a
modified version of a file of the amslatex package.
Different license proposal: "Modifications, and distribution of modified
versions, are permitted. Distributed modified files must have a file
name that is different ..."
If soft linking is not an option and we ignore inertia for a moment,
then it seems likely that there will be a parallel This-Is-Not-AMS-LaTeX
version of the package that will be used by all distros, because (or
just in case) they need to be able to make changes to the original version.
But we probably can't ignore inertia, because people can't and won't
change all their sources overnight. So in theory everybody (distros)
would be free to fix a bug and distribute the changed version, but in
practice that is not an option because of compatibility issues.
With respect to the question of softlinks: All kpathsea-based systems
(that's at least TeXLive and its Mac relatives, I don't know about
MikTeX) support an alias file. This allows you to load
amsfoo-renamed.cls if amsfoo.cls is requested. LaTeX, however, will
still complain that the wrong package has been loaded *if* the package
identification in \ProvidesPackage has been changed.
Therefore, IMHO, the wording of the LPPL does make sense to preserve
file integrity, but the "Knuth wording" used by AMS does not; the mere
requirement to change the filename is moot.
TBH, I'd prefer the 'changes as diffs' approach over 'rename on
change'
With AMS proposed licence, is it possible to write a *replacement* file
with the same name, and include it in the bundle. it looks like it is.
This is the same 'problem' PHP have with thier licence requirements (a
complete PHP rewrite can be called something with php in the name, but
a derivative can't).
(e) Renaming directories?
Does the renaming condition apply to directories as well?
In all systems following the TDS, path does matter, and moving a file
from $TEXMF/tex/latex/ams/ to $TEXMF/myengine/latex/ams/ will make it
inaccessible for LaTeX in a usual setup.
So far for the comments.
Thanks a lot for caring about our concerns.
Greetings
Benedikt Ahrens
[1] http://lists.gnu.org/archive/html/gnewsense-users/2009-09/msg00098.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477060
[3]
The complete license proposal:
Here's a copy of the draft license that I propose to append to the
current AMS-LaTeX distributions. Do you have any questions or
comments before I release it?
The AMS is in the process of restating and updating the license on all
of its distributed files in order to bring the license into line with
current standards of "free" software licenses. Since it will take
some time to update all individual files, we're distributing this file
now to clarify the license on currently-distributed files.
The following license replaces any conflicting statement found inside
any files distributed by the American Mathematical Society as part of
the AMS-LaTeX distribution, including the amscls and amsmath
components, and related files.
Unlimited copying and redistribution of this file are permitted as
long as this file is not modified. Modifications, and
distribution of modified versions, are permitted, but only if the
resulting file is renamed.
This includes -- but is not necessarily limited to -- the
following files:
ams-c1.ins v2.20 (2004/08/03)
ams-m1.ins v1.05 (2000/05/25)
amsalpha.bst v2.0 (2000/03/27)
amsbsy.dtx v1.2d (1999/11/29)
amsbsy.sty v1.2d (1999/11/29)
amscd.dtx v2.0 (1999/11/29)
amscd.sty v2.0 (1999/11/29)
amsdtx.cls v2.06 (2004/08/06)
amsdtx.dtx v2.06 (2004/08/06)
amsgen.dtx v2.0 (1999/11/30)
amsgen.sty v2.0 (1999/11/30)
amsldoc.cls v2.06 (2004/08/06)
amsldoc.tex v2.09 (2004/04/06)
amsmath.dtx v2.13 (2000/07/18)
amsmath.sty v2.13 (2000/07/18)
amsmidx.dtx v2.01 (2004/08/03)
amsmidx.sty v2.01 (2004/08/03)
amsopn.dtx v2.01 (1999/12/14)
amsopn.sty v2.01 (1999/12/14)
amsplain.bst v2.0 (2000/03/27)
amstex.sty v1.2f (1999/11/15)
amstext.dtx v2.01 (2000/06/29)
amstext.sty v2.01 (2000/06/29)
amsthdoc.tex v2.20 (2004/08/03)
amsthm.sty v2.20 (2004/08/06)
amsxtra.dtx v1.2c (1999/11/15)
amsxtra.sty v1.2c (1999/11/15)
instr-l.tex v2.20 (2004/08/06)
subeqn.tex v1.2c (1999/11/29)
technote.tex v2.0 (1999/11/15)
testmath.tex v2.0 (1999/11/15)
thmtest.tex v2.01 (2004/08/02)
upref.dtx v2.01 (2004/07/29)
upref.sty v2.01 (2004/07/29)
Please address any questions to
American Mathematical Society
Technical Support
Publications Technical Group
201 Charles Street
Providence, RI 02904
USA
tel: (401) 455-4080
(800) 321-4267 (USA and Canada only)
fax: (401) 331-3842
email: tech-supp...@ams.org
Incidentally, a number of the associated files (especially various
documentation files and release notes) do not have any included
license statement. Is that something that we need to address or is it
understood that they are are covered by the same license in associated
files? I suspect that the safest thing for us to do in the future is
include a 00LICENSE.txt file with wording similar to the above in all
of our distributions.
Best wishes,
David.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
