FSFE Mailinglists
Sign In
Sign Up
Sign In
Sign Up
Manage this list
×
Keyboard Shortcuts
Thread View
j
: Next unread message
k
: Previous unread message
j a
: Jump to all threads
j l
: Jump to MailingList overview
2024
September
August
July
June
May
April
March
February
January
2023
December
November
October
September
August
July
June
May
April
March
February
January
2022
December
November
October
September
August
July
June
May
April
March
February
January
2021
December
November
October
September
August
July
June
May
April
March
February
January
2020
December
November
October
September
August
July
June
May
April
March
February
January
2019
December
November
October
September
August
July
June
May
April
March
February
January
2018
December
List overview
Download
REUSE
January 2019
----- 2024 -----
September 2024
August 2024
July 2024
June 2024
May 2024
April 2024
March 2024
February 2024
January 2024
----- 2023 -----
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
----- 2022 -----
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
----- 2021 -----
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
----- 2020 -----
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
----- 2019 -----
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
----- 2018 -----
December 2018
reuse@lists.fsfe.org
1 participants
1 discussions
Start a n
N
ew thread
Next steps
by Carmen Bianca Bakker
07 Jan '19
07 Jan '19
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
2
1
0
0
Results per page:
10
25
50
100
200