Re: debian/copyright for files not part of the binary packages?
On Sun, Jul 20, 2008 at 03:20:57PM +0200, Stefano Zacchiroli wrote:
> > You're not agreeing with me.
> ... and that's why I added 'that this "policy" ...' in the paragraph above.
Which is not something I agree with. I don't think this is a question of
documentation, I think this is a question of scope creep.
> > 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".
> I understand that can be pissing off that a pre-existing bug in the
> archive (according to FTP masters POV) causes a NEW reject, but *if* you
> agree with them that it is a bug, then it doesn't matter when it get
> recognized.
Well, a) I don't agree that this is a bug, and b) it matters that
developers' work not be blocked by orthogonal and *low impact* issues. By
making this a blocker for binary NEW, it's given an importance far out of
proportion.
> Then, I concur that their power in rejecting the package instead of simply
> submitting the bug report is strong, but they are the ultimate responsible
> of what is in the archive after all.
They're responsible for making sure it's legal, complies with the DFSG, and
doesn't break the archive network; none of these requirements apply here. I
certainly *don't* think the ftp masters should be arbiters of what goes into
the archive very far beyond that; we have other, better procedures for
dealing with routine bugs.
> > Take for example the package in question, freetds. Those GFDL docs have
> > been in the source since the last time the soname changed, in 2005. (This
> > is easily confirmed by the changelog; there have been no new upstream
> > versions accepted into Debian between the last soname change and now, so any
> > GFDL docs have been in the orig.tar.gz all along). The package was fine for
> > binary NEW back then, and it should be fine now.
> Probably they did not check thoroughly as now the content, and they did
> now. Should the past overlook be a reason for overlooking now what they
> consider an issue?
No, my position is that they have no grounds for considering it an issue,
and it was not well communicated that they intended to make it an issue
(given that it was not an issue in the past).
> DD words can't be trusted on this IMO. Simple reason: a DD mistake in
> this respect can cause the Debian project to be liable for distributing
> illegal stuff, and the responsibility of that would fall first of all on
> FTP masters (at least according to folklore, IANAL and I didn't check
> the applicable laws to see if this is really the case or not).
This is something that can happen at any point, not just when a package goes
through NEW. If freetds were really an issue, it would have been an issue
for three years and our stable release would be contaminated. We *already*
have to trust DDs to not screw up the licensing of existing packages when
they package new upstream versions that don't go through NEW; there's no
reason to single packages out when they do go through binary NEW.
> But still you miss my point or I explained it badly: copyright of source
> files can mix arbitrarily in binary files. As it would be foolish to ask
> FTP masters to check the whole build process to discover source->binary
> flow, a simple rule has been put in place: copyright/license of all
> source files should be declared in debian/copyright.
So what, exactly, do you intend for the ftpmasters to do in the case that a
single source package contains software that's licensed under incompatible
licenses - like, say... the GPL and the GFDL?
If "it would be foolish to ask FTP masters to check the whole build process",
then listing the licenses is a waste of time because it does not give you
the information to distinguish the legal cases from the illegal ones. You're
still either relying on the maintainer to generally know what they're doing,
or depending on the ftp team to fully vet the licenses... or authorizing the
ftp team to blindly reject packages if they contain incompatible licenses
anywhere in the source, regardless of how much collateral damage it causes.
Following the last to its logical conclusion, we would have to repack/split
upstream tarballs to get them through NEW even if there are no actual
license problems. I'm not ok with that.
> I think we didn't ask them to do the checks at *any* particular time,
> but they are responsible of what ends up in the archive. It is
> reasonable to let them use whatever practice they want to achieve
> archive content screening.
When their practices involve rejecting packages that it's perfectly
legitimate to distribute in main, I strongly disagree.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: