Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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] https://github.com/stephanlachnit/dep5convert

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Jonas Smedegaard]

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 
> > with XML will know that plaintext does not equal human-readable.
> 
> This comparison is a bit off, XML is a representation. The SPDX format 
> I want to use is tag:value just like DEP5, so in this regard 
> "human-readable". There is more cruft content, but it takes less than 
> 5 minutes to understand where the per file copyright and license 
> information is.

It takes less than 5 minutes to understand where the per file copyright 
and license information is: "Just" ignore all angle-bracket markup.

Comparison is that both XML and checksums adds noise, reducing 
readability.

...and seems you agree:

> Yes I agree that adding hashes to DEP5 makes it unreadable and utterly 
> annoying to maintain, that's why I don't want to add it. DEP5 is 
> designed to be written by humans, SPDX is not. That's why SPDX can add 
> hashes without any drawbacks.

A file containing checksums for all files is much harder not only to 
write but also to read, than one without such hashes.

[ original criticism revived ]

Quoting Jonas Smedegaard (2022-02-08 16:39:36)
> If we permit a debian/copyright format that is not human-readable, it 
> means that I cannot confidently proof-read and change the contents of 
> the debian subdir without the help of machine-parsers, and I would 
> need to know two formats with different goals.

> > > I don't see the problem with machine parsers. We already use a lot 
> > > of different tools for our processes (git, dput, dpkg, debhelper, 
> > > lintian, uscan, a mail program, a text editor, ...), adding one 
> > > more shouldn't be a big deal. It needs to be provided of course, 
> > > but I plan to do that.
> >
> > Only 2 of those you list are mandatory: dpkg and RFC822 email - the 
> > rest are optional, some quite popular but even then routinely 
> > bypassed.
> 
> I mean if you want you can write SPDX files by hand, it's not a binary 
> format. Same as you can write a Debian package without debhelper.

I can also transfer TCP packets using pigeons, if I seek challenges.

My concern is not about binary versus text-based format, but about 
only-machine-readable versus human-and-machine-readable format.


> > I would be quite happy if our work on evolving debian/copyright would
> > result in a future revision being identical to REUSE format.
> >
> > What I dislike is requiring all developers to master 3 formats instead
> > of currently only two: freeform-human-only and (also-)machine-readable.
> 
> No, you don't have to master SPDX! That's the point: you don't
> interact with it at all. It's created by tools, and shipped to satisfy
> the legal obligation to provide copyright information. Users don't
> care how the copyright information is shipped. As a developer, you
> just have one less thing to care about, namely writing
> debian/copyright by hand.

I need to either interact with the format or depend on tools that do.

When I release a package to Debian, then I am responsible for that 
package being in compliance with Debian Policy - including § 2.3 about 
information that the debian/copyright file MUST cover.

It does not matter if I write debian/copyright by hand or choose to use 
automated tools to autogenerate that file - regardless it is my 
responsibility to ensure that contents or that file comply with Debian 
Policy.

If I upgrade a package as an NMU, then it is my responsibility to ensure 
that the new package comply with Debian Policy - including 
debian/copyright getting updated as needed - but if debian/copyright 
format is alien to me then I cannot do that responsibly.

Your argument seems to be that I can simply trust SPDX/REUSE tools.  
Agreed, I can choose to trust tools doing magic for me, but that is 
exactly my concern: I am _forced_ to trust tools, where I have the 
(easy!) option of by-passing helper tools with current 
[also-]machine-readable format.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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 tools.  There are a lot of tools that make assumptions
> about debian/copyright, and trying to track them all down will be
> counterproductive for trying to make forward progress on exposing
> information in a more interoperable format.
>
> The way I see this, there are three different things that have been
> discussed on this thread:
>
> 1. Consuming upstream data in SPDX or REUSE format and automating the
>generation of required Debian files using it.
>
> 2. Exposing SPDX data for our packages for downstream consumption.
>
> 3. Aligning the standard way to present Debian copyright information with
>other standards.
>
> 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.
>
> I think that's fine for what you're trying to accomplish, because I think
> 1 and 2 are where the biggest improvements can be found.  As long as your
> system for managing copyright and license information can spit out a DEP-5
> debian/copyright file (in its current or a minorly modified format, not
> with new files elsewhere that would have to be extracted from the
> package), you are then backward-compatible with the existing system and
> that takes 3 largely off the table (which is what you want).  Then you can
> demonstrate the advantages of the new system and people can choose to be
> convinced by those advantages or not, similar to DEP-5, and we can reach
> an organic consensus without anyone feeling like they're forced to change
> how they do things.

Thanks for this input, Russ! I think you're right: it will be easier
to output the DEP5 format in addition to SPDX at the beginning, and
see from there how it works. I would install the source SPDX document
then to /usr/share/doc/PACKAGE/copyright_spdx in addition to the DEP5
file in the usual place.

I will write a SPDX -> DEP5 tool for this, which should be "fairly
trivial". Regarding concerns about the different file formats SPDX can
come in: for us only the tag:value format makes sense, I don't want to
support other formats.

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
> with XML will know that plaintext does not equal human-readable.

This comparison is a bit off, XML is a representation. The SPDX format
I want to use is tag:value just like DEP5, so in this regard
"human-readable". There is more cruft content, but it takes less than
5 minutes to understand where the per file copyright and license
information is.

> > However, I also think the human-readable aspect is less important here
> > because it is an output format. What I mean with this is that the
> > information is already there in a human readable way: either via REUSE
> > or in the file headers directly. While it is theoretically possible to
> > write SPDX documents by hand, I would not treat them with the same
> > trust as one created by REUSE.
>
> Here you seem to assume that humans need not be involved in authoring
> the contents or at least that human-facing interfaces for smart tools
> exist and is expressive enough to cover all that is needed.
>
> That is quite an assumption, I dare say.

I think this is a misconception: I don't want people to write SPDX
documents by hand at all. IMHO for this scenario, DEP5 is still
superior (that's e.g. why REUSE can also use DEP5).

> Writing the debian/copyright file for ghostscript took quite some time.
> Singularity is imminent, I know, and I wouldn't mind machines taking
> over the task of classifying tights statements, when they are up to the
> task - but until then I will want to proof-read and intervene as needed.
> My own experience is that they are not yet there - you seem to claim
> they have already surpassed humans for this task...
>
> Can you show me (off list if too long for an attachment) how your new
> not-really-needing-manual-editing file for ghostscript looks like, so I
> can compare with my lesser trusted human-laboured product?

No, because if ghostscript doesn't have the information to
automatically generate a SPDX document, don't do it by hand, use DEP5
instead.

What you can do is to put your DEP5 in .reuse/dep5 in the top-level
dir and run "reuse spdx" if you want to see how it looks.

> > Regarding reviews: I plan to write a SPDX-to-DEP5 converter anyway to
> > get a better feel for the spec. I will probably also write a copyright
> > review 

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Russ Allbery]

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.

That last parenthetical was in retrospect probably not very clear,
particularly to people who aren't familiar with that specific English
idiom.  For the record, this is "pace" in the sense of:

https://www.merriam-webster.com/word-of-the-day/pace-2017-09-28

What I meant to express is that I realize that Jonas is actively working
on this and is hopeful, and I would love for him to be successful, but I
am more pessimistic.  But I wanted to acknowledge that he disagrees and I
may well be wrong.

-- 
Russ Allbery (r...@debian.org)  

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Russ Allbery]

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 worse than the current way.

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 tools.  There are a lot of tools that make assumptions
about debian/copyright, and trying to track them all down will be
counterproductive for trying to make forward progress on exposing
information in a more interoperable format.

The way I see this, there are three different things that have been
discussed on this thread:

1. Consuming upstream data in SPDX or REUSE format and automating the
   generation of required Debian files using it.

2. Exposing SPDX data for our packages for downstream consumption.

3. Aligning the standard way to present Debian copyright information with
   other standards.

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.

I think that's fine for what you're trying to accomplish, because I think
1 and 2 are where the biggest improvements can be found.  As long as your
system for managing copyright and license information can spit out a DEP-5
debian/copyright file (in its current or a minorly modified format, not
with new files elsewhere that would have to be extracted from the
package), you are then backward-compatible with the existing system and
that takes 3 largely off the table (which is what you want).  Then you can
demonstrate the advantages of the new system and people can choose to be
convinced by those advantages or not, similar to DEP-5, and we can reach
an organic consensus without anyone feeling like they're forced to change
how they do things.

-- 
Russ Allbery (r...@debian.org)  

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Scott Kitterman]

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 results of
> > your work to be usable in Debian.
> 
> Speaking as a Policy Editor, the way that Stephan is engaging with this
> process is fine.  We're in the early stages of discussion and
> understanding the shape of the problem.  Writing emails ot debian-devel,
> and writing a DEP, are exactly the right way to engage with Policy on this
> topic right now.

Thanks.  I haven't tried to do it myself before and didn't know.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Russ Allbery]

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 Editor, the way that Stephan is engaging with this
process is fine.  We're in the early stages of discussion and
understanding the shape of the problem.  Writing emails ot debian-devel,
and writing a DEP, are exactly the right way to engage with Policy on this
topic right now.

-- 
Russ Allbery (r...@debian.org)  

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Jonas Smedegaard]

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.
> 
> Thank you for your input! I'm aware of this concern, however I think
> it is not something that can't be solved.
> 
> For one, while not as trivial to under as the current machine-readable 
> copyright, it's still "human-readable" (i.e. a tag:value style text 
> file). I would do the following comparison: if you only know Python 
> (DEP-5), C++ (SPDX) might look a bit weird, but you can get the gist 
> of it.

For starters, the format adds one SHA1 hash per source file, right?

Sure I can "just" ignore all FileChecksum: lines, but anyone working 
with XML will know that plaintext does not equal human-readable.


> However, I also think the human-readable aspect is less important here 
> because it is an output format. What I mean with this is that the 
> information is already there in a human readable way: either via REUSE 
> or in the file headers directly. While it is theoretically possible to 
> write SPDX documents by hand, I would not treat them with the same 
> trust as one created by REUSE.

Here you seem to assume that humans need not be involved in authoring 
the contents or at least that human-facing interfaces for smart tools 
exist and is expressive enough to cover all that is needed.

That is quite an assumption, I dare say.

Writing the debian/copyright file for ghostscript took quite some time.  
Singularity is imminent, I know, and I wouldn't mind machines taking 
over the task of classifying tights statements, when they are up to the 
task - but until then I will want to proof-read and intervene as needed.  
My own experience is that they are not yet there - you seem to claim 
they have already surpassed humans for this task...

Can you show me (off list if too long for an attachment) how your new 
not-really-needing-manual-editing file for ghostscript looks like, so I 
can compare with my lesser trusted human-laboured product?


> > Another important feature to me is that there is only one format (in 
> > addition to unformatted content, which hopefully we can put past us 
> > at some point).
> >
> > Today, I can as DD help proof-read and change *any* package in 
> > Debian.
> 
> Regarding reviews: I plan to write a SPDX-to-DEP5 converter anyway to 
> get a better feel for the spec. I will probably also write a copyright 
> review tool that will show you the copyright header of each file based 
> on DEP5 or SPDX information for validation / manual review. This will 
> make proof-reading copyright information much easier.

Seems to are now talking not about a format, but a detection mechanism.


> But to stress this again: the goal is to *replace* the manual 
> copyright reviews by something much better: automatic copyright 
> reviews.

Great.  But orthogonal to switching format: detection tools can 
serialize their findings in current machine-readable format.  Either by 
themselves, or for tools that can only output REUSE format *AND* if that 
output fully covers Debian needs, then othr tools can reformat that to 
current format.

My point here is not that there is no benefit in using REUSE.  My point 
is that detecting rights information is orthogonal to serializing it.


> There are three areas of interest for copyright information:
> a) for developers writing it b) for the user receiving it and c) the
> legal side.
> 
> Regarding a: From hand DEP5 is better, but for automation SPDX is equally 
> good.
> Regarding b: I think they don't care anyway. Like which user reads the
> debian/copyright really? If at all, you are interested in the
> copyright of a certain library you wish to use, but this doesn't
> require the extensive file-by-file information of DEP5. Most likely
> the documentation provides much clearer information.
> Regarding c: SPDX is as good as DEP5 if not even better due to file hashes.

So new format is at best "equally good" as current format, except that 
outperforms current format by adding file hashes.

That is probably a simplification. Ok, let's then use it as an example:

You can add file hashes to debian/copyright files *today* - the standard 
permits unofficial fields, and we could then elevate certain fileds to 
make them official in a later revision of the current format.

Adding hashes would clutter the files, making them less readable, but in 
your argument that's a feature with no real drawback, so let's play 
along for now.

Any feature improvements that cannot be an evolution of current format?


> > If we permit a debian/copyright format that is not human-readable, 
> > it means that I cannot confidently proof-read and change the 
> > contents of the debian subdir without the help of machine-parsers, 
> > and I would need to know two formats with different 

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Scott Kitterman]

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 Stephan Lachnit wrote:
> 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, 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 be human readable, but I'm not that familiar with SPDX, so
> > 
> > maybe
> > 
> > > > it
> > > > will surprise me.
> > > 
> > > You can find an example in my initial mail [1].
> > > 
> > > > I would be good to understand how this proposal supports Debian
> > > > Policy.
> > > 
> > > 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 worse than the
> > > current way.
> > > 
> > > 
> > > Regards,
> > > Stephan
> > > 
> > > [1] https://lists.debian.org/debian-devel/2022/01/msg00309.html
> > 
> > Personally, I don't view that as a minor change.
> > 
> > I think before starting a DEP on this you ought to work out the policy
> > implications.  Currently any package using your proposed approach would be
> > instantly RC buggy.
> > 
> > Scott K



signature.asc
Description: This is a digitally signed message part.

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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, 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 be human readable, but I'm not that familiar with SPDX, so
> maybe
> > > it
> > > will surprise me.
> >
> > You can find an example in my initial mail [1].
> >
> > > I would be good to understand how this proposal supports Debian Policy.
> >
> > 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 worse than the
> > current way.
> >
> >
> > Regards,
> > Stephan
> >
> > [1] https://lists.debian.org/debian-devel/2022/01/msg00309.html
>
> Personally, I don't view that as a minor change.
>
> I think before starting a DEP on this you ought to work out the policy
> implications.  Currently any package using your proposed approach would be
> instantly RC buggy.
>
> Scott K

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Scott Kitterman]

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 be human readable, but I'm not that familiar with SPDX, so maybe
> > it
> > will surprise me.
> 
> You can find an example in my initial mail [1].
> 
> > I would be good to understand how this proposal supports Debian Policy.
> 
> 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 worse than the
> current way.
> 
> 
> Regards,
> Stephan
> 
> [1] https://lists.debian.org/debian-devel/2022/01/msg00309.html

Personally, I don't view that as a minor change. 

I think before starting a DEP on this you ought to work out the policy 
implications.  Currently any package using your proposed approach would be 
instantly RC buggy.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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
it is not something that can't be solved.

For one, while not as trivial to under as the current machine-readable
copyright, it's still "human-readable" (i.e. a tag:value style text
file). I would do the following comparison: if you only know Python
(DEP-5), C++ (SPDX) might look a bit weird, but you can get the gist
of it.

However, I also think the human-readable aspect is less important here
because it is an output format. What I mean with this is that the
information is already there in a human readable way: either via REUSE
or in the file headers directly. While it is theoretically possible to
write SPDX documents by hand, I would not treat them with the same
trust as one created by REUSE.

> Another important feature to me is that there is only one format (in
> addition to unformatted content, which hopefully we can put past us at
> some point).
>
> Today, I can as DD help proof-read and change *any* package in Debian.

Regarding reviews: I plan to write a SPDX-to-DEP5 converter anyway to
get a better feel for the spec. I will probably also write a copyright
review tool that will show you the copyright header of each file based
on DEP5 or SPDX information for validation / manual review. This will
make proof-reading copyright information much easier.

But to stress this again: the goal is to *replace* the manual
copyright reviews by something much better: automatic copyright
reviews. There are three areas of interest for copyright information:
a) for developers writing it b) for the user receiving it and c) the
legal side.

Regarding a: From hand DEP5 is better, but for automation SPDX is equally good.
Regarding b: I think they don't care anyway. Like which user reads the
debian/copyright really? If at all, you are interested in the
copyright of a certain library you wish to use, but this doesn't
require the extensive file-by-file information of DEP5. Most likely
the documentation provides much clearer information.
Regarding c: SPDX is as good as DEP5 if not even better due to file hashes.

> If we permit a debian/copyright format that is not human-readable, it
> means that I cannot confidently proof-read and change the contents of
> the debian subdir without the help of machine-parsers, and I would need
> to know two formats with different goals.>

I don't see the problem with machine parsers. We already use a lot of
different tools for our processes (git, dput, dpkg, debhelper,
lintian, uscan, a mail program, a text editor, ...), adding one more
shouldn't be a big deal. It needs to be provided of course, but I plan
to do that.

> I would like to instead welcome the REUSE developers in helping Debian
> evolve next version of the existing machine-readable format to better
> align with SPDX.

While this would be nice, I think this is just unrealistic. While I
may implement DEP5 output to REUSE, I still want to use SPDX because
it is already an existing industry standard having all the "features"
we want. Adding things like file hashes and referencing / merging
other DEP5 documents is certainly possible, it would make the format
less readable and in the end just SPDX looking differently.


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 be human readable, but I'm not that familiar with SPDX, so maybe it
> will surprise me.

You can find an example in my initial mail [1].

> I would be good to understand how this proposal supports Debian Policy.

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 worse than the
current way.


Regards,
Stephan

[1] https://lists.debian.org/debian-devel/2022/01/msg00309.html

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Scott Kitterman]

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 it is
> > much less human readable, i.e. it includes much more meta information,
> > and does not contain the license texts.
> > 
> > - What has this to do with Debian?
> > My idea is to allow SPDX documents in addition to DEP-5. The advantage
> > is that - if supported upstream - REUSE can generate such reports
> > automatically during package build time, so there is no need to write
> > d/copyright manually anymore.
> 
> 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.
> 
> Another important feature to me is that there is only one format (in
> addition to unformatted content, which hopefully we can put past us at
> some point).
> 
> Today, I can as DD help proof-read and change *any* package in Debian.
> 
> If we permit a debian/copyright format that is not human-readable, it
> means that I cannot confidently proof-read and change the contents of
> the debian subdir without the help of machine-parsers, and I would need
> to know two formats with different goals.
> 
> I would like to instead welcome the REUSE developers in helping Debian
> evolve next version of the existing machine-readable format to better
> align with SPDX.

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 be human readable, but I'm not that familiar with SPDX, so maybe it 
will surprise me.

I would be good to understand how this proposal supports Debian Policy.

Scott K


signature.asc
Description: This is a digitally signed message part.

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Jonas Smedegaard]

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,
> and does not contain the license texts.
>
> - What has this to do with Debian?
> My idea is to allow SPDX documents in addition to DEP-5. The advantage
> is that - if supported upstream - REUSE can generate such reports
> automatically during package build time, so there is no need to write
> d/copyright manually anymore.

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.

Another important feature to me is that there is only one format (in 
addition to unformatted content, which hopefully we can put past us at 
some point).

Today, I can as DD help proof-read and change *any* package in Debian.

If we permit a debian/copyright format that is not human-readable, it 
means that I cannot confidently proof-read and change the contents of 
the debian subdir without the help of machine-parsers, and I would need 
to know two formats with different goals.

I would like to instead welcome the REUSE developers in helping Debian 
evolve next version of the existing machine-readable format to better 
align with SPDX.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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 Machine-readable debian/copyright file. I
> > > guess if upstream uses it, there's no reason not to ignore that as a
> > > source of copyright assertions.
> >
> > I expected some concerns about the complexity of the SPDX document,
> > but certainly not about standardized copyright information in source
> > files.
> >
> > Yes, Debian may have invented the machine-readable copyright bill, but
> > not machine-readable copyright information in source files.
>
> Erm, no that's not what I'm saying? I'll requote my agreement with
>
> > > I *am* a big fan of SPDX-License-Identifier

Yes I saw that line, but you also wrote
> TLDR: I think REUSE.software is a bad idea

I apologize  for the misunderstanding. Maybe next time write something
like "While I am a big fan of copyright information in source files, I
find certain aspects of REUSE bad".
Because there may be valid concerns about the spec, however this is
not really relevant for my proposal: It's mainly about allowing a
different copyright format than [DEP-5 style], which _can_ be created
automatically via REUSE.

> I will admit I'm somewhat skeptical in how often file-level copies
> happen these days, rather than folder-level or whole project forks. But
> it's easy enough to convince people to slap a single-line license
> comment in to avoid ambiguity.

Obviously we as Debian are not a big fan of file-level copies anyways,
but let's just say that REUSE wasn't written just for Debian. There
are enough industry projects that use tons of imported code whether we
like it or not, but it's certainly better with standardized copyright
information than without.

> > what REUSE is all about, and it greatly reduces manual labor - I don't
> > understand how this can be seen as bad.
>
> Because being REUSE-compliant IMO greatly *increases* manual labor as
> soon as you're dealing with non-text forms, multiple authors and
> aggregation of differing copyright assertions. These are all things that
> the debian copyright-format has already solved without (as much) manual
> busywork, so if upstream is agreeable to formally documenting their
> copyrights, I'd much rather they just used that format in LICENSE.

But it does not increase the manual labor for us! It actually
decreases our work, that's what this is all about!

The main point of my proposal: we, as package maintainers, don't have
to do the bulk work anymore, upstream does it. We can just use this
information which we would have done by hand otherwise. This is not
about pushing REUSE to upstream projects from our side at all, but
rather using it downstream to decrease manual labor if it already
exists upstream.

> > Yes it is called "Machine-readable debian/copyright file Version 1.0",
> > but everybody knows it _is_ DEP-5, it is even in the spec in the
> > second sentence of the abstract.
>
> Sure, and that's fine as a colloquialism, but you haven't addressed my
> objection to REUSE formalising that as part of the spec.

If you look at [1]:
> Definitions
> [...]
> DEP5 — Machine-readable debian/copyright file, Version 1.0. Where the REUSE 
> Specification and DEP5 state different things, the REUSE Specification takes 
> precedence. Specifically in the case of the Copyright and License tags.

And they link to the proper spec, so it is nothing but an abbreviation.

> > The spec _is_ still DEP-5, being accepted doesn't change that.
>
> Sure it does, compare `#files-field` in both specs, from 2019 policy
> upgrading checklist 4.4.1. Perhaps that change should have bumped a
> version number, but it's a bit late now.

Oh, thanks, I didn't know that!

> That has not been my experience for projects without a long history,
> they tend to not care about copyright initially, slap a generic
> assertion on it at some point, but without noticing they've included
> e.g. an embedded copy of zlib or less formally - used an image with a
> vague gratis use but omitting a formal license.
>
> It's only either later, or from the ITP scrutiny that some confusion
> over pedigree comes to light, someone fires off an email to an early
> contributor and gets the accurate license information. Or for Debian,
> the path gets added to Files-Excluded and patched out of compilation.

Yes, surely copyright assertion mistakes happen from time to time. But
these can happen everywhere, whether they slap a generic assertion on
it or not. Just using the information REUSE provides doesn't mean that
the code is free from any review, just from the tedious copyright
review. If one detects an embedded copy of zlib, or really any other
embedded code, this needs to be addressed anyway. Detecting these has
nothing to do with any automated copyright review tools, but rather 

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Phil Morrell]

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 it, there's no reason not to ignore that as a
> > source of copyright assertions.
> 
> I expected some concerns about the complexity of the SPDX document,
> but certainly not about standardized copyright information in source
> files.
>
> Yes, Debian may have invented the machine-readable copyright bill, but
> not machine-readable copyright information in source files.

Erm, no that's not what I'm saying? I'll requote my agreement with 

> > I *am* a big fan of SPDX-License-Identifier

I will admit I'm somewhat skeptical in how often file-level copies
happen these days, rather than folder-level or whole project forks. But
it's easy enough to convince people to slap a single-line license
comment in to avoid ambiguity.

> what REUSE is all about, and it greatly reduces manual labor - I don't
> understand how this can be seen as bad.

Because being REUSE-compliant IMO greatly *increases* manual labor as
soon as you're dealing with non-text forms, multiple authors and
aggregation of differing copyright assertions. These are all things that
the debian copyright-format has already solved without (as much) manual
busywork, so if upstream is agreeable to formally documenting their
copyrights, I'd much rather they just used that format in LICENSE.

> > Firstly, I didn't think it was called DEP-5 anymore - it was accepted
> > into policy in 2012 as "copyright-format" titled "Machine-readable
> > debian/copyright file", so no longer a proposal for enhancement. This
> > would be a minor pedantic point (a colloquialism) except for the fact
> > that REUSE encourages it as part of their interface: `.reuse/dep5`.
> 
> Yes it is called "Machine-readable debian/copyright file Version 1.0",
> but everybody knows it _is_ DEP-5, it is even in the spec in the
> second sentence of the abstract.

Sure, and that's fine as a colloquialism, but you haven't addressed my
objection to REUSE formalising that as part of the spec.

> The spec _is_ still DEP-5, being accepted doesn't change that.

Sure it does, compare `#files-field` in both specs, from 2019 policy
upgrading checklist 4.4.1. Perhaps that change should have bumped a
version number, but it's a bit late now.

> > I think this undermines your previous point about it being less prone to
> > failure - if we could trust upstream assertions on copyright, the NEW
> > review wouldn't be a problem in the first place.
> 
> I strongly disagree. First of all, upstream knows way better where
> they copy the code from than packagers do.
> ...
> And as a second point, if you write a debian/copyright, you are most
> likely to trust what is in the header, and I suspect the copyright
> review in NEW is not different from this regard. I mean how can one
> even know if the copyright information is wrong?
> Yes there are cases where copyright information is missing and one can
> try to search it, I've done this not just once, but if a project uses
> REUSE headers, this doesn't happen.

That has not been my experience for projects without a long history,
they tend to not care about copyright initially, slap a generic
assertion on it at some point, but without noticing they've included
e.g. an embedded copy of zlib or less formally - used an image with a
vague gratis use but omitting a formal license.

It's only either later, or from the ITP scrutiny that some confusion
over pedigree comes to light, someone fires off an email to an early
contributor and gets the accurate license information. Or for Debian,
the path gets added to Files-Excluded and patched out of compilation.

> And projects that use REUSE
> are more likely to write that somewhere down as your average NPM
> package that puts a "under MIT license" in the readme and copies
> minified code from everywhere.

Sure, but instead of wasting my time encouraging upstream to become
REUSE-compliant, I would much rather promote a better standard like
Debian's. I was curious and found approximately 40 instances of REUSE in
codesearch, but multiple thousands of the (optional) copyright-format.


signature.asc
Description: PGP signature

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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

I expected some concerns about the complexity of the SPDX document,
but certainly not about standardized copyright information in source
files.

Yes, Debian may have invented the machine-readable copyright bill, but
not machine-readable copyright information in source files. This is
what REUSE is all about, and it greatly reduces manual labor - I don't
understand how this can be seen as bad.

On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell  wrote:
>
> I *am* a big fan of SPDX-License-Identifier, but the above being
> straightforward is only true for the most trivial of examples. REUSE
> advocate for sprinkling .license files around your repo for e.g. logos
> and other binaries. Same story with multiple authors, they recommend
> using multiple FileCopyrightText's initially, then split it out to a
> separate AUTHORS file and use something like "Project X contributors".

No, it does not only work for trivial examples. Take any project with
a significant amount of code, e.g. [1], and most of the time you will
find that every source file has the copyright information in the
header. The problem is, there has been no standardized way to parse
them. That's why we have tools like licensecheck that try to find it
out. With REUSE, it gets much much easier.

Wrt to the .license files: yes they're ugly, but still better than no
automation at all. With the new yaml spec, I suspect that these will
go away.
Wrt to multiple authors: this is not the fault of REUSE, but just how
copyright works.

> Ultimately, when everything becomes too much, REUSE falls back to
> recommending Debian's copyright format anyway! So even if upstream sees
> the value in taking some copyright busywork off our hands, why not
> suggest they just use it in the first place in e.g. the LICENSE file.

Sight, yes, because Debian's format is afaik the only standardized,
easy to parse format out there. But the reason why it is there is
*not* for "when everything becomes", but for files that you cannot and
don't want to alter. For example, if you regularly import 3rd-party
code that does not follow REUSE and you don't want to edit the header
all the time. Note that if everyone would use REUSE, that would not be
a problem. Another example is when you have tiny example code or
configs that you want to present to a user, but without any
distracting comments (think beginner tutorials).

However, they want to switch from DEP-5 to a more flexible (i.e.
non-central, relocatable) spec [2]. And there is good reason to do so:
for example we as Debian can specify the copyright information from
our packaging separate from the upstream code, without conflict. DEP-5
does not allow that.

> Firstly, I didn't think it was called DEP-5 anymore - it was accepted
> into policy in 2012 as "copyright-format" titled "Machine-readable
> debian/copyright file", so no longer a proposal for enhancement. This
> would be a minor pedantic point (a colloquialism) except for the fact
> that REUSE encourages it as part of their interface: `.reuse/dep5`.

Yes it is called "Machine-readable debian/copyright file Version 1.0",
but everybody knows it _is_ DEP-5, it is even in the spec in the
second sentence of the abstract. The spec _is_ still DEP-5, being
accepted doesn't change that.

> I think this undermines your previous point about it being less prone to
> failure - if we could trust upstream assertions on copyright, the NEW
> review wouldn't be a problem in the first place.

I strongly disagree. First of all, upstream knows way better where
they copy the code from than packagers do. And projects that use REUSE
are more likely to write that somewhere down as your average NPM
package that puts a "under MIT license" in the readme and copies
minified code from everywhere.
And as a second point, if you write a debian/copyright, you are most
likely to trust what is in the header, and I suspect the copyright
review in NEW is not different from this regard. I mean how can one
even know if the copyright information is wrong?
Yes there are cases where copyright information is missing and one can
try to search it, I've done this not just once, but if a project uses
REUSE headers, this doesn't happen.

Regards,
Stephan

[1] https://gitlab.cern.ch/geant4/geant4
[2] https://github.com/fsfe/reuse-docs/issues/81

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[nick black]

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 is and is not free software.  (IETF RFCs
> are a sadly common example.)

just as a personal example, i've got a fairly elaborate
Files-Excluded [0] for freely-distributed but DFSG-incompatible
media included with my upstream tarballs. doing so was easier
than trying to recreate e.g. jpegs as GIMP xcfs.

[0] https://salsa.debian.org/debian/notcurses/-/blob/master/debian/copyright#L9

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Russ Allbery]

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'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 is and is not free software.  (IETF RFCs
are a sadly common example.)

-- 
Russ Allbery (r...@debian.org)  

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Phil Morrell]

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
source of copyright assertions.

On Wed, Jan 26, 2022 at 12:49:34PM +0100, Stephan Lachnit wrote:
> It is straightforward to
> implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe
> " and "SPDX-License-Identifier: GPL-3.0-or-later" as
> comments to your source file's header and you are done.

I *am* a big fan of SPDX-License-Identifier, but the above being
straightforward is only true for the most trivial of examples. REUSE
advocate for sprinkling .license files around your repo for e.g. logos
and other binaries. Same story with multiple authors, they recommend
using multiple FileCopyrightText's initially, then split it out to a
separate AUTHORS file and use something like "Project X contributors".

https://reuse.software/tutorial/#binary-and-uncommentable-files

Ultimately, when everything becomes too much, REUSE falls back to
recommending Debian's copyright format anyway! So even if upstream sees
the value in taking some copyright busywork off our hands, why not
suggest they just use it in the first place in e.g. the LICENSE file.

https://reuse.software/faq/#bulk-license

> My idea is to allow SPDX documents in addition to DEP-5.

Firstly, I didn't think it was called DEP-5 anymore - it was accepted
into policy in 2012 as "copyright-format" titled "Machine-readable
debian/copyright file", so no longer a proposal for enhancement. This
would be a minor pedantic point (a colloquialism) except for the fact
that REUSE encourages it as part of their interface: `.reuse/dep5`.

> Note that I don't want DEP-5 to go away - it is unlikely that every
> project will follow the REUSE spec and writing an SPDX document by
> hand has no significant advantages over DEP-5. Besides, using the
> file-exclusion function in DEP-5 for uscan is quite useful for ds/dfsg
> packages (although that could also be moved to an external file).

I think this undermines your previous point about it being less prone to
failure - if we could trust upstream assertions on copyright, the NEW
review wouldn't be a problem in the first place. 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.


signature.asc
Description: PGP signature

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Max Mehl]

~ 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 needed.
> 
> Probably too technical at this stage, but a conversion tool in
> combination with the yaml format could actually be quite useful.
> E.g. one could have a debian/REUSE.yaml sub-file for the copyright
> information of the package build files and a debian/REUSE-source.yaml
> file in case the source does not follow the REUSE spec. If the
> reuse-tool would have an option to specify a different file for the
> root REUSE.yaml, we could actually use it for all packages with
> relatively low migration work on the maintainer side.

Perhaps it's really too early, but hey. The current idea for REUSE.yaml
is that, other than the DEP-5 implementation, you can have multiple of
these files in your project. Each file can describe files relative to
it, but not in parent directories.

Consider you have a sub-directory with binary files you'd like to mark,
e.g. icons you also re-use in other projects.  You could create a
REUSE.yaml file in the same directory describing them. Whenever you
copy the directory in another project, the licensing/copyright info is
retained.

This is the reason why it should not describe parent directories.
Therefore, such a file in /debian could only cover files in this
directory. But I understand that in this special scenario it would be
useful. I could think of ways how either Debian or REUSE introduce some
hacks around it, but before we elaborate on this I think there are other
more fundamental decisions Debian would have to make first ;)

Best,
Max

-- 
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom:  https://fsfe.org/join

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

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 provide a converter from DEP-5 to this new
> REUSE.yaml format.
>
> That would mean that the REUSE helper tool in the future could take
> DEP-5 files, convert them to the modern format, and run a lint to check
> whether everything is fine – and if you want, also generate a SBOM.
>
> 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 needed.

Probably too technical at this stage, but a conversion tool in
combination with the yaml format could actually be quite useful.
E.g. one could have a debian/REUSE.yaml sub-file for the copyright
information of the package build files and a debian/REUSE-source.yaml
file in case the source does not follow the REUSE spec. If the
reuse-tool would have an option to specify a different file for the
root REUSE.yaml, we could actually use it for all packages with
relatively low migration work on the maintainer side.

Regards,
Stephan

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Max Mehl]

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 than text, this
recording of a recent talk could be for you [^1]. Otherwise, please
check out the official website [^2] that also offers a tutorial that
should get you up to speed.

> Note that I don't want DEP-5 to go away - it is unlikely that every
> project will follow the REUSE spec and writing an SPDX document by
> hand has no significant advantages over DEP-5. Besides, using the
> file-exclusion function in DEP-5 for uscan is quite useful for ds/dfsg
> packages (although that could also be moved to an external file).

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 provide a converter from DEP-5 to this new
REUSE.yaml format.

That would mean that the REUSE helper tool in the future could take
DEP-5 files, convert them to the modern format, and run a lint to check
whether everything is fine – and if you want, also generate a SBOM.

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

With this, I just would like to emphasise that Debian's extra care about
proper licensing is a great plus and comes in handy if you were to
streamline and extend it by widely supported best practices like REUSE.
As Stephan said, I'd be thrilled to work together with you to make
licensing and copyright in Debian and ideally also upstream easier and
more understandable for users and developers.

Best,
Max


[^1]: https://www.sfscon.it/talks/reuse/

[^2]: https://reuse.software/

[^3]: https://github.com/fsfe/reuse-docs/issues/81

-- 
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom:  https://fsfe.org/join