We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

How to get public administrations to use more FOSS

00:00

Formal Metadata

Title
How to get public administrations to use more FOSS
Title of Series
Number of Parts
542
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The strength of FOSS lies in their corresponding licenses. Public administrations however sometimes have a hard time wrapping their heads around the specifics of FOSS licenses although they more and more understand the advantages. In this talk we want to illustrate the underlying reasons for the existing problems and present ideas how the procurement of FOSS can be improved and made easier for all those involved. We combine this with an outlook to the impending changes and developments with regard to the public procurement of FOSS in Germany. When procuring software the German administration usually works with standardized model contracts (the so-called EVB-IT) which are not ideally designed for the procurement of FOSS. In 2022 members of the Open Source Business Alliance performed a number of workshops with the German Ministry of Interior that maintains the EVB-IT in order to remove existing barriers and to eventually reform these standardized model contracts. Additionally a survey among members of the Open Source Business Alliance revealed typical recurring practical problems that companies face when offering Open Source Software or corresponding services to public administrations.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Local GroupBuildingBlock (periodic table)Open sourceFundamental theorem of algebraDigital signalSoftwareCoalitionMaxima and minimaNumberArchaeological field surveyDigital rights managementDesign by contractObservational studyRevision controlDistribution (mathematics)Source codeComputer programCondition numberTerm (mathematics)Client (computing)Sample (statistics)Term (mathematics)Group actionOpen sourceSoftwareInstallation artFlow separationProjective planeSoftware developerCoalitionServer (computing)Computer programSelf-organizationTelecommunicationCASE <Informatik>LoginPhysical lawBuildingCondition numberRight angleClient (computing)NumberSampling (statistics)Distribution (mathematics)Modal logicDesign by contractBitDigital rights managementTable (information)ResultantMereologyTranslation (relic)Complex (psychology)Revision controlSource codeProper mapSanitary sewerPower (physics)Computer hardwareOpen setComputer animation
Condition numberTerm (mathematics)Client (computing)Open sourceSample (statistics)SoftwareDigital signalComplex (psychology)Product (business)VideoconferencingState of matterWebsiteComponent-based software engineeringModule (mathematics)Library (computing)Different (Kate Ryan album)File formatInformationRevision controlLatent heatWeb pageRegular graphDifferent (Kate Ryan album)CASE <Informatik>Public key certificateProduct (business)Endliche ModelltheorieOpen sourceLine (geometry)File formatVideoconferencingComputer fileBlock (periodic table)Mixture modelInformationProjective planeView (database)Multiplication signInstallation artBitPoint (geometry)Hard disk driveType theoryElectronic mailing listComputer fontSoftwareRevision controlData structureLatent heatPattern languageMobile appComputer programModulare ProgrammierungServer (computing)BuildingSoftware developerSystem administratorOperator (mathematics)Information securityNumberComponent-based software engineeringData storage deviceComputer animation
Statement (computer science)InternetworkingCodeLine (geometry)Open sourceComponent-based software engineeringSoftware developerInformation securitySource codeProduct (business)Projective planeSoftwareDisk read-and-write headPlanningLevel (video gaming)WebsiteCASE <Informatik>Software developerFormal languageOpen sourceRevision controlChainInternetworkingComponent-based software engineeringMereologyClient (computing)Right angleBlock (periodic table)Different (Kate Ryan album)Integrated development environmentMathematicsNumberDigitizingGame controllerProcess (computing)BuildingSlide ruleControl systemComputer animation
BitOpen sourceLevel (video gaming)Online chatSoftwareDesign by contractCoalitionOrder (biology)VideoconferencingComputer animation
Program flowchart
Transcript: English(auto-generated)
Happy to introduce our next speaker, Klaus Wittenhot. 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 SUSI, Red Hat or telecom
but also smaller companies like Lino Data whom I'm working for. And within the OSPR we have several working groups and I'm the spokesman of the working group Bechaffung, 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 talking with people about it. I've had a disclaimer, so this is not legal advice.
I have an engineer's degree, I'm more kind of a developer and I just came a bit by accident into this world. So this is not 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 FOSDEM before Corona and then just a few weeks later the streets were empty
because there was the lockdown. Then we had a FOSDEM completely virtually. That was very strange because you were sitting relaxed with coffee and everything at home, but you're missing the atmosphere, the people aren't there. We had Ever Given got stuck in the sewers 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 that to handle on their own will.
So in the actual coalition agreement from the German Federal Government, there's 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.
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.
And so at OSPI 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 this 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 GPL2O.
You make copy and redistribute verbatim copies of the program's source code as you receive it in any medium provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and this claim of 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. So 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're producing cars or they are bakeries. So then they're 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 of several legal entities.
And then one entity 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's 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 Kurt 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 procurement law. And there is something like the E4BIT. That means the against-the-for-trax-be-ding-un-so-be-chaf-ung-fon-IT, a huge complex thing of terms and conditions and sample contracts. And one of the things stated there in the E4BIT is the contractor must grant a 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 hand sheet 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 these tools also, the installer downloads fonts from Microsoft. So they have some specific tool 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 of when dealing with this software. And this is something,
when you think back to the public sector, they 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 a 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? Log4j, for example, is somewhere Log4j 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 Copyleft 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 compliant stuff. For the SBOM itself, there are different formats available outside. The one that 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 in different formats, JSON, 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's a whole death room here on FOSDEM just dealing with this SBOM topic. So 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 1,800 different licenses that may appear in such an SBOM. So we have 1,800 different legal texts that we might have to examine. OSE has certified 116 of these as being open source.
From my personal point of view, this list is incomplete. So OSE has set up a kind of a lifecycle 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 OILAs, 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 OILA, 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 GPL2O before. That's the license applied onto the Linux kernel, and the GPL2O 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 we also have seen while talking with people
in the public sector that there are some kind of misconceptions outside. So this is a kind of misunderstandings that probably people told them. And the first one 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 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 in 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 copyleft, 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 these 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 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 guy than an illegal guy. What we can do is when we start writing code, I mean, I 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 planned 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 think of,
we shouldn't think, 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-bomb 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 everybody of these, 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 update it with every update that you ship so that you always have a fresh S-bomb. I told you there is the license, the software version included so you have to use that for dealing with security issues.
Avoid exotic licenses. There are some interesting licenses around for example like the beer 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 an antenna for any software solution and you are just one person giving, 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 OC, 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. So this is something that you can probably try to follow.
And the last thing is a question to you. Do you know the AUPL? That's the European Union Public License. It's a copyleft 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 UPL
and use that for licensing. And then we have a German text and if you 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.
Is that true? I think we can take one or two questions. Yes, sure. Who's the first one? Okay. We have a winner. 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 like 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 you think like 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 and then they just 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.