- REUSE - FSFE Mailinglists

Examples of guidelines implementing REUSE and a general ©/FOSS FAQ
by Matija Šuklje 18 Apr '19

18 Apr '19

Hi all, as discussed during the LLW, I am happy to share (the revelant parts of) our internal guidelines and FAQ. Liferay donates the attached files to REUSE under CC0 for its content to be reused and edited to make it useful. Do note that while I edited the texts, some parts still have some project- and company-specific bias, which should not be directly copied into REUSE material, but could prove useful to see how things look in practice internally. cheers, Matija Šuklje -- gsm: +386 41 849 552 www: http://matija.suklje.name xmpp: matija.suklje(a)gabbler.org sip: matija_suklje(a)ippi.fr

2 1

New drafts for tutorial and FAQ
by Max Mehl 18 Apr '19

18 Apr '19

Dear all, As a result of a rather spontaneous sprint, we have a second draft of the tutorial and a first rough draft of the FAQ which could use a cautious read and your valuable contributions: Tutorial: https://github.com/fsfe/reuse-docs/blob/tutorial/tutorial/tutorial.md FAQ: https://github.com/fsfe/reuse-docs/blob/faq/faq/faq.md As you will notice, the initial 3 REUSE steps in the tutorial have been changed slightly in order to integrate more nicely with our target audience (primarily devs of small/medium-sized projects). It also does not give many different options but recommend a sane default. In general, it's much more engaging and more clearly structured, and takes the more helpful output of the current beta version of the reuse tool into consideration. Edge cases and additional questions are handled in the new FAQ. They contain really general questions ("What is copyright?") and also complex stuff. We haven't answered the questions yet but we thought that collection typical uncertainties first is the higher priority. Please feel free to provide answers to some of them via creating a pull request. Regarding the specification, we haven't made any progress today. On the one hand, this will be a big project and we still have some open questions (see upcoming mails), on the other hand we consider the priority of having more useful hands-on info for developers soon higher than waiting for everything to be finished. At this occasion, I should mention that we've heavily reorganised the repositories. Now, everything is hosted under <https://github.com/fsfe>, and the website has been split in documents (tutorial, spec, faq) and the actual website source, and mirrored to <https://git.fsfe.org/reuse>. This allows for the most open collaboration but also decentralisation to some degree. The old GitHub org will probably be deprecated. Please let me know how you like it. If you have some spare minutes, please also consider to contribute your knowledge by answering some FAQ, or create an issue report if you see need. Thanks! 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

1 0

18th of April: REUSE sprint in Arnhem
by Carmen Bianca Bakker 15 Apr '19

15 Apr '19

Hi team, reuse, Following some successful back-and-forth about REUSE at LLW, Max and I intend to do a sprint in Arnhem on Thursday the 18th of April. The focus of the sprint will be: - Cleaning up the website and git repos. - Working on an FAQ for REUSE. - Working on a tutorial for REUSE. - Maybe possibly working on a REUSE spec. The sprint will last from 10:30 to 17:00, Amsterdam time. If someone happens to be in the area or is otherwise interested in collaborating remotely during that time span, please be in touch. With kindness, Carmen

1 0

ClearlyDefined
by Peter Moser (NOI Südtirol/Alto Adige) 11 Apr '19

11 Apr '19

Dear REUSE-list, as you may already know, it exists a project called ClearlyDefined. https://clearlydefined.io/about Any thoughts on that project? How does REUSE compare (or how is it different in its goals) to ClearlyDefined? Cheers, Peter -- Digital Technologies ICT Peter Moser T +39 0471 066 672 p.moser(a)noi.bz.it<mailto:p.moser@noi.bz.it> NOI Techpark Südtirol / Alto Adige A.-Volta-Straße / Via A. Volta, 13A I-39100 Bozen / Bolzano www.noi.bz.it <https://www.noi.bz.it> <https://www.noi.bz.it> <https://www.noi.bz.it>

2 1

Where to put a licence header
by Max Mehl 09 Apr '19

09 Apr '19

Dear all, When discussing with Reinhard how the FSFE's technical teams can comply with REUSE, we wondered which files actually need a license header. In the current practices, REUSE only speaks about "source code files", but also about "each file". For our code files, the case it quite obvious. For our community database, an exemplary file is [^1]. But what about a Dockerfile (like [^2]). IANAL, but it seems like such simple instructions do not meet the threshold of originality. Do they still need license header? And would that rather be a code licence like GPL, or a content licence like CC? We also wondered if and how CSS files can be licensed according to REUSE. Best, Max PS: I am aware that these might also be more general licensing questions, but I think that REUSE should provide answers to those as well. [^1]: https://git.fsfe.org/fsfe-ams/fsfe-cd-front/src/branch/master/fsfe_cd_front… [^2]: https://git.fsfe.org/fsfe-ams/fsfe-cd-front/src/branch/master/Dockerfile -- 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

