Next up, review.
Hello everybody, can everybody hear me okay in the back?
Then I'll speak up like this, okay?
Okay, perfect.
So I'm going to give a talk about reuse.
I'm Linus.
I work for the Free Software Foundation Europe as a CIS admin
and I'm also one of the maintainers of the reuse tool.
And so this tool, so since this is the S-bomb deaf room,
I need to relate what we do with reuse to S-bomb somehow.
And I think the catchphrase or what I want you to take away
from this presentation today is that if you want to have nice S-bomb
downstream, you should push everybody to use reuse upstream
because it makes everything else much, much easier.
Or just how reuse makes everybody's life a bit easier.
So typically with free and open source software,
you have compliance issues when it comes to license and copyright.
There's missing information about license and copyright holders
of your own code and of third party code
that you might use in your application.
There's license ambiguity, so for example if there's just,
it says GPL but you don't know which version.
And often when there's somebody taking the time to put
all the information there, it's stored in a silo
and it's not actually where the code is.
And often another thing is that when you change something
in the code you should or you have a new contributor coming on,
then you need to change everything again.
Developers also need a lot of training if there's custom solutions
and there might also be conflicting compliance practices.
So we thought like why can't we solve these issues here
up the stream so that when the water flows down
to everybody else who's consuming license and copyright information
of source code has just an easier time digesting them.
So reuse is based on a couple of principles.
It should be easy for copyright and licensing information.
Everybody should be able to find this easily,
so it should be in the file that it applies to
if that's possible, like of course with a binary file
that's not possible, but if it's plain text
that's possible and then it should go in there.
Silo's should be avoided and all the licensing copyright
information should be stored in the repo.
And that info should be readable by humans and machines alike.
We also do not want to reinvent the wheel if we don't have to,
so yeah, we try to be compatible, as compatible as possible.
And also licensing should be easy and fun.
And yeah, so we try to do that.
You can decide whether we manage, but at least we try.
So there's three simple steps to using reuse.
First you choose and provide the license.
Reuse does it with a nice little dialogue for you
when you start it up the first time, I can show you later.
Then you add copyright and licensing information,
preferably to every file.
And then we have a range of tooling that allows you
to confirm this reuse compliance,
either in a pre-commit hook, in CI,
and of course locally on your machine.
So I'll go through this quick.
Maybe just a quick show of hands.
Who has heard of reuse before?
Okay, so I'm preaching to the choir.
Who has used it before?
There's plenty of people on it before.
Okay, so I'll go through this rather quickly.
One thing that we do is we save license text
in a licenses directory.
I'll make a quick shout out to GitHub later about this.
Then reuse names after the SPDX license identifier,
and then they're stored in the licenses repository.
Then the copyright and license information is added to every file.
Then it looks roughly like that.
And then if you have uncommentable files,
binary files, images, or executables or whatever,
then you can do a separate license file,
which is a plain text file,
which refers back to that uncommentable file,
which then contains this information.
And also you can use a.deb5 file in.reuse directory.
This is about to change soon, hopefully,
because we are going to develop our own reuse YAML,
which sits at the root of the repository,
where you can define this type of information
for uncommentable files or for whole directories,
much easier than with.deb5.
And then the third step is you confirm
that you're actually compliant with reuse.
What are the components of reuse?
One thing is a spec where we pretty clearly try to state
how licensing information and copyright information
should be added to source code.
Then there's a helper tool, the reuse tool,
the reuse CLI tool.
Then there's a very good tutorial in FAQ
that you can look into to answer very basic questions
about licensing, but also some advanced stuff.
And then there's an API where you can sign up your project
and then get a nice badge who doesn't like badges.
So I've already said that we store the licenses in a
licenses directory, so the UI of GitHub, for example,
still doesn't pick that up properly.
That would be very cool if that happens.
It's not very hard.
And the rest of that, in the interest of time,
I'll skip over that.
So now I'll just show you really, really quick,
because I have five minutes left, I think,
how this works, how this looks in practice.
So here is the text size OK for everybody in the back.
So here I'm in a non-compliant repo,
and I can run reuse lint to confirm that I'm not compliant.
I have 6,000 in this repo, and none of them
have any copyright or licensing information.
That's not cool.
So I can just run reuse in it.
And now I'm asked to provide licenses,
so usually I use something like CCO 1.0.
For just configuration files and stuff like that,
then we could set GPL.
And then did you mean IRGP?
And then just call that example.
That doesn't matter.
So now we see it downloaded the licenses
and it created that file file for us.
Like I said, this will change.
And now I can start adding license information
to certain files.
So for example, now I can add the license CC0
to my gitignore file, for example.
I can run reuse lint to see what's changed.
And I see now I have one file with correct copyright information.
And I could now continue doing that for the rest of the files.
But I hope you get the idea that it's a tool
that really simplifies this process.
And then you can put the reuse lint checks
in your pre-commit hooks.
They're very terse.
They basically look like this.
That's all you have to do.
And then run pre-commit install.
And then before you commit, it does the reuse lint check.
So it's very, very simple.
It's very straightforward.
I had to jump through this a little bit
because I don't have that much time.
I just realized.
So the ongoing development is, of course, the tool.
And it's all free and open source.
And so you can contribute as much as you like.
And we are very happy about everybody who contributes.
And then there's an API, which is all fully open source
and free software.
We have a specification which will be extended
with reuse YAML really, really soon.
We hope that we can do some better integration,
especially with Git forages in the future,
that the UI shows you which licenses you have
in the repository right away.
And we want to spread.
And you can, of course, help us with that.
So who uses reuse?
At the moment, we have over 1,400 projects signed up
that use our API that have cumulatively more than 80,000
stars on GitHub.
Then there's stuff that lives on other forages like KDE
and the framework that uses reuse.
CURL became reuse compliant as WebLate,
a really cool translation product that recently became
compliant.
GNU Health Project, which is an awesome project,
the Corona 1 app in Germany.
And the Linux kernel is trying to become reuse compliant.
We'll take a while.
And yeah, so feel free to check this.
I will upload the slides, and then you have all the links.
If you want to participate, sign up to the mailing list,
ask questions, create issues, make one of your own projects
reuse compliant.
It's really easy.
Integrate reuse into your community and compliance
policies.
Help others adopt reuse.
Here, I linked the developer section of the website,
which is really the best way to get started really,
really quickly.
And yeah, I don't know, do I have time for questions?
Two minutes.
Maybe I can take one.
I also just a quick note.
Carmen is here.
She's one of the main creators of reuse.
So we'll also be happy to answer questions afterwards.
I'll take one now.
What does bad license mean in the Linux app?
A bad license?
Yes.
The linter shows in the header the first one is bad licenses.
I think.
It's not an SPDX license.
Ah, yeah.
It's not an SPDX license.
What does bad license mean?
And it means that it's not an actual SPDX license.
Yeah, but just on, yeah.
How do you handle custom licenses?
Yes.
I don't think we handle them at all.
Yeah.
You can make a custom license, license ref.
Ah, OK.
Yeah.
So you can make a custom license ref within SPDX.
So that SPDX allows you to do that.
And then the reuse tool follows that.
Yeah.
Sorry.
Only 15 minutes.
Sorry.