FYI, I started working on a SPDX->DEP5 and DEP5->SPDX converter tool,
the code (or rather a basic concept) is here [1].
My goal is to produce an internal representation that collects
copyright information on a per-file basis, and convert between
SPDX/DEP5 and this format.
Regards,
Stephan
[1] ht
Quoting Stephan Lachnit (2022-02-10 11:59:11)
> On Tue, Feb 8, 2022 at 8:36 PM Jonas Smedegaard
> wrote:
> >
> > For starters, the format adds one SHA1 hash per source file, right?
>
> Yes, one checksum per file.
>
> > Sure I can "just" ignore all FileChecksum: lines, but anyone working
> > wi
On Tue, Feb 8, 2022 at 8:45 PM Russ Allbery wrote:
>
> I recommend thinking about how to generate an existing debian/copyright
> file and putting the SPDX-formatted one in a different location. You're
> going to want to decouple the new work from any transition that requires
> other people change
Russ Allbery writes:
> I can tell you from prior experience with DEP-5 that 3 is wildly
> controversial and will produce the most pushback. There are a lot of
> packagers who flatly refuse to even use the DEP-5 format, and (pace
> Jonas's aspirations) I don't expect that to change any time soon.
Stephan Lachnit writes:
> It would require a minor change: putting the verbatim license texts in a
> single file is not possible anymore. But I don't why just copying the
> licenses to "/usr/share/doc/PACKAGE/licenses/LICENSE" in addition to the
> SPDX formatted debian/copyright would be any wors
On Tuesday, February 8, 2022 2:38:29 PM EST Russ Allbery wrote:
> Scott Kitterman writes:
> > Technically it would be the simplest, but there's a process for policy
> > changes that's more involved than writing emails to d-devel. I'm
> > suggesting you engage with it on this topic if you want the
Scott Kitterman writes:
> Technically it would be the simplest, but there's a process for policy
> changes that's more involved than writing emails to d-devel. I'm
> suggesting you engage with it on this topic if you want the results of
> your work to be usable in Debian.
Speaking as a Policy E
Hi Stephan,
Quoting Stephan Lachnit (2022-02-08 18:53:22)
> On Tue, Feb 8, 2022 at 4:39 PM Jonas Smedegaard
> wrote:
> >
> > I am sceptical towards this proposal.
> >
> > An important feature to me with current machine-readable format is
> > that really it is machine-and-human-readable.
>
> Th
Technically it would be the simplest, but there's a process for policy changes
that's more involved than writing emails to d-devel. I'm suggesting you
engage with it on this topic if you want the results of your work to be usable
in Debian.
Scott K
On Tuesday, February 8, 2022 1:27:19 PM EST
The easy solution would just be allow both. Either only a single file with
verbatim text or an SPDX document with licenses in a separate folder.
Regards,
Stephan
On Tue, 8 Feb 2022, 19:12 Scott Kitterman, wrote:
> On Tuesday, February 8, 2022 12:53:22 PM EST Stephan Lachnit wrote:
> > On Tue, F
On Tuesday, February 8, 2022 12:53:22 PM EST Stephan Lachnit wrote:
> On Tue, Feb 8, 2022 at 5:00 PM Scott Kitterman wrote:
> > Since Debian policy requires verbatim copies of licenses (or links to
> > /usr/
> > share/common-licenses), I think any policy compliant debian/copyright will
> > have to
Hi Jonas,
On Tue, Feb 8, 2022 at 4:39 PM Jonas Smedegaard wrote:
>
> I am sceptical towards this proposal.
>
> An important feature to me with current machine-readable format is that
> really it is machine-and-human-readable.
Thank you for your input! I'm aware of this concern, however I think
i
On Tuesday, February 8, 2022 10:39:36 AM EST Jonas Smedegaard wrote:
> Quoting Stephan Lachnit (2022-01-26 12:49:34)
>
> > - What is an SPDX bill of materials?
> > It is a machine-readable format that specifies the licenses of each
> > file in tag/value style like DEP-5. However compared to DEP-5
Quoting Stephan Lachnit (2022-01-26 12:49:34)
> - What is an SPDX bill of materials?
> It is a machine-readable format that specifies the licenses of each
> file in tag/value style like DEP-5. However compared to DEP-5 it is
> much less human readable, i.e. it includes much more meta information,
>
On Fri, Jan 28, 2022 at 9:42 AM Phil Morrell wrote:
>
> On Thu, Jan 27, 2022 at 11:27:45AM +0100, Stephan Lachnit wrote:
> > On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote:
> > >
> > > TLDR: I think REUSE.software is a bad idea that is worse than what
> > > Debian already invented with Machi
On Thu, Jan 27, 2022 at 11:27:45AM +0100, Stephan Lachnit wrote:
> On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote:
> >
> > TLDR: I think REUSE.software is a bad idea that is worse than what
> > Debian already invented with Machine-readable debian/copyright file. I
> > guess if upstream uses i
On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote:
>
> TLDR: I think REUSE.software is a bad idea that is worse than what
> Debian already invented with Machine-readable debian/copyright file. I
> guess if upstream uses it, there's no reason not to ignore that as a
> source of copyright assertio
Russ Allbery left as an exercise for the reader:
> My intuition (I admit that I haven't done a survey) is that Files-Excluded
> is less frequently used for cases where upstream has not done license
> verification and is more frequently used for cases where upstream
> disagrees with Debian over what
Phil Morrell writes:
> The point about uscan is interesting, since if upstream does take on the
> hard work of license verification such that packaging is just checking,
> then they're unlikely to have any Files-Excluded, so that would have to
> merged somehow.
My intuition (I admit that I haven
https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code
TLDR: I think REUSE.software is a bad idea that is worse than what
Debian already invented with Machine-readable debian/copyright file. I
guess if upstream uses it, there's no reason not to ignore that as a
~ Stephan Lachnit [2022-01-26 15:20 +0100]:
>> But already now, a DEP-5 file could be provided to REUSE. One would have
>> to check whether the ones Debian provides would work in the default
>> location for DEP-5 files in REUSE (`.reuse/dep5`). If not, I suspect
>> there would be no large changes n
On Wed, Jan 26, 2022 at 1:59 PM Max Mehl wrote:
>
> FWIW, as you may have already noticed, REUSE makes use of DEP-5 as well,
> as one (and honestly the least preferred) of the three ways how you can
> label your files. We have a better file-based format in the works [^3],
> and would probably also
Thank you Stephan for bringing REUSE into the discussion and Cc'ing me
(I am not part of this list). Please let me just add two small things to
your otherwise encompassing mail.
~ Stephan Lachnit [2022-01-26 12:49 +0100]:
> - What is REUSE?
If you have ~15min of time and rather fancy video intros
Since I feel this fits to the current discussion on the mailing list,
let me quickly introduce you to an idea I had for a while to improve
the copyright review situation.
TLDR: for projects using REUSE, we could generate d/copyright
automatically and approve the copyright check in NEW automatically
24 matches
Mail list logo