[Reuse] Next steps

[Carmen Bianca Bakker]

Hi all,

It's already been two weeks since SFSCon in Bolzano.  I think that those
interested in participating have joined the mailing list by now.  If any
of you know good candidates for the list, however, feel free to invite
them.

Now, point in case.  I will keep this e-mail short as not to be
tedious.  I will first list some pain points of the REUSE project:

1. The 3rd "step" of the REUSE recommendations---creating a bill of
   materials---seems very superfluous.  It doesn't appear like this
   document should be included in the source repository of a project
   (because it can be automatically generated), though one might
   possibly include it in a tarball release.  One could make a
   reasonable argument for removing this step, or presenting it much
   more clearly as entirely optional.  Its purpose, however, I do not
   entirely understand.

   Solution: This needs debate.

2. The specification of the REUSE Initiative is not easy to read, and
   does not function very well as a guide on how to make your project
   REUSE compliant.  The flight rules made by Peter
   (<https://github.com/idm-suedtirol/reuse>;) do a much better job of
   this.

   Solution: This needs debate and people willing to transform the
   flight rules into a tutorial.

3. Furthermore, I would argue that the specification is not formal
   enough.  Because it does double duty as guide and as specification, it
   does neither exceptionally well.

   Solution: This needs debate and someone who has skill in writing
   formal specifications.  Rather embarrassingly, though I study
   software engineering, I've never seen a course on formal specs in my
   life.

4. The recommendations contain one very problematic recommendation:
   Tracking copyright via version control.  For those who are not 100%
   familiar with version control: Every time you make a change to a
   document, you make a "snapshot" of the exact changes and push that to
   the central project.  Theoretically this makes version control a
   great candidate for tracking copyright, because you could see exactly
   which line was authored by whom---just find the snapshot in which
   that line was last changed.  But author =/= copyright holder.  And
   sometimes, author =/= author.  If I copy a section from a third party
   project and put that in my own project, then my snapshot will
   erroneously say that I am the author.

   Solution: This needs debate.  I am forwarding another e-mail about
   this.

5. The reuse tool is hosted on git.fsfe.org, which unfortunately means
   that people aren't very likely to do random contributions.

   Solution: I am currently moving the tool to GitLab.  I am choosing
   GitLab over GitHub because it's free-er, and because I'm familiar
   with GitLab CI.

6. Peter observed that programmers really like automation, and expressed
   a desire for the reuse tool to do more automation.  For instance,
   automatically downloading license files, or setting up the
   debian/copyright file.  I principally agree, but want to caution
   against automating too much.  The tool is not allowed to make any
   assumptions outside of the REUSE specification.

   Solution: This needs ideas, and a programmer to implement those
   ideas.

7. People keep wanting ways to exclude files from copyright.  See
   <https://git.fsfe.org/reuse/reuse/issues/69> and
   <https://git.fsfe.org/reuse/reuse/issues/54>;.

   Solution: This needs debate.  Either the linter will allow excluded
   files, or there needs to be very clear documentation that this is not
   possible by design.

8. People aren't actually using the REUSE recommendations.

   Solution: I don't know.

9. "debian/copyright" is an awkward file path.  It might conflict with
   some projects, creates the erroneous impression that a compliant
   project has something to do with Debian somehow, and purists are wont
   to complain about ugly stuff like this.

   Solution: This needs debate.  We could propose a different file path,
   but I want to avoid a situation where we create another branching
   option.  This would effectively be backwards-incompatible.

10. The REUSE Initiative has a lot of special cases and options to
    choose from.  You can use "Copyright" or "©".  You can put copyright
    information in the header, in a .license file, or in the
    debian/copyright file.  You can put licenses in LICEN[SC]E, COPYING,
    COPYRIGHT, LICENSES/whatever, etc etc etc.

    Solution: It appears to me that all these special cases and options
    are somehow necessary and justified.  Any superfluous things that
    can be culled should probably be culled, though.  Solving point
    no. 2 would come a long way.

I think that includes most grievances.  Feel free to expand upon that
list.

As an additional goal, those grievances should somehow be condensed into
a list of "deliverables".  Gabriel should know more about this in
coordination with Matthias.  My understanding is that a list of
deliverables is a restricted set of specific achievable goals before a
certain date.

Welcoming any input.

With kindness,
Carmen

-------------- 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/20181201/ad883223/attachment.sig>