Dear developers,

I have recently had a package rejected out of NEW on the grounds that the
debian/copyright file was incomplete for not listing the GFDL, which is used
as the license for some documentation that is shipped in the source but not
included in the binary packages.

This is not a legal issue; the GFDL documents are themselves distributed
properly, and everywhere they appear (i.e., in the source only), they're
accompanied by the license text. It is not a freeness issue, because the
documents are licensed under the GFDL in the manner which has been approved
for main. And it is not a Policy issue: Policy states only that every
binary package must include its copyright and license in
/usr/share/doc//copyright, there is no requirement at all that
debian/copyright list licenses for files that don't contribute to the
copyright of the binary packages.[1] (Indeed, the ftpmaster who rejected
the package acknowledges that this requirement is not applied to files such
as config.sub which do not impact the copyright of the binary packages.)

Finally, it is not in the least a regression vs. what's in the archive,
because this package was only in binary NEW and the GFDL docs in question
are already present in stable.

On Sat, Jul 19, 2008 at 05:40:24PM +0100, Steve Langasek wrote:

I do agree with you that this "policy" of FTP master should be
documented somewhere. Ideally, since it has been a well-known common
practice for years of NEW processing, it should become part of policy
(without quotes this time). To me it would look like as the application
of the typical process of our policy: status quo -> stone carving.

However, as you have read between the lines above, I do acknowledge
Joerg claim that it is a well-known practice: debian/copyright should
list licenses and copyrights on a source package basis. I frankly do not
understand your surprise, I doubt it is the first time you hit it ...

I also see the pragmatical reason of the current practice: files from
the source package can mix in complex ways during compilation, the only
reliable place where to define their legal details is the source
package. To be sure you have been exhaustive, you need to list all files
(OK, there are exceptions like config.sub, but I'm sure my point is
clear enough).

On Sat, Jul 19, 2008 at 11:50:59PM +0200, Stefano Zacchiroli wrote:

You're not agreeing with me. I disapprove of this policy; if it had gone
through the Debian policy process, I would have objected with the arguments
that I've given here. I also disapprove of the ftp team enforcing such a
requirement as part of binary NEW - it's not my problem that this is the
only time they look for such problems in the archive, and it's not
appropriate for the ftp team to couple my library transition to a completely
orthogonal "bug".

Hi,

on the whole I rather agree with Steve's point of view. It's great to see
that ftpmasters are doing thorough checks when they have to check
something but in this case, a simple library transition, they shouldn't
check for licenses and shouldn't refuse the update when the package has
already been accepted into main and that it's fine for main.

They could have filed a bug if they think that the copyright file should
be updated but rejecting the update is just wrong. There's nothing broken
in the package.

On Sat, 19 Jul 2008, Steve Langasek wrote:

Raphael Hertzog wrote:

It's always good to tell other people what is right and wrong. I'm sure
telling ftpmasters that what they do "is just wrong" improves the recognition
of ftpmaster work, the relationship maintained with them and the trust people
usually put in this team.

Regards,

Joey

On Sat, Jul 19, 2008 at 04:20:48PM -0700, Steve Langasek wrote:

... and that's why I added 'that this "policy" ...' in the paragraph above.

On Sun, Jul 20, 2008 at 03:20:57PM +0200, Stefano Zacchiroli wrote:

Le Sat, Jul 19, 2008 at 05:40:24PM +0100, Steve Langasek a écrit :

Hi Steve, Jörg, and everybody else,

from my newcomer point of view, I really think that a more formal
definition of the requirements of the FTP master team or at least the
individual requirements of Ryan Murray and Jörg Jaspert would really be
useful. Otherwise we have to rely on oral tradition, trial-and-error,
and other noise-amplifying methods of information transmission.

Debian is getting big and some developpers will probably never meet in
real life nor on IRC. Without a clear policy stating the functionning
and expectations of core teams such as the FTP master team, we just
increase the potental for misunderstandings, frustrations and
killing-of-the-fun, between individuals who must cooperate in the
absence of any occasions for friendly social interactions.

Have a nice day,

On Sun, Jul 20, 2008 at 16:27:25 +0200, Bas Wijnen wrote:

ITYM the non-bug.

Cheers,
Julien

On Sun, Jul 20, 2008 at 11:39:04PM +0900, Charles Plessy wrote:

You mean something like: http://ftp-master.debian.org/REJECT-FAQ.html ?

But I see your point. Also note that that list is not IMO clear enough
to explain Steve's reject (i.e. it does not state «we will reject any
source package with at least one file not accounted for by
debian/changelog»). But still it is a good start. I guess that it should
just be better advertised (pointer from developers-reference?) and
clarified as soon as cases like this one arise.

Cheers.

--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic -- Manoj \/ right keys at the right time