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

Re: DEP-5: additional requirements to use with upstream

On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote:
> As mentioned in the other thread, one goal for DEP-5 for me is to make the
> format sufficiently rich to allow me to use it for the upstream LICENSE
> file.  Towards that end, I have three changes I'd like to have.

Thanks, that's an interesting use case for the file format, and I'm glad
you brought it up.

> * An additional section with the same syntax as the Files section but with
>   no Files field that would be used for documenting the copyright of the
>   distribution as a whole.  (In US law, this is called a compilation
>   copyright.)  This is not the same thing as a Files: * section, which
>   would specify a default copyright and license for any individual file
>   that doesn't have other information.  In some edge cases, the
>   compilation copyright and license can be different than the copyright
>   and license of any individual file in the distribution.

I am uncomfortable signalling compilation copyright just with the
absence of a Files: field. It seems to error prone to me. It would be
better to be explicit, I think. What would be a good way of being
explicit in this case?

> * A comment field in the header section into which I can put statements
>   like:
>     All individual files with no other license statement are released
>     under this license.  Some files have additional copyright dates from
>     earlier releases or may be owned by other copyright holders as noted
>     in those files.  Some files are individually released under different
>     licenses, all of which are compatible with the above general package
>     license.

Would a generic multi-line Comment: field be sufficient?

> * An origin field in the files section where I can note the origin of that
>   set of files.  For example, my packages contain some files copied from
>   GNU Libtool, and I currently say that in the LICENSE file.  I don't want
>   to lose that information.  This use case could be served by just
>   allowing a comment field in the files section, I suppose, and that may
>   be a better approach since it's more general.

Perhaps it'd be sufficient to stick to a generic Comment: field for now,
until there's some experience to see what other new fields are useful in
the real world. This would be my personal preference.

If others think an Origin: field would be good to have, I'll add it, my
job as DEP driver is to record consensus. Can you suggest a wording?
What do others think? Anyone for or against and Origin: field?

Reply to: