[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian/copyright for files not part of the binary packages?

On Sat, Jul 19, 2008 at 11:50:59PM +0200, Stefano Zacchiroli wrote:
> 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.

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".

> 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 ...

Yes, it is.  I don't see why that's so hard for you to believe that you
would find it necessary to call my integrity into question?

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.

> 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).  

No, it's not clear to me.  Why do you think that config.sub should be given
an exception?  If it's because we know that config.sub does not contaminate
the license of the binary packages, then why is my word that this is also
the case for the GFDL docs in my package not sufficient to warrant an
exception for those docs?  Since when is the word of a DD not good enough
for this, absent evidence to the contrary?

> Even though in your case you are probably sure that the GFDL stuff does
> not end up in the binary package, there might be way more complex cases
> (like grepping away lines of GFDL-ed stuff and including it as usage
> messages which then get compiled in an executable). We can't ask FTP
> masters to check build details to check cases like this: once more I see
> the current practice as a reasonable one.

In fact, I'm pretty sure we didn't /ask/ the ftp masters to do even the
checking they're currently doing.  Why are there checks for licensing in
binary NEW at all?  That's a check that should happen in source NEW, and
perhaps as part of archive-wide sweeps; there's no cause for singling out
libraries that are undergoing soname transitions.

It would have been simple enough for Joerg, upon reading my reply, to accept
that the package was properly licensed and approve it for a second upload to
binary NEW.  This was not done.

> The best outcome I can imaging of this discussion is a bug report
> against policy stating more precisely that all files shipped in a source
> package are taken into account by debian/copyright.

As far as I'm concerned, this is backwards.  The ftp team doesn't have the
authority to dictate policy here; they're stewards of the archive, not
autocrats.  When the cited announcement was sent to d-d-a, I understood it
as an enforcement of the existing contents of Policy, not a new policy.

> PS wrt exhaustiveness, the machine-interpretable debian/copyright
>    proposal http://wiki.debian.org/Proposals/CopyrightFormat is way
>    better than the status quo, and I really hope that someone with time
>    and energy take it up again to reach a definitive syntax and
>    semantics for debian/copyright

I'm all in favor of machine-interpretable debian/copyright, but it will be a
long time before that will be a policy violation that should warrant
rejection from the new queue.  Even if machine-interpretable
debian/copyright does become policy in the future, I don't think it would
ever be appropriate to reject packages for not mentioning licenses in
debian/copyright that only apply to the source package and not the binary
packages.  Upstream has already documented the licenses on the source -
debian/copyright's primary objective was always to ensure that this was
documented appropriately for the binaries.

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: