[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 04:20:48PM -0700, 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.

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

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

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

Oh come one, I did not "call your integrity into question", I was just
surprised. Maybe it is just unlucky me with has it into similar problems
quite often in the last years, than I found surprising that others
didn't. Nothing more than that.

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

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

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

Regarding config.{sub,guess} I do not agree their special handling is
appropriate, and according to Joerg's mail you forwarded he did not
either. But the reason has been explained: tons of packages insta-buggy,
isn't that part of the usual policy process you want to see applied at
this case?

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.

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

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.

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

Attachment: signature.asc
Description: Digital signature


Reply to: