[Reuse] Minutes of FOSDEM meeting

Carmen Bianca Bakker carmenbianca at fsfe.org
Tue Feb 5 14:10:04 UTC 2019

Hi all,

It was a pleasure to meet you at FOSDEM, and I hope you had safe trips

In this e-mail I share the minutes of the meeting we had, though calling
them "minutes" might be overselling it.  I'm summarising the points
raised.  If I missed any, then my mind is fallible and my notes
incomplete.  I aim to keep the e-mail short, but I'm notoriously bad at

- It was raised repeatedly that adding headers to big projects is a
  non-trivial task that very few people want to do manually.  If this
  can somehow be automated, and if REUSE can facilitate doing this
  automatically, then it might increase the amount of headered files.

  + Important to note, however: This may result in false headers.
    Automatically adding headers to old files skips manual legal
    review.  This is something to be cautious about, and to convey to
    users of such a tool.

  + This would require a template(s).  The template(s) would be put in a
    "[.]reuse" directory.

  + Provide links to tools that might already do this, e.g. Maven

- The utility of the bill of materials (third step of REUSE) was

  + There was some misconception that this file could be used to declare
    the copyright and licensing of a file like in debian/copyright.
    This is not so.  Rather, it is a list of ALL files in a project and
    the copyright info that was discovered.

  + The bill of materials must ALWAYS be generated by a computer, and
    possibly curated by hand.

  + As such, the bill of materials may not need to exist within the
    repository.  It is build output, which customarily never exists in
    the codebase.  But if one wanted to, they could keep it in the repo
    and "bump" the file with every release.

  + Moreover, the bill of materials is not an actionable STEP for
    developers (though more on the target audience of REUSE later).
    Developers can run `reuse compile` to generate the BOM, but then
    there is nothing they can do with the output.  The output is for
    legal teams.  As such, being able to generate the BOM should be a
    _goal_ rather than a step.  i.e., once you can generate a complete
    BOM, you have succeeded in adopting REUSE.

- The specification is not a good tutorial.  A new tutorial must be

  + Link to existing tutorials.

  + One tutorial cannot cover the complexity of the spec unless the
    tutorial has an interactive decision tree.

  + If the decision tree is not implemented, then a tutorial ideally
    only covers _one_ path through the spec, and this should be clearly
    marked.  e.g., "this tutorial is one easy way to be REUSE compliant,
    but it is not the only way".

  + The tutorial should be as short and sweet as possible, and have a
    limited scope.  People do not like reading long tutorials, so a long
    tutorial would hamper adoption of REUSE.

- The specification is not a good specification.

  + It would be nice if the spec had identifiable bullet points that can
    be referenced, instead of being a wall of text.

  + The spec contains an error regarding SPDX Exceptions, which is
    approved for fixing.

  + The spec contains a lot of silly edge cases.  Rewriting the spec
    will fix this.

  + Matije and Carmen will co-operate on drafting a new spec.

- The recommendation that Git/VCS could be used to record copyright and
  authorship information instead of recording this information in the
  files themselves will be SCRAPPED.  People _could_ do that if they
  really wanted to, but it would be out of the scope of the REUSE spec.

- The tool is currently hosted on gitlab.org.  The website/spec is
  currently hosted on github.com.  There are still some bits and pieces
  on git.fsfe.org, possibly.  It would be good if this were cleaned up.

  + Preference for GitHub and/or GitLab, because git.fsfe.org has a
    non-trivial barrier for entry.  GitHub probably has the lowest
    barrier, but is the least in line with FSFE's ideals.

  + Consult Matthias about this.  Gabriel?

- Programmers really like automation.  The tool could do some extra

  + Possibly reduce Python version from 3.5 to 3.3/3.4 for teams that
    are stuck on old Python versions.  Python 2 is out of the question.

  + Provide a Docker container for people who really hate dealing with

  + `reuse init` to automatically set up some simple stuff.

  + Download licences from SPDX or elsewhere.  Fill in the templates

  + Set up the DEP-5 file.

  + Auto-generate headers (see above).

- People don't want to mark trivial or config files as having copyright,
  and want to exclude them from the linter.

  + Excluding files from the linter is a can of worms best left closed.

  + Make a clear recommendation to license those files under CC0.

- Sites such as GitHub do not recognise the LICENSES directory.  This
  leads to an awkward situation where you have to put your "main"
  licence in LICEN[CS]E, COPYRIGHT or COPYING for it to be recognised.
  This is not ideal, because now LICENSES does not contain ALL

  + If you elect to put everything in the LICENSES directory, the site
  will erroneously say that you have no licence at all.

  + This also messes with multi-licence projects.

  + Contact GitHub/GitLab/Bitbucket about collaboration.

- "debian/copyright" is not a great file path.  It is incompatible with
  projects that legitimately include that path, and it incorrectly
  invokes a relation to the Debian project.

  + Allow the user to specify their own path.

  + Change the default to "[.]reuse/dep5" (or something similar).

- MIT and BSD are tricky licences.  They include the copyright holder
  within the licence---which means that no two such licences are
  identical---and mandate an exact reproduction of the licence.  REUSE
  currently deals with this by recommending the developer to create a
  separate licence for every copyright holder, but this is frankly very

  + Solve this by not making any recommendations about this in the
    spec.  Instead, include an explanation of the problem in an FAQ.

- Speaking of an FAQ: Turn the flight rules into an FAQ.

- There was some confusion regarding the goal of REUSE and its target
  audience, and I am not certain it is solved entirely.  What follows is
  a summary mixed with personal reflection.

  + The argued goals are (1.) making sure that copyright information can
    be parsed by computers, (2.) making sure that developers know how to
    license their stuff, (3.) make sure that lawyers can generate SPDX
    files, and probably some more goals that have slipped my mind.

  + After some reflection, it appears to me that they are all perfectly
    valid and tangential goals, but the fact that there was some
    (slight) confusion and disagreement here re-ignites a pain point I
    should have written down, but did not: REUSE does not have an
    elevator pitch, and it desperately needs one.  When I talk to a
    developer and tell them about REUSE, I do not have a simple, quick
    explanation at hand, even though I've been working on this for a
    while.  Any attempt at an elevator pitch quickly becomes convoluted:

    "The REUSE Project presents a set of recommendations to developers
    that they can implement so that their project have full coverage of
    copyright and licence information, in such a way that a computer can
    verify this".  This elevator pitch is correct, but more than a

I hope that this has covered most of the talking points (and action
points).  Please correct the things I got wrong, and add things I
forgot.  I am only human.

With kindest regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fsfe.org/mailman/private/reuse/attachments/20190205/0197800a/attachment.sig>

More information about the Reuse mailing list