4 3

Draft of REUSE tutorial
by Carmen Bianca Bakker 03 Apr '19

03 Apr '19

Hello kind people, I have created a draft of the tutorial. Going into the tutorial, I prioritised three things: - Length (i.e., keep it short) - Clarity of instructions - Tangibility/relatability Things I explicitly avoided (but might need to be mentioned elsewhere): - Explaining how copyright and licensing works - Explaining why this is important - Explaining how SPDX and DEP-5 work - Explaining rationales for REUSE decisions - Explaining all the possible options from the spec - Explaining that some licences might not be compatible, and you may occasionally need legal review from an expert - Explaining that Free Software licences are the best licences Specifically, I wanted to touch on these things going in: - How to add licence - How to mark files as being under a certain licence - How to deal with files that cannot have headers - How to deal with large directories And so I ended up with <http://carmenbianca.eu/en/reuse/>;. If or when you have time, please let me know how it could be improved, or whether the general style of the tutorial is fitting at all. I am half-certain it would be much better with nice illustrations, but I am not very good at those. With kindness, Carmen

3 4

Minutes of FOSDEM meeting
by Carmen Bianca Bakker 20 Feb '19

20 Feb '19

Hi all, It was a pleasure to meet you at FOSDEM, and I hope you had safe trips home. 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 that. - 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 plugin. - The utility of the bill of materials (third step of REUSE) was debated. + 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 created. + 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 things: + 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 Python. + `reuse init` to automatically set up some simple stuff. + Download licences from SPDX or elsewhere. Fill in the templates automatically. + 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 licences. + 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 ugly. + 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 mouthful. 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, Carmen

2 2

Introduction new team member
by Max Mehl 13 Feb '19

13 Feb '19

Dear all, I am Max, Programme Manager with the FSFE. I would love to become part of the REUSE project and help pushing it forward. With this email I would like to introduce myself to those who don't know me, and outline a few parts of the project I could be of help for. For the FSFE, I am coordinating a few projects, for example the "Public Money? Public Code!" initiative [^1] or the EU project FOSS4SMEs which will create learning materials about Free Software for people working in SMEs [^2]. I am also supporting our technical teams, although I am no technician by profession but a political scientist. What fascinates me about REUSE is the intersection of individual developers, the practical needs of companies, and the legal aspect of licence compliance. I also like its mix of technical tools and human-understandable guidelines. I hope I can add some value when it comes to explaining technical things to non-techies, boiling down complicated information to a few lines of text, and creating symbiosis with other projects inside and outside of the FSFE. At the same time, I am also keen on learning more about practical licence compliance. If you have any further questions about me, please do not hesitate to get in touch with me. I am looking forward to working with you on this exciting initiative! Best, Max [^1]: https://publiccode.eu [^2]: https://fsfe.org/activities/foss4smes/ -- 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

2 4

Intros and ClearlyDefined
by Jeff McAffer 12 Feb '19

12 Feb '19

Hi All, Jeff McAffer here. Gabriel connected me up with this list after a discussion at FOSDEM. I run a project called ClearlyDefined (https://clearlydefined.io) as part of the OSI which is aimed at clarifying, amongst other things, the license/compliance related data around open source components. The main goal is to reduce friction and increase engagement around open source. This is, I think, very much inline with the REUSE mission and there are likely some great intersection points. The short version of the project operation is that we mechanically harvest as much data as we can from the packages and repos out there. This involves running ScanCode, FOSSology, Licensee, and some custom tools to find licenses, copyrights, source location, release date, ... The harvested data is summarized and aggregated to form a "definition" that contains the license-related info in a normalized form. Since tools are not perfect and data is often missing, we enable people to curate the data by submitting pull requests to a repo on GitHub. These are reviewed and vetted like any other open source contribution, and eventually merged causing the definition to be updated. >From there we work with the upstream community to either learn where they keep the data we missed or add/correct the data in the project if it was missing/erroneous. That way, future releases of the project are, well, more clearly defined. It would be great to look at ways we can collaborate to drive our shared goals. Jeff

1 0

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

2024

2023

2022

2021

2020

2019

2018

REUSE