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

Re: debian/copyright format and SPDX



Jeremy Stanley <fungi@yuggoth.org> writes:

> Since Debian's machine-readable format has been around longer than
> either of the newer formats you mentioned, it seems like it would make
> more sense for the tools to incorporate a parser for it rather than
> create needless churn in the package archive just to transform an
> established standard into whatever the format-du-jour happens to be (and
> then halfway through another new format gains popularity, and the
> process starts all over again).

I don't think the file format is the most interesting part of SPDX.  They
don't really have a competing format equivalent to the functionality of
our copyright files (at least that I've seen; I vaguely follow their
lists).  Last time I looked, they were doing a lot with XML, which I don't
think anyone would adopt for new formats these days.  (YAML or TOML or
something like that is now a lot more popular.)  In terms of file formats,
writing a lossy converter from Debian copyright files to whatever format
is of interest for BOMs would probably do most of the job.

The really interesting part of SPDX is the license list and the canonical
name assignment, which is *way* more active and *way* more mature at this
point than the equivalent in Debian.  They have a much larger license
list, which is currently being bolstered by Fedora, and the new licenses
and rules for deduplicating them are reviewed by lawyers as part of their
maintenance process.  Their identifiers are also incerasingly used in
upstream software in SPDX-License-Identifier pseudo-headers.

I have no idea how to do a transition, but I do think Debian would benefit
from adopting the SPDX license identifiers where one exists, and possibly
from joining forces with Fedora to submit and get idenifiers assigned to
the licenses that we see that are not yet registered.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>


Reply to: