April 2019 - REUSE - FSFE Mailinglists

Re: [Reuse] REUSE tutorial
by Carmen Bianca Bakker 16 May '19

16 May '19

Hi reuse list, Forwarding this e-mail I got from Luis (Tidelift) after he kindly offered to offer me feedback. Je mer, 2019-04-24 je 12:57 -0700, Luis Villa skribis: > Hey, Carmen- [+work email] > Great meeting you in Barcelona! > > Couple of observations on Reuse; feel free to share (or point me to a better discussion forum): > As we already discussed, "why" would be good. Eventually, to be transparent, I think one reason "why" could be "Tidelift's customers will pay you, through Tidelift, to do it". > Wildcards/patterns would be really good to have formally in the spec somewhere, so that (at least as a default) something more powerful than per-file could be used. I think you mentioned that's currently possible via debian packaging formats but extracting that out would be useful. > It'd be good if the documentation mentioned what tools actually pick up Reuse metadata. eg, my understanding is that Valid-License-Identifier is a Reuse-specific extension and so may not get picked up by all scanners? If it is picked up by many major scanners, it'd be good to say that! > Should it have a concept similar to ClearlyDefined's facets? I think it'd be useful to be able to not just say "this file is CC-BY", but "this file is CC-BY and a documentation file", or rather than "this file is proprietary" instead "this file is proprietary and a test file". Both of these are common situations that metadata would help scanners to analyze and deal with, and that upstream maintainers are best positioned to analyze. > Have you given any thought to how this meshes with SFLC's recommendations? Specifically, they recommend centralizing copyright notices, and that seems like something that might be worth incorporating somehow. > Hope these thoughts are useful! > Luis

4 9

How to handle non-compliant files in tarballs?
by Max Mehl 16 May '19

16 May '19

Hi all, We currently have the problem that the REUSE tool which you can download from pypi [^1] actually is not REUSE compliant although the source code itself is. This might also be true for many other projects who distribute their releases through similar services. The reason is that by compilation files are being created, e.g. binaries or documentation, which do not carry license information nor are accompanied with corresponding .license files. How shall we deal with those? Carmen and I discussed several options, but didn't find something completely convincing. So please share your opinion to find a good solution: 1. Ignore the whole problem and assume that people interested in reusing source code will find the source repo and start from there anyway. This would ignore the few cases in which FOSS projects do not have a publicly accessible VCS and are only published via tarballs containing such problematic files. 2. Recommend projects to always link to the source code repo in the README file so interested parties will always find the REUSE compliant code somewhere and do not reply on the released tarball. 3. Recommend projects to put the problematic files in the .gitignore file. REUSE will not take these files into consideration anyway. The problem is that people will probably remove this file from a packed release, and sites like pypi might to so as well. 4. Recommend projects to add the problematic files to a DEP5 file which is also shipped with the product. What do you think? Best, Max [^1]: https://pypi.org/project/fsfe-reuse/ -- 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 1

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

2024

2023

2022

2021

2020

2019

2018

REUSE April 2019