[Reuse] Next steps

[Gabriel Ku Wei Bin]

Dear Carmen,

Thank you so much for putting this together, and I do apologize for the
long delay in any follow up to this email.

To summarize your comments, the next concrete steps to take would be to:

* Convert Peter's flight rules into a more digestible tutorial
* Have someone with expertise in formal specifications to clean up the
language used
* Have someone program/implement automated functions for the Reuse tool

> 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.
From what I can tell, this bill of materials recommendation serves to
encourage conveniently locating and displaying license and copyright
information of each component software. Since the recommendations
already mark it out as an entirely optional step (albeit a helpful one
to adhere to), I agree with you that it might be prudent to remove this
step, especially if we want to simplify the recommendations to encourage
greater adoption of Reuse.

Perhaps someone more familiar with this subject that I am can comment on
the necessity of this provision?
> 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.
I notice that the current language includes a casual mention of version
control systems recording authorship and not copyright. Perhaps a more
comprehensive explanation in the recommendations might be useful just to
ensure that the explanations are available. I'm not sure how the
underlying issue can be resolved, however. It seems that clarifying this
would create more onerous obligations for the user if they choose to
rely on version control to record copyright information, which will
discourage the use of the Reuse recommendations.

---

I also have some questions regarding your suggestions that you could
perhaps clear up for me as a layman.
> 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.
Dos this mean that we should generate a comprehensive list of file types
that should be excluded from copyright? Apologies if this is a silly
question, I had trouble understanding the issue from the git
conversations linked.
> 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.
Could you explain the problems with using a different file path and
creating another branching option?
> 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.
As an aside, Bjorn has suggested setting up a category at discourse
instead of a mailing list. I find a forum style interface would work a
lot better than a mailing list for discussions.

Thank you for all your efforts, and thanks in advance for your patience
and explanations!

Best wishes,
Gabriel

-- 
Gabriel Ku Wei Bin - Project Manager
Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290 
Registered at Amtsgericht Hamburg, VR 17030  | https://fsfe.org/support


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.fsfe.org/mailman/private/reuse/attachments/20190107/97d5e22b/attachment.sig>