to introduce our next speaker, Klaus Wicke-Hot.
Yeah, thank you and welcome to my talk.
Actually, today I'm here representing the Open Source Business Alliance, so the OSPR.
We are a non-profit organization representing more than 200 companies in Germany trying to make money with open source software.
And also the goal of the OSPR is to promote usage of open source software.
So we have some heavyweight members like Susie, Redhead or Telekom, but also smaller companies like Linodata, whom I'm working for.
And within the OSPR we have several working groups, and I'm the spokesman of the working group Beschaffung, that means procurement.
And so we are busy, or we were busy the last year with negotiations, with people working on this sector,
and I want to share a bit all the experiences, all the insights I found personally,
because I think it's very interesting to see the other side of the table when we're talking with people about that.
I've had a disclaimer, so this is no legal advice. I have an engineers degree, I'm more kind of a developer,
and I just came a bit of by accident into this world.
So this is no legal advice. If you have legal issues, especially license issues, you need to go and get a lawyer.
So why is all this getting more important on part of the public sector side?
So we know that the world is changing sometimes, and in different ways we don't expect.
I remember the last FOSTEM before Corona, and then just a few weeks later the streets were empty because there was the lockdown.
Then we had a FOSTEM completely virtually, that was very strange because we were sitting relaxed with coffee and everything at home,
but you're missing the atmosphere, the people aren't there.
We had the Ever Given, Got Stuck and the Suez Channel, so we are running out of supplies with IT hardware and all these things.
Now we have a war on the Eastern part of Europe, and it all leads to something that we call sovereignty,
especially digital sovereignty, and this is something that the countries really now understand themselves,
so they see that they have to be able to react on things and to handle on their own will.
So in the actual coalition agreement from the German federal government, there is something stated, it's in German, but I translated it for you.
So developments are usually commissioned as open source, and the corresponding software is generally made public.
And there are many more initiatives in German counties and cities that are focusing on building on open source technology,
and I'm pretty sure it's the same all over Europe.
We have contacts to France, to Luxembourg, where all these things also happen in a similar way.
So far so good.
It's quite hard to get an understanding on how the number of used open source software evolves.
So the main principle in our open source software is that we share it with everybody.
So I cannot check somewhere how many installations there are.
You can sometimes figure out in server logs what kind of clients are connecting.
You can check download numbers from GitHub, GitLab and whatever, but you don't see a real number.
So at OSPR we didn't survive on our member companies dealing with selling open source to the public sector.
And asking a bit about the issues they face and the question that arrived.
And we also did monthly workshop with the minister in Germany that's responsible for some of these contracts.
And then we got some pretty interesting insight about the issues they have.
And the result is the open source licenses we use, and the contract management on the public sector side, they are not really friends.
So there are some problems that we need to solve, that we need to address, and there's really room for improvement.
And I want to point out some of these things here.
So the power of open source is something that I don't have to explain to you.
These are the four freedoms defined by the Free Software Foundation stated in the GPL.
We all know that probably by heart, and this is the base of all our work, let's say.
But these power of open source, they come with a price tag.
And this is something I didn't know before I was really looking into these issues.
Because you get all these freedoms if you apply to the terms and conditions.
And I took it here from the GPL to O.
You may copy and redistribute verbatim copies of the program source code as you receive it.
And any medium provided that you consciously and appropriately publish on each copy an appropriate copyright notice and disclaimer warranty.
Keep intact all the notices that refer to this license and to the absence of any warranty.
And give any other recipients of the program a copy of this license along with the program.
These terms and conditions mainly apply in the case of distribution of software.
This is something that is not very common in a business to business situation.
So if the company is buying software, they just want to keep it for themselves.
They are producing cars or they are bakery.
So they are not going to distribute the software.
So there is no problem.
But if you go business to government, you most often have the situation that the government itself is a huge complex body with several legal entities.
The company is organizing the software and then they have to distribute it to the other parts.
And then this distribution fact applies here.
And then they have to check if they apply on the licenses.
And they have to check that everything is complete and everything of these conditions are fulfilled.
So these are legal issues.
So they need lawyers to work on that.
And this costs money, resources.
Another thing that we face is that these licenses we are using are mainly in English available.
So there is only an English version, which is quite hard in Germany because you need a translation into proper German.
But there is no authorized version of the GPL, for example.
And they are all based on US conception of law.
So for example, this copyright thing we have in Germany is completely different in the US.
So you need lawyers to put that into the right thing.
I'm not going to say they are not working.
So we have several projects like gplviolation.org.
They showed in Germany by going to KERD that the licenses work and people understand them.
But it's quite hard to use them.
So in Germany, mainly the software is ordered via tenders.
This is regulated in the procurement law.
And there is something like the E4B IT.
That means they are against the Vertragsbedingung, so Beschaffung von IT, a huge complex thing of terms and conditions and sample contracts.
And one of the things stated there in the E4B IT is the contractor must grant the right of use of the software to the client.
And this is impossible because in open source the recipient gets the right to use out of the license by following the license terms.
So we need special workarounds in that situation.
And the OSPR we have made a kind of a handsheet to support companies doing this.
But it always needs the special negotiation necessary to solve these issues.
And this is also some extra work, something of the price tag I was talking about.
You're here in Belgium and Belgium is famous for its comic strips, so I found this one that I really, really like.
It shows a modern application, any application, probably one of the app store from the talk before.
And you see it's very shiny, complex and very detailed model.
But it's a kind of a building blocks.
This is the way we work.
So we use open source blocks somewhere outside and we recombine them to something new.
And the thing is, each of these components has its own license.
And the problem here is that we cannot say there is a final license for our whole product.
Because when we distribute the software, we distribute all the small packages together.
And at OSPR we also did an examination of a popular video chat solution in the beginning of COVID, we all needed that.
I'm not going to name it, but on the project side it says it used the LGPL, so the GNU Lesser Public License.
And when you install that on your hard disk and you try to examine all the files installed there and figure out all the different license files that we're putting on your hard disk,
you find that it's not LGPL, it's a mixture of different things.
And this tools also the installer downloads fonts from Microsoft, so they have some specific true type fonts.
And in Debian you can download an installer for those.
Then you call the installer and then you have to apply to the Euler from Microsoft and then the download starts.
But here nothing happened, they just appear on your hard disk.
So this is something that you have to take care when dealing with the software.
And this is something, when you think back to the public sector, they're distributed to another legal entity within.
So now they have to fulfill all these license things that are putting in that product.
The main question I cannot answer here is who is responsible for that.
The project that put the installer on their project page, the programmer or the developer that made that installer,
probably the company that made the offer and made the installation work or the admin guy on whose server it's running
or at least later the final entity that is using this application.
So this is the kind of an issue.
And be sure with containers the things are getting worse because then you get a bunch of containers,
everything with its own operating system and also a different bunch of software and a different bunch of licenses integrated.
So we need to answer the question, when we look on a piece of software, what is inside?
Which licenses are used inside?
And then we come to something like a package insert, like for medicine.
And the only way to deal with that is an SBOM, the Software Bill of Materials.
And this should list all the components, all libraries, all modules, all container stuff, everything that's put into the product.
And for the SBOM we need the information about the piece of program, the source, where does it come from, the version and the license.
With the version and the source we can also answer security questions like are we vulnerable for something?
Lock for J, for example, is somewhere Lock for J implemented? Which version do we have to fix that?
And for us, for our legal view on that, we know which licenses are there.
But when we have this bunch of licenses, we are not really done as public sector because now we have to check for our business case.
Are all these licenses compatible? Are they working together?
We have something like copy left that might have an impact, so we have to figure out that situation for a specific business case.
So we still need some people dealing with license compliance stuff.
For the SBOM itself, there are different formats available outside.
The one that's mainly seems to be the most common use so far is the SPDX format, Software Package Data Exchange.
It's maintained by the Linux Foundation and it's the only one that is an ISO certification now.
So this is something that's an ISO standard and then we can use that.
There are tools available out there to convert SBOM from one format to another.
That's mainly text files and different formats.
Jason, for example, and with that, we get a detailed view on all the components that's inside our software delivery.
And for people who are being interested or being a bit afraid,
oh, I have to deliver an SBOM, tomorrow there is a whole deaf room here in Foslem just dealing with this SBOM topic.
But this is something we will probably face in future when we apply for software tenders that we have to deliver an SBOM with our solution.
When we check all those licenses that may be around in the world,
we come to a number of probably 1800 different licenses that may appear in such an SBOM.
So we have 1800 different legal texts that we might have to examine.
OSI has certified 116 of these as being open source.
From my personal point of view, this list is incomplete.
So OSI has set up a kind of a life cycle thing to get rid of licenses that are not common anymore.
So to narrow down this number, so there are probably 500 that may be something like we would accept as open source.
And each of them are different.
So when you're working as a lawyer and you have to check the license situation,
you have to deal with these number of licenses.
But I want to remember you that also the proprietary software uses licenses and EULAS,
and they are mainly much more complex than our open source licenses.
They are sometimes specific for a specific product and they are changed regularly.
So if you use any device, sometimes it pops up, new EULA, you have to accept it.
And I'm pretty sure everybody here in the room checks them carefully,
find out the differences to the last version because they are not kind of red or blue marked,
and accept them afterwards.
With open source, we have the real advantage, the unknown or hidden advantage I called it.
We have the real advantage that our licenses are quite short.
So they are mainly just a couple of pages, sometimes even not that.
I think MIT is something like just a few lines of license code.
And most of them follow a specific pattern.
So they are derived from each other and so you can find a structure inside
and you get a better feeling for what this license is about.
And they are pretty static.
I mentioned the GPL20 before.
That's the license applied onto the Linux kernel.
And the GPL20 is unchanged since June 1991.
So more than 30 years, the same license text.
If I'm working as a lawyer, I'm pretty fine.
I spend one time all my work in that license.
And then the next 30 years, I can work with my customers and support them.
What you also have seen while talking with people in the public sector,
that there are some kind of misconceptions outside.
So these are kind of misunderstandings that probably people told them.
And the first one is there is some people think there's an obligation to publish everything on the Internet.
But this is not written in any license.
The idea of open source is you give somebody a binary piece of software
and then you have to give him the source code of that software.
So if something in the recipient's environment changes,
he can adapt the software on his needs.
He can add new device drivers, he can change the language,
he can add new functionality, whatever.
But the thing is you have to hand over the source code with appropriate rights to work on the source code
to the recipient of a software, not to anybody somewhere on the world.
This is something most of us do because we want to spread our idea,
we want to spread our software, but we don't have to.
This is something important when you go on this.
I think we have another talk today in the military sector.
Where probably parts of the solution must be hidden or must be not being published.
Then you can easily use open source, you can adapt it,
you can give it to another legal entity, but only they have to receive the source code.
You don't have to put a mission control system on the Internet.
But some people are thinking like this is open source, I have to publish everything.
Another thing is like pushing changes back to the community.
I personally really like that idea because then I'm not in charge anymore for my changes
because the community does.
Otherwise with every updated version I have to apply my changes again.
But in fact it's not stated in any license.
It's more like common sense that we do so.
But we don't have to bring the changes back to the community.
This is something like mission control system, missile control system, whatever.
We don't have to.
And then we have, especially with copy left, sometimes the idea of the disclosure of all our source code.
I think it's based in some Microsoft advertisements from 20 years ago
during this Halloween papers, like all GPL this kind of cancer.
This still is in their heads.
No, we don't have to disclose all our source code.
If we accidentally mix GPL into our product, we break the license.
So we are not licensed anymore.
So we cannot ship that solution.
That's a legal problem we have to solve.
But this is not that we, in this moment, we have to ship all our source code.
So these are things that we hear.
And then you'll think like, oh shit, we have to explain them that this is not the case.
It's just normal software that we are dealing with.
And then finally my last slide.
How can a developer improve the situation?
So I said I'm also more a developer guide than an illegal guy.
What we can do is, when we start writing code, I mean, I've wrote already better before,
but normally you start just coding.
When you start working on a new project, you should check the licenses of all the components you want to use for compatibility.
Do we have copy left? Does that all work and fit together what we are doing?
And also in the plan business case that the company I'm working for or the client I'm working for is going to use.
Especially for standard components, when you think of that picture I showed you before, this strip thing,
there was one small block on the right-hand side.
If this breaks, it all falls apart.
And this seems to be a very fundamental piece of that solution.
So it's probably not that easy to change.
We should start building S-bombs to check what's inside in our product.
That's also something that the security guys are asking.
In the US there is something like the supply chain thing.
There was presidential advice on how to secure the digital supply chain.
And S-bombs is a very important part in that.
So I personally assume that we have to deliver S-bombs in public sector projects
and that developers are starting building S-bombs.
And when you think of that picture I showed you,
when every community of these building blocks made an S-bomb for their product,
we can iteratively use all these S-bombs together for the final product.
So this is something that will probably start to work from automatically, I think.
But you should, for your own project, start writing S-bombs.
And the best way is to build that into your build process.
So that's created automatically and updated with every update that you ship.
So that you always have a fresh S-bomb.
I told you there is the software version included.
So you have to use that for dealing with security issues.
Avoid exotic licenses.
There are some interesting licenses around, like, for example, like the BIA license.
It's probably not a very good idea to try to find a very exotic license that nobody else uses
because it makes the work for the lawyers much more complicated.
And at the end, when you apply for such a tender,
and it's not a specific solution that must be built in open source,
but it's a tender for any software solution,
and you are just one person offering an open source solution against proprietary solutions.
They have to check what kind of work do we have afterwards,
does it fulfill our needs, and then they make a choice.
And when your thing is way too complex and they are mainly working lawyers on that level,
then probably they choose something else.
I put in brackets. Avoid, if possible, try to reduce the pile of different use licenses.
I know this is very hard because you cannot change the licenses of all the pieces that you need.
But going back to OSI, I said they treat 116 as open source licenses.
They already started to narrow down their number of licenses.
They put on their website.
And on their website, they have, I think, five popular licenses that they recommend.
This is something that you can probably try to follow.
And the last thing is a question to you.
Do you know the EUPL? That's the European Union Public License.
It's a copy-left license.
And the cool thing on that is it's available in every European language, natively.
So in Germany, we can pick the German version of the EUPL and use that for licensing.
And then we have a German text. And if we go to German court, we have then German license text.
In Italy, it's the same. It's an Italian version, a French version.
And they are all comparable.
Thank you.
I think we can take one or two questions. Anyone of you? Who's the first one? Okay.
Hi, thank you.
I really appreciate that you've identified a problem in software procurement with the public sector.
And I see that you're making really useful suggestions.
My question is, is the demand from the public sector to do these things?
Or are you proactively making these suggestions?
Does the public sector understand that these are challenges in procurement?
Or what is the situation from the other side? Thank you.
So does the public sector understand the demand for open source, something like that?
So it depends a bit to whom you are talking.
As I said in this coalition contract, on very top level, they say we want to do open source.
And then it goes down. And then there are people that probably got the order.
We have to order open source stuff. What is that?
And then they probably make a tender. And sometimes you have a complete new thing that should be built.
Then they probably put the tag open source or it has to be open source on that.
And if they just go for any software, like a video chat solution, then they should be open.
And then it depends on the person if they know what open source is and if they know it the right way.