Hi Frank,
On Wed, Sep 27, 2006 at 06:14:17PM +0200, Frank Küster wrote:
> With the freeze coming nearer, I am unsure how to deal with this. I
> currently see two options:
> a) Either remove all problematic files from the orig.tar.gz right now,
> with the option to add them again later
> b) Or keep the bug open and only do the removal in the last sensible
> moment, as the release team judges.
> The good thing about (a) is that any possible breakage in other packages
> (e.g. packages that need non-free components for the build process) have
> good chances to be detected, while some might slip into etch with option
> (b). On the other hand, option (a) is not in the interest of our users,
> and/or the release process:
> - if we do not re-add files that turn out to be free, they will be
> missing in etch, which doesn't serve our users,
> - if we re-add them, this would mean to allow versions of tetex-base
> into etch after the freeze that do not fix any RC bug. That's against
> the rules, and I don't know whether you are willing to grant
> exceptions with licensing issues.
The guidelines I believe we should be using when deciding such a bug is RC
as follows:
- If upstream has been contacted and relicensing is in progress pending
contact with each of the contributors, the bug is not RC.
- Otherwise, if the license clearly imposes conditions on
use/modification/distribution that are recognized as non-free, the bug
is RC.
- Source code for documentation is not RC unless it's required by the licene
(e.g., the GPL).
- If the license does *not* clearly prohibit exercising any of the necessary
freedoms, but is merely ambiguous (granting modification without
explicitly granting redistribution, or granting both in a way that leaves
doubt as to whether the intent is to permit redistribution of modified
versions), and there is a reasonable belief on the part of the maintainer
that it was the *intention* of the copyright holder to release the work
under a free license, the bug is not RC with the condition that the
maintainer is expected to seek a clarification.
- If a component of a package lists a non-free license, but is distributed
as part of a larger work that includes a blanket license statement,
resulting in ambiguity about which license the component is distributed
under, the bug is not RC with the condition that the maintainer is
expected to seek a clarification.
- If the maintainer determines that it is impossible to contact a copyright
holder, or the copyright holder is contacted and refuses to clarify the
license terms, the bug is again RC.
For the last three points, I'm inclined to use the "$release-ignore" tags,
because I think one stable release cycle is long enough for the maintainer
to attempt to contact the upstream and either get a clarification or
determine that no clarification is possible.
Do the other members of the release team have any thoughts on these?
The consequences of these guidelines for the tex licensing bugs seem to be
as follows:
345604:
ConTeXt upstream says they aren't interested in relicensing; RC bug.
csname.txt: etch-ignore (due to blanket license statement?).
unixtex.ftp: etch-ignore.
l2tabuen.pdf, pdftex-a.pdf, fontinstallationguide.pdf, l2kurz.pdf:
ok per the GFDL GR
l2tabu.pdf: ok per James Troup in bug #384019 (?)
doc/encspecs/ and examples: etch-ignore.
356853:
reasonable belief that the files are intented to be under free licenses;
etch-ignore.
- except for shapepar.sty, under a non-commercial license: RC
363061:
palatcm.sty: implicit permission grant to distribute modified versions
(etch-ignore), but requires renaming files -- RC
[BTW, copyright law doesn't govern use in the first place; any license that
you have to accept the terms of in order to use the work is an EULA, and
pretty much non-free.]
amslatex: upstream relicensing process, etch-ignore
seminar.sty: statement of author intent, etch-ignore
368968:
ongoing discussion with upstream; etch-ignore
Have I overlooked any other outstanding issues in these bugs, or missed
important details about any of the files?
For the issues that remain listed as "RC" here, I think the prudent course
of action is to remove them immediately from the orig.tar.gz so that we can
cross these RC bugs off. If you do get feedback permitting one or more of
these files to be distributed under a DFSG-compliant license, I'm ok with
allowing those files to be re-added during the freeze.
> As for the possible breakage, I've sent a mail to debian-devel[3],
> listing all affected packages and maintainers, but hardly got any
> response. And frankly, I don't expect much even if we mail each
> maintainer individually, because most don't know about the internals of
> their packages' document creation setup, and hence have no idea how to
> check which LaTeX packages are used. Needless to say, the TeX Task
> Force also does not have the time to check packages by the dozen (283
> Build-Depends, unnumbered Depends).
Once the files in question have been removed, are these things that can be
checked with rebuild tests? The main problem to worry about is packages
which need a style that's been removed and fail to build, correct?
If so, we can ask for help from debian-qa for a targetted rebuild test.
This makes it even more important to get these files removed sooner rather
than later, to give us enough time for those rebuilds.
On Wed, Sep 27, 2006 at 07:20:44PM +0200, Frank Küster wrote:
> What about option c:
> - Remove all problematic files at once from tetex-base's orig.tar.gz,
> - but keep them installed with texlive until somewhen at (release - n
> weeks), n=2,3
> - state that bugs that affect texlive's ability to be used as a teTeX
> replacement may be NMU'ed.
I don't understand, what's the advantage here? If the bugs are present in
both texlive and tetex, surely we want to treat them the same for the
release, which means we should try to treat them the same now as well.
> These bugs are in most cases just Depends: lines that only mention teTeX
> and do not allow texlive as an alternative. Among the packages any
> texlive package conflicts with, there might be some more. Some other
> conflicts just indicate that the package is not up-to-date, and texlive
> installs the newer version contained by upstream. Norbert?
Sorry, I don't follow at all how this has to do with licensing bugs.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
