Re: DEP-5 meta: New co-driver; current issues
Charles Plessy <plessy@debian.org> writes:
> It is necessary to let people add comments in debian/copyright. Some
> people have asked for free-form comments and I think that it is a valid
> request.
> Enclosing comments in a DEP-5 fields give extra work since for each line
> a space needs to be added, with a dot if the line was empty.
This is true. I think the flipside of this argument, though, is that if
we're going to have an RFC 5322 header (or, equivalently, a Debian control
file) format, it would be nice to be able to point an RFC 5322 or Debian
control file parser at it and have it just work. This doesn't work with
free-form comments.
As Steve pointed out in a separate discussion, the Debian control file
format does support # as a comment character, so we could do free-form
comments that way instead, but after thinking about it for a while, I
don't mind making it a real field.
> As example of free-form comments that do not need a field, there is
> extracts of the correspondance with the authors when some points need to
> be confirmed,
This is a good point.
> and the traditional “On Debian systems, the complete text of the …
> License can be found in /usr/share/common-licenses…”, which can be
> inferred by the parsers themselves.
Oh, hm. I was going to argue that this should be part of the license
text, but that's a very good point. It's actually redundant information
for a Debian-aware parser.
> File format
> -----------
> The “paragraph” format that is popular in Debian control files does not
> allow the use of free comments. Also, in addition to indentation it
> requires empty lines to be represented by a single dot. I can tell you
> by experience that it is unfun and frustrating to go through long texts,
> for instance the Artistic license version 2.0, and add the missing
> dots. Of course there are programmatic ways to solve that, but adding
> requirements like this is adding barriers to the adoption of the format,
> and at the end of the day, the small barriers add up in a quite tall one
> (as you can already read from the other comments on this list).
> I propose to use a simpler format, that is trivial to parse:
I would prefer to stick to a Debian control file format, since otherwise
implementing DEP-5 aware checks in tools like Lintian is going to be more
painful than it needs to be.
> Lastly, there are cases like for the ‘BSD’ that needs to answer to a
> question first: If a work is not copyright of the Regents of the
> University of California, and forbits the use of another names for
> endorsment or promotion, can we call it the “BSD” licenses? My answer to
> this would be no, and it should be clearly written in the DEP. This
> said, we could provide a formalised way to indicate that a license is
> “similar to” the BSD or MIT licenses:
My preference would be for the keywords to indicate a particular class of
licenses, such as all BSD-style licenses with the same number of clauses
and the same provisions but possibly different listed people that you
can't attribute without permission. This would make the keywords much
more useful for automated analysis. However, specifying when you can use
the keyword and when you can't is a bit tricky.
> File globbign syntax
> --------------------
> Here is what I think represents the broader consensus from previous
> discussion:
> * **`Files`**: List of space-separated pathnames indicating files that
> have the same licence. Question marks indicate any character and
> asterisks indicate any string of characters. When this field is omitted
> in the first paragraph containing a `License` field, its value will be
> assumed to be '*'. If multiple `Files` declaratioun match the same
> file, then only the last match counts.
I would prefer to use the same syntax as .gitignore, since it already
deals with all of the complicated cases of matching files in particular
paths versus a file by that name anywhere in the tree and does so in a
well-specified way.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: