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

Re: DEP-5: query about possible inheritance of License:



Hi Mike,

On Tue, Sep 15, 2009 at 08:38:58AM +0200, Mike Hommey wrote:
> On Mon, Sep 14, 2009 at 09:18:00PM -0700, Steve Langasek wrote:
> > On Mon, Sep 14, 2009 at 08:40:34AM +0900, Charles Plessy wrote:
> > > Having a mantadory Files: field was strongly opposed on debian-devel

> > AFAIK the opposition was from people who opposed the machine-readable
> > copyright format altogether, not from people who are planning to use the
> > format and are looking to improve it.  The DEP should not cater to the whims
> > of people who aren't going to use it anyway.

> On the other hand, the DEP should make it possible for more people to
> use it, not make it impossible. Basically, having the Files field
> mandatory means no big package will ever use it. Ask Gustavo Noronha how
> fun it is, and how long it takes to update the debian/copyright file for
> webkit at each new upstream release, which is only medium sized. Not
> only is it not fun and time sucking, but it is also very error-prone.
> I'm pretty sure I involuntary introduced errors when I was still
> maintaining that file, which are probably still out there.

This particular subthread is about whether or not the 'Files: *' field
should be mandatory in the first ("default") stanza.  Isn't it obvious that,
*if* you're using multiple stanzas, the *additional* stanzas need Files:
fields?  Else, why would you have multiple stanzas?

> And while software like fossology could help a lot, they still leave a
> massive amount of manual work to be done.

I think much of the criticism of DEP5 is due to a misperception that the
machine-readable format requires maintainers to provide more detail than
they are required to provide today.  There's no reason that this should be
the case.  If you have a package with 800 source files, 30 copyright
holders, and three different (but compatible) licenses, for instance, I
don't see anything wrong with declaring your copyright file like this:

 Files: *
 Copyright: 1999-2005 Person One, 2003-2007 Person Two, [...]
 License: LGPL-2+ and GPL-2+ and BSD-with-cheese

 License: LGPL-2+
  <license text>

 License: GPL-2+
  <license text>

 License: BSD-with-cheese
  <license text>

... unless, that is, you find that listing the licenses in a lump applying
to the package as a whole is inappropriate, perhaps because it's misleading.
But if you hold that opinion (as, judging by many debian/copyright files
I've looked at, a fair number of maintainers do), you have to do more work
to document the copyright/license *anyway*, and use of the machine-readable
structure doesn't significantly impact the work one way or the other; it
just provides a structure you can plug the data into.

Starting to dogfood the DEP on unixodbc, for instance, I went with the
following:

 Files: *
 Copyright: 1999-2005 Nick Gorham <nick@easysoft.com>,
  Peter Harvey <pharvey@codebydesign.com>, et al.
 License: LGPL-2+
 
 Files: exe/*, odbctest/*
 Copyright: 1999-2005 Nick Gorham <nick@easysoft.com>,
  Peter Harvey <pharvey@codebydesign.com>, et al.
 License: GPL-2+
 
 Files: DRVConfig/esoob/esoobS.c
 Copyright: 1999 Easysoft Ltd.
 License: LGPL-2+
 
 Files: Drivers/nn/*
 Copyright: 1995, 1996 Ke Jin <kejin@visigenic.com>
 License: GPL-2+

 License: LGPL-2+
  <blah>

 License: GPL-2+
  <blah>

But if I wanted less detail I could just as easily have compressed this to
two File stanzas (one for all GPL-licensed code, one for all LGPL-licensed
code), or even one with just "License: LGPL-2+ and GPL-2+".  (But not, I
would note, "License: GPL-2+" even though the LGPL would allow this, because
this is a library that we have to link a variety of other code against so
the LGPL permissions are relevant to Debian and should be explicit.)

And as and when tools start to appear that can generate debian/copyright in
this format, we can probably tweak them to optionally spit out the stanzas
in each of these styles.

> Let's also add something I pointed out last time: the debian/copyright
> file is mostly relevant for *binary* packages, yet, we fill copyright
> for *source* files and provide no information for *binary* files at all,
> while having a machine-parseable copyright has, IMHO, a more interesting
> benefit for binaries than it has for sources (especially sources of big
> packages). But I admit gathering these informations together would mean
> even more work than what copyright files require already.

I agree; I would also prefer being able to track copyright on a
per-binary-package basis.  I think that's out of scope for DEP5, however.

If I were trying to solve this on my own packages, I would probably go with
separate debian/<pkg>.copyright files for each binary which I update by
hand, plus logic to regenerate debian/copyright in the clean target.  Hmm,
but a tool that can look at the make rules for a given binary output,
identify its dependencies, gather copyright information for those files and
output it in a machine-readable copyright format would be interesting to
see. :)

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

Attachment: signature.asc
Description: Digital signature


Reply to: