Re: How to deal with teTeX's and texlive's RC licensing bugs
Steve Langasek <firstname.lastname@example.org> wrote:
> The guidelines I believe we should be using when deciding such a bug is RC
> as follows:
Thank you for your answer.
> Have I overlooked any other outstanding issues in these bugs, or missed
> important details about any of the files?
Not in the bugs, but since this all got very confusing, I stopped
forwarding to the bug all problems I found. They are all collected in
the Wiki at http://wiki.debian.org/ProblematicCtanPackages
The ones not discussed so far are:
| euler: LPPL according changelog, but no indication in file.
| adrconv: No license at all for the documentation
| antp: PD according to catalogue, no statement in the files, no
| sources; contacted upstream
| citesort.sty: no license statement
| index.doc: no license statement - probably unused
| dinbrief: lppl 1.1+, but with additional restrictions which are non-free
| a4wide.sty: no license statement, obsolete, uses a4.sty, should be removed
| bar.sty: no license statement except "don't modify", latex2.09, authors
| are no longer at their listed affiliation => should be removed
Plus some under the heading "less serious problems".
> 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.
> 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?
Yes, that's the main concern, and it should be testable by rebuild
tests. The other problem is with packages that have an ordinary
Depends, here tests cannot be automated. However, if the package is
actually used by some people, but problems aren't detected immediately
because the removed files are used rarely and a problem shows up only in
certain circumstances, then I think the package can stay in main and
only has a normal or important bug, correct? Bugs in mostly unused
packages are likely to slip through, anyway...
> 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.
Okay. Will try to do it during the weekend.
> 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.
There would have been an advantage only if you had not said "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.", because even without re-adding them to
etch, they would be available to etch users if they choose texlive (or
install texlive packages in parallel with tetex, as far as that is
possible). With that statement from the Release Managers, there's no
>> 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.
Well, in the hypothetical case that you wouldn't let removed, now-free
files be re-added during the freeze, it wouldn't help our users if we
tell them "they are still available in texlive" if at the same time they
cannot use texlive because other packages they need just don't permit
it. And as I understand,
Depends: tetex-bin | texlive-base-bin, tetex-extra | texlive-latex-recommended
is just a wishlist bug and doesn't ordinary justify an NMU.
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)