All right, folks, we're starting.
So we've got Alan Pope, and he's going to talk about community and compliance.
Hello, everyone.
We might have to go slightly fast because my laptop battery is dying, so apologies for
that.
So hello, and welcome to my short, gentle talk, Compliance as a Community Effort.
I've got two goals with this talk, raise awareness of compliance tools available in
open source projects, and increase compliance engagement in open source projects between
maintainers, contributors, and the rest of the community.
It's a new topic for me, so I'd appreciate any feedback, either afterwards, here in
Meet Space, or later in a bar, or via email.
My contact details are at the end.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thanks, woes.
That includes code scanning, reviewing to ensure compliance with their license obligations,
DevOps integration to build compliance tools into their development process.
We also provide open chain certification processes and services.
And recently we've also provided training to, I have to say this is quite vaguely,
developers of a large proprietary software product
which consumes a lot of open source products.
That's as specific as I can be.
So, let's get into the mind of an open source developer.
The quick and easy questions,
you likely know the answer to,
but the answer may be different for each of you.
Why do developers create open source software?
Why would you do that?
There's many reasons beyond because I can
and because I want to and why not.
There's the traditional one which is to scratch an itch
or to solve a problem of some kind that that developer has.
There's personal development,
maybe you want to learn a new toolkit, a framework,
learn a new language or something.
Maybe you want to build a portfolio,
have some contributions on your GitHub profile
that everyone looks at or maybe you want to announce a project
on LinkedIn if you're looking for a job or something.
Some people do it just for a sense of community and contribution.
They just want to give back,
helping others with new software to increase the corpus of software
that's out there in the community.
Maybe it's your job, maybe you've just been told
to work on some open source software.
That happens as well.
There's a number of reasons why people contribute
or create new software.
That's all very reasonable.
But why do people and organizations contribute to existing software?
I mentioned why people create them.
What about why people contribute?
Maybe they want to improve it.
Maybe they want to fix some bugs, add a feature
or change functionality in the software.
Maybe they also want career advancement
and they fear that adding a few contributions on GitHub
will help them in their career.
Maybe community and networking is what they desire.
Open source projects bring people together from around the world
with shared interests.
That's pretty obvious given you're at FOSDEM
and if you look around you,
there's a lot of people with shared interests around you.
Some people want to give back,
maybe it's a sense of altruism.
There's a lot of reasons why people contribute to open source software.
That's why people contribute.
What about some of the ways in which they do that contribution?
How do they contribute?
There's probably amongst those items listed there
some of the activities that you may have taken upon,
whether it's translating software into your language
or maybe you've filed bugs
or maybe you've handed out stickers and events.
There's a lot of ways in which you can contribute to an open source project
depending upon your skill set and your desires.
But one of the things that's often missing from these
often cited lists of ways you can contribute
is actually license compliance.
Doesn't sound super interesting.
Why would I want to do that?
Well, trust is a big thing in open source software.
Some of the keep contributors and users coming back
is confidence in your project and a sense of trust in your project.
At the basic level, they trust that the project is sustainable.
Users might trust that the project is going to update regularly
and put out timely releases when needed.
Contributors to those projects will trust that their translations
get merged in a timely fashion.
That code gets reviewed in a timely fashion
and merged into the project and eventually released
and that their bugs get attention.
And consumers of the project, maybe not direct consumers,
maybe they're consuming your project inside their project.
Maybe you built a library and they're using your library.
They may want to trust that you're on top of security issues.
And all of them likely trust, perhaps subconsciously,
that the project is complying with license requirements.
A lot of the time people don't even think about it.
It may, of course, be the case that your favourite project
is fully compliant with all of their license obligations.
Do you know that for sure, though?
Do you really know that for sure?
What about all the dependencies that that project depends upon?
Are you certain?
When did you last check to make sure?
Can you prove that you're complying with all the licenses
if someone did ask you?
Indeed, consider what you would say right now
if someone asked you,
does your project comply with all the licenses
under which the software is distributed?
In my experience, the majority of traditional open source projects
are not written by lawyers.
And also, the project team may not have access to legal advice,
not directly, especially smaller applications
or libraries created as a side project
or something you do in the evening.
But in order to improve trust in the software supply chain,
it's something we should consider,
just like all the other activities I listed on one of the previous slides.
So let's think about the community's role in this.
Users and contributors are already very familiar with these buttons in GitHub.
They'll often use them without prejudice when you have bugs
or when they require a new feature or when you've moved their cheese.
And from a practical perspective,
the project should accept license issues
just like they accept any other issue.
It's just like any other bug, right?
And users and contributors should be empowered and encouraged
to hit that button when there's a license issue.
But we should also assume good intent.
The default posture when a license issue is raised
is not quick, let's sharpen all the pitchforks
and start a thread on Twitter and Reddit and hack and use.
It's engage in open conversation on the issue.
There are a few barriers to community engagement with these compliance issues.
There's a lack of awareness and understanding of licenses in general.
Many contributors may not be fully aware of the importance of license compliance.
That can be addressed with a bit of education, better documentation.
It's a complex topic.
Interrelationship between different types of potentially incompatible licenses
is a hard thing to understand sometimes.
So to make it easy, we should simplify the process
of enabling them to report issues.
Automate regular scanning of your project.
There are tools I'll mention in a minute that can scan your project
and highlight when there are license compliance problems.
You can also integrate that into the whole process
so that every time someone submits a pull request,
a scan is done to ensure that not only the code is tidy
and the tests run, but the tests should include license compliance as well.
One of the other barriers is fear of legal repercussions.
People don't want to press the issue button
because they worry that if they talk about the problem,
then the lawyers are going to come knocking on their door
and it's all going to be blown up out of proportion.
But what we should do is highlight that we're open
to talking about these compliance issues.
Be welcoming when someone wants to report an issue
and foster a community that's full of open communication and dialogue
rather than won't fix that kind of thing.
So where do we start?
Well, the Linux Foundation have a project called Open Chain.
It's a good place to start.
It's full of policies and procedures, loads of documentation.
It's all open source.
I've put a picture of the website up there.
The URL is openchainproject.org.
If you Google for Open Chain, you find some nonsense blockchain stuff.
So this is the actual website.
And it's all on GitHub as well.
So there's repository in there with loads of documents
that you could get started with to understand this whole compliance process.
There's also a ton of tools available to help you.
At the top end, there's the rather spendy black duck.
Then there's open source tools like SIFT by Ankor and OSS Review Toolkit.
And these allow you to build a software bill of materials
so you understand what all the bits and bytes are inside your project
and they can scan your repository,
they can scan docker containers that contain your software
and all that kind of good stuff.
These tools don't solve everything.
They're part of the story, but they're very useful for automating that scan.
So you're aware of stuff that may be non-compliant ahead of time.
We should, as I said, engage contributors in the compliance process.
Ignoring a license violation and hoping it will go away is not a solution.
We should educate and raise awareness that we're open to this kind of dialogue.
Educate the rest of the team so they know that if someone files a licensing issue,
don't panic, don't just delete the GitHub repository.
It's not necessarily caused a panic.
People make mistakes with their licenses and these things are solvable.
And also celebrate the successes.
So when you do solve a problem, don't bury it in a commit somewhere
that fixes the license.
Celebrate it like we weren't compliant and now we are.
That's great.
Just as you would celebrate the release of your software, celebrate being compliant.
That's a good thing.
I've mentioned we should establish clear policies and procedures
so people know what their expectations are when they file an issue to do with compliance.
And also promote a blame-free environment.
Don't go pointing the finger and sharpening the pitchfork to try and find out,
well, who committed this thing and who, you know, go through the get blame history
and try and figure out who it was and chase them down.
That doesn't help.
Let's solve the problem and understand why it happened
and try and prevent it happening in the future.
Maybe assign responsibility.
Maybe your team is large enough that you've got enough people
that someone could be responsible for monitoring license compliance.
I get that a lot of open source projects are, you know, that XKCD comic
and the little balancing thing in the bottom right-hand corner.
There's a lot of open source projects like that.
But if you do have a significant team,
maybe give some responsibility to a community member to keep an eye on this kind of stuff.
So some takeaways from my little semi-rant.
Integrate some compliance tools early on.
Start scanning your projects.
Make sure that you're using the correct licenses in the correct ways.
Maybe you have a lot of dependencies.
It's quite fashionable these days to use software from NPM and Cargo and Pipeye
and, you know, are they all compliant as well?
Are you consuming software that is also compliant?
Leverage automation.
You absolutely should have tools that are scanning your repositories on a regular basis.
And this kind of stuff is pretty easy to do.
Many of the providers that I've mentioned,
you can just enable a GitHub action on your repository.
Very quick and easy to do, very straightforward,
and gives you a bit of peace of mind that you're scanning on a regular basis.
And integrate compliance into the review process.
So when someone contributes a new code,
you can scan that before it gets merged,
rather than two years down the road when that contributor has left the project.
And engage with the community.
Don't be afraid to have conversations in the open, in Matrix or IRC or wherever it is.
You have those conversations.
Don't feel the need to hide those licensing conversations away
because you're scared of the lawyers coming knocking on your door.
Switching tack slightly.
I wanted to mention another project.
We're bootstrapping this at Orcro, and it's a project called Corinthian.
One of the challenges of open source businesses is in terms of mergers and acquisitions.
Company acquiring another company asks the other company,
do you have any open source software?
They say, I don't know, somewhere maybe, I don't know.
And in order it may be done.
But the problem is the lawyers who are very smart about mergers and acquisitions
are not necessarily super smart about open source software and licensing.
And this is a bit of a gap in the market for lawyers performing these activities.
So we started this project to collate process documentation for lawyers
to help them understand the open source community,
the open source licenses, how they fit together, how they interact.
It's all open source, they will all be on GitHub.
That domain just points to a static page at the moment, but we're building it out.
I sincerely apologise for the AI generated Corinthian logo over there.
It was done in a hurry. Patches welcome.
And finally I wanted to highlight another talk this weekend
given by Andrew Katz, Andrew is a well respected and knowledgeable open source lawyer
with many years experience in the field.
He's also an all round good egg.
He's the all gross CEO, so he's my boss.
So please go to his talk tomorrow.
Or watch it online later on if the room is full.
I hope the information I provided has been interesting.
If you have any questions, again, I'm not a lawyer.
This is not legal advice. It's just my opinion.
Thank you for this.
So quick question.
Is there any support that a company or organisation that can support
humanitarian organisations or other organisations in being compliant?
Like kind of consultancy or support or ad hoc or whatever.
Or guiding or come, let's say come a week to our organisation,
help us set things up in the right direction and just, you know.
Yeah, there are a few organisations that can assist in this kind of stuff
like Software Freedom Law Centre,
Software in the Public Interest,
OSC, what is it, Open Source Something.
It's also a different channel.
I will put the notes, the answers to that question in the slide
and upload it to the FOSDEN website.
So, fun talk.
Right now there is sort of a lot more pressure around knowing what's in your
software because the security folks have suddenly realised,
gosh, we should worry about that.
Is there a way that we can sort of align efforts from the compliance folks
with the security folks?
It turns out that some of those tools that do security scanning
also do license scanning as well.
So there is actually quite an overlap there and some of the tools
can like hit both buttons for you.
Things like SIFT that does the S-bomb,
ANCOR have other tools that can do the security scanning as well.
So yeah, there are some tools that can do that, absolutely.
So more of a shout out for a project and tool than a question.
Reuse.software, that's the URL.
So it's a Python tool reuse and it's also a spec around how to put
license information in your project.
Nice.
You can't really comply with SIFT, the dependencies you use
haven't actually told you what their license is.
So that's for everyone.
Make clear what license the software is released under.
Absolutely.
So Reuse.software has good tools for the whole video.
Excellent.
Thank you for that.
You have four minutes of your lives back.
Thank you very much.
Thanks very much.