Episode 882 transcript

2026-09-15

Jonathan: [00:00:00] time for Floss Weekly. That's the show about free Libre and open-source software. I'm your host, Jonathan Bennett, and today we're talking about, well, open-source, of course. We're talking open-source automation and some experts in that field. I've got Jan Altenberg with me, and he is, I discovered during the pre-show, a German engineer working on, well, a lot of different things, all the way from the pre-empt real-time kernels to being around computers since the 1980s.

He started with a Commodore VC-20, the ever-present VIC-20, one of, I don't, I think the Commodore 64 actually holds the record, but the VIC-20 has to be one of the most popular computers ever sold. But yeah, we're talking open-source, we're talking automation, and let's bring the man himself on. Jan, welcome to the show.

Jan: Thanks for having me. Great to be here. Great. Looking forward to talk about open source [00:01:00] today. As you mentioned, I've been working with computers for quite some years. Actually, I have to admit that I was not working with Commodore. This was my colleague I'm working with at OSADEL. But actually, for me, it's even more than, I would say, I've spent 35 years with computers. The drawback was that my first computer was running proprietary software, which was pretty sad, but I think I'm with open source since 30 years now.

Jonathan: Yeah, yeah, that's a long time. Yeah, I see now that it was Alex, your colleague, that started with the Commodore VIC-20, but still, you've been around, you've been doing this for a while. We were talking before the show about how this interview came together, and I'm pretty sure that it's from where I was at Embedded World earlier in the year.

And I took one of the days, and I went to the software wing, because they have like five different halls at Embedded World, because it's a huge show. And I went to the software wing, and I just walked around, and I looked for anything [00:02:00] that had "open source" in the title or that I knew was an open source project.

I'm like, "Here's my business card. You should come be on the podcast." And so we finally made this one work, talking about the Open Source Automation Developer Lab. Now, what is open source automation in this context? Are we going to be a very AI-heavy episode again today? Is that the sort of automation that we're talking about?

Jan: Oh, well. So, AI is everywhere these days, but maybe it's a bit different for us. So, what is the Open Source Automation Development Lab? As the name says, we do a lot of with open source and automation. So, we are around since a bit more than 20 years, actually. What is interesting for you to know is, I mean, as you mentioned at Embedded World, there's many different companies, right, doing software, doing open source. So, we actually, we do not have the legal form of a company, actually. [00:03:00] So, we are a registered German cooperative.

Jonathan: Okay.

Jan: So, that works a bit different. So, it's actually that we are owned by our members, So, we do not have a single owner, and we don't really primarily operate profit-oriented, so the thing what people do is, with a cooperative, they gather in a place and put some budget together to do something useful in common interest, right? So, in Central Europe, this is pretty common, for example, for small wine producers, so you might have everything to do the wine, but you do not, cannot maintain as a small company all the infrastructure to sell the wine and do all the production and the bottling and that stuff, and that's why wine producers gather in a cooperative, so they could finance that infrastructure together.

And what happens at OSADL is that our members do the very same for open source in industrial products. So, our members [00:04:00] have the interest of using open source in industrial products, mainly in automation, but in other products as well, right? And the reason why we were founded roughly 20 years ago was basically real-time Linux. Which was around at that time, in the early 2000s, and it was proven to work.

So, it became of interest for German machine producers, so it rang the interest of many engineers in Germany. But the question for the deciders was: this is a young project, right? So, will the maintainers continue that work? Who can help us with quality assurance, and who to ask, right? And this is why these companies founded OSADEL back then, to, like, provide funding to the real-time maintainers and to do commonly funded quality assurance for real-time Linux. So, this was the main idea.

With 10 members back then, so today we have more than 100, and, of course, over the last [00:05:00] 20 years, the interest of our members grew into a different direction, and yes, AI as well. But many different topics, like even licensing topics, that are of common interest, are covered by our community. So, just to sum it briefly up, we're pretty much a community that supports its members in using open source in their products.

Jonathan: Gotcha. The story with Realtime Linux has been pretty interesting, too, over the years, because that was a pretty big change to the Linux kernel, and it's something I've been watching and been sort of excited about for a long time, mainly because I do some Realtime Audio stuff.

Jan: Yes.

Jonathan: And, you know, I remember way back in the day trying to, you know, I was doing crazy things like running live sound through a Linux machine to be able to use plug-ins on the live sound, and it's like, you've got to get your latency down as low as possible, and, you know, we were trying to pull out all the stops and figure out how to do that, and the Realtime kernel [00:06:00] was one of the ways to do it.

And I remember trying it one time, and it immediately crashed the machine, because we had to use the NVIDIA driver on that machine. They just, they did not work. They just, they did not play nicely together at all. We've come quite a ways now that, I mean, it's landed in the upstream kernel and everything.

Jan: Exactly. Yes.

Jonathan: Yeah, how much of that story were you involved in?

Jan: Pretty much the whole story, actually, pretty much the whole story, because that was the topic that really got me into open source, right?

Jonathan: Huh?

Jan: So, I got my first Linux installation when I was 15, but that was just like out of interest, wanted to try things out, and the cool stuff about open source was that I could look into stuff and figure out how it was working. But what happened in my studies is that back then I was working for a machine producer and doing my thesis, and they were evaluating Linux as the next generation operating system, and I was in charge to look into real-time Linux.

So, back then in 2004, [00:07:00] I started doing my thesis on real-time Linux and porting machine controllers to real-time Linux, and since then I've been following the whole history. of real-time Linux supporting people using real-time, helping people with testing, evaluating new use cases. So all over these 20 years, this was a big topic for me. It was always a pleasure for me to present on conferences about real-time Linux.

So at some point I really got passionate about that. So really one of my favorite topics. And you can imagine that the very day when the pull request got merged, enabling preempt RT in the mainline kernel was a very, very special moment for me. And it actually happened pretty much exactly 20 years after I submitted my thesis for review.

So it was quite some time.

Jonathan: Ha-ha-ha-ha-ha-ha-ha!

Jan: So I really still, I think the maintainers can be really proud. It was a very [00:08:00] big change. And I think you mentioned a very interesting aspect because I mean, having this in the mainline kernel is great, but just look at all the things that happened over these 20 years because, Like you mentioned, you enable real-time and drivers start crashing.

Because you didn't have proper locking or something, some serialization did not work, but, I mean, you immediately discover that when you have full preemption, right? So, I think there was a big quality jump for many drivers in the Linux kernel with real-time, and apart from that, I mean, just look at the tracing infrastructure, the high-resolution timers, generic interrupt handling, and so on, and so on.

All these nice features, threaded interrupts, all these features are there because they came from the real-time development, and I think it's, for me, it's always a very good example on which synergies you can have with open source, right? Because people develop the real-time for a specific [00:09:00] use case or specific use cases, but they made Linux better for each and anyone, right?

I think it's one of the best examples you could have on how open source works. really helps you saving efforts.

Jonathan: Yeah. There's a sort of parallel, something that I just became aware of here recently. So, the real-time effort, is it fair to say that part of the reason for that was to be able to use Linux in automotive cases?

Jan: Partly, partly. So, I think the first heavy use cases was automation, was even big server machines that did high-speed trading and stuff, so they had to do deterministic calculations and stuff, so these were the first early use cases on that, and that maybe was the enabler to slowly push it also towards automotive.

Jonathan: So, I was at a talk in London, and I think it was [00:10:00] an NVIDIA engineer, interestingly enough, but he was looking at the question about using Linux and automotive and doing safety engineering around the Linux kernel.

Jan: Yes, yes, that's a big topic, yeah.

Jonathan: And the things that he was describing that would have to be changed in the Linux kernel, I was sitting there going, "my goodness, this is a lot of work for, you know, just to..."

Jan: Yep, yes.

Jonathan: I am always a little skeptical, this is just me, but I'm always a little skeptical of some of these, like, engineering-proof things, like, we can make the kernel safe by doing this, and I'm like, I mean, it's kind of like moving code to Rust, right? Like, yes, you can fix this class of memory bugs, but you also have this other class of bugs that Rust doesn't help you with at all, and so I was sitting here listening to this presentation going, "This doesn't necessarily guarantee that it's not going to crash." But all that to say, I see an interesting parallel between the 20 [00:11:00] years that it took to get real-time into the kernel, and now this sort of growing interest in getting

Memory safety, but also, like, you know, big iron engineering safety, or I forget even the term that they use, but the amount of changes that that would take to land that in the kernel. Is that something you guys are involved in at all?

Jan: Yes, actually, so we're still following that.

Jonathan: I'm not surprised.

Jan: We do that for 20 years now. Actually, we've been actively involved in safety efforts for the Linux kernel. So, we did run quite some time ago, we ran a project which was called CO2LinuxMP, which was actually looking into what could be proper strategies to get safety certification for Linux-based systems. So, we built some know-how in that area, and as you say, this is maybe still a different story than real-time, because that effort is definitely huge.

[00:12:00] And we're still a bit involved in the ongoing efforts. For example, there's the ELISA project going on. People still look into methodologies. So, the interesting part of all the efforts that are still around there is not that someone is looking into getting specifically a certification, right? The thing is, what would be the proper mindset? What might be the tools and strategies? Because if you take an operating system like Linux, right, it hasn't been developed following a specific process, right?

So, it hasn't been developed following a safety standard. So, what routes you could take, you need to see what route to take Using something existing and prove that you can make it safe, right? And this is pretty much what all these people are these days looking into. How can you adjust the development process? How can you prove that things are good? How can you improve? How can you do documentation so that in future it might [00:13:00] be easier to get that kind of certification?

Because I'm quite sure, or I am sure, I'm aware that certified open source systems are around on the market, right? The question is just, in this case, it was always very individual effort, but can we make this the common case? And I think this is the next big step for industry. So, the first big round for industry was, okay, they need real time, and the next big question is, can you get safety certification?

Jonathan: interesting to watch. Do you think it's going to take another 20 years?

Jan: Well, I gave up doing estimations, right? I did do quite a few estimations for real-time Linux, right, and at some point, we always kept saying next year because there's, of course, always a next year, right?

Jonathan: Right, right, right.

Jan: So, I don't want to do estimation there. I can say I am confident that this [00:14:00] can happen because so many companies are looking into that way. And open source became of interest for many different industries because they are independent in their decisions, and maybe also for security reasons because the software they have is just open and transparent.

Jonathan: Mm-hmm.

Jan: So, I am confident that there will be ways, but it's hard to estimate how long that will take. It will definitely be a way bigger effort than just getting real-time into Linux.

Jonathan: Sure. Europe is kind of making a move as a whole, even due to some regulatory pressure, I think, towards open source solutions, specifically away from Closed source solutions coming from U.S. companies. I think that's part of it, but I see it as sort of a bigger trend just away from proprietary solutions and towards open source solutions, which I love.

I think that's great, and [00:15:00] I think every country should be thinking about that. It absolutely makes sense to me.

Jan: Yeah, I think there's two aspects on that. So, definitely, there's a European strategy on getting more independent when it comes to software, so there's a European strategy in looking into open source and trying also to push countries to move open source. So, this is an effort I really appreciate. There was actually recently also the possibility to submit ideas and arguments to the European Commission on what do we need for European open source strategy.

So, even the European Commission is looking for feedback, so each and anyone was possible to submit. So, this is one thing. So, there is a strategy there. If you look into that from an engineering perspective, I think, this is something that arrived on the market quite earlier, [00:16:00] before we had that strategy coming up from regulatory side. It's like that, I mean, sooner or later, you realize that, I mean, just imagine you're building So, what happens with proprietary software very regularly, and I've been through that, you need to do updates because Well, you don't get support anymore for the old version, so you need to rework a lot of stuff without any real need, right?

So, this is a pressure and a burden you basically don't have with open source, so you have way more flexibility. It's basically up to you what you use. Of course, you need to update, you need to maintain. But, I mean, you can look into the software, you can do it on your own, and you can decide who can support you, right?

There's [00:17:00] so many brilliant minds, so the thing is you're not bound to a single entity, right? So, it's still work to do, but you become way more independent, so this is one aspect to avoid these. There are artificial release cycles that you don't really need, right? So, and the other thing is just when you debug real-time topics.

So, when you're with proprietary systems, you usually always get to the point where you see, okay, data is going in and gets back too late. So, you can open a ticket and that's it.

Jonathan: It's difficult to try to troubleshoot the inside of the black box.

Jan: So, if you're using real-time Linux or anything else, or Zephyr or something that is open source, you can just see what happens, right?

Exactly, exactly.

Jonathan: In the past, probably 10 years, I've had a couple of times now, people have come to me with, in one case, it was a Windows 3.1 machine, [00:18:00] in the other case, it was a Windows 3.1, I think one Windows 95, and one Windows 98 machine, and they've all come to me and gone, "This is incredibly important for our business use case. Please make it continue to work."

DOSBox to the rescue, by the way, is an incredible piece of software for making that happen, but yeah, it's ridiculous.

Jan: Yes.

Jonathan: You see these businesses that are locked into their old solution, whether it be for hardware or for some old piece of software that nobody has the source code to anymore. It's incredible, and I've seen it several times, yeah.

Jan: That's it, yeah. And I think that was a very good example, because the fun fact here is, in many cases, open source emulators save proprietary software, right? Because you can still run it, [00:19:00] right?

Jonathan: Mm-hmm. One more time that this happened to me, it was a doctor's office, and they had their old back-office system running on an old SCO Unix box. And they were like, we need to be able to fix this, keep it working, and get backups from it. And this has been, again, probably 10 years ago. And I said, okay, I can do that. And I did Fedora install and set up QEMU and virtualized their old SCO UNIX box and got it working.

Which is interesting, because the SCO UNIX lawsuit was in the news one more time in the past couple of weeks, which is what brought that to mind.

Jan: *laughter*

Jonathan: But yeah, it's a problem all over the place of people getting themselves locked into these ancient systems.

Jan: Exactly, but I think people started to learn from that once again. I think that message arrived, and people start rethinking, so we can see that over the last 20 years, now after 20 years of using open source, I was at the position where I thought, okay, now all industries should be aware about open source. There's still nowadays, still industries, still now switching from proprietary systems to open source.

[00:20:00] Even these days.

Jonathan: Yeah. What are some of the other projects that the lab is involved in? We've talked about real-time Linux and the safety-critical stuff, but I'm sure there's some other things that you guys have your hands in.

Jan: Of course, there's many. So, we could talk days. Now that Alex wasn't able to join us, I should briefly mention Alex's work, which is closely related to real-time Linux, but not only just related. So, I mentioned that one of the reasons why Ozan was founded was quality assurance. So, what we do is, we do run quality assurance for more than 200 embedded systems in our lab.

So, these boards do come from our members, or we choose them on our own, but basically they do come from our members, and they want to see how stable are these boards operating 24/7. Of course, real-time behavior is one topic we look into there, because the [00:21:00] thing is basically that with operating systems like Linux running on modern processes, It's not that easy to prove the real-time behavior. In the good old times, you just did a code path analysis, and with old processes like M68K, you exactly knew, "I have this number of assembly instructions, and it will take that time to execute."

Now, estimating the execution time on a modern processor is close to impossible. So, you have at least two or three caching levels. You have branch prediction. You have SMIs. You have microcode patches, and so on, and so on. So, the only thing what you could do is to evaluate and to collect as much data as possible. This is what we basically do at the QA farm. So we do latency measurements 24/7 under different load scenarios, and we collect all the results of the measurement runs and render long-term plots that our members [00:22:00] could even spot single latency spikes that happen once a month or once a year.

So we put some patches on top with the layer tracing infrastructure that we could easily spot when a latency happened and who was the culprit and so on. So this is one intention. On the other side, we do health monitoring like we monitor CPU load, temperature, fans, whatever, to track the stability, and you find really interesting stuff when you're monitoring embedded boards, like doing random reboots that a user in the field won't even realize because it's fast enough, right? But just simply monitoring the uptime of a device can give you interesting results.

And one of the fun facts is actually that work is maintained by Alex. So, you can imagine that with 200 boards in the farm, he needs good running shoes, because something is breaking every minute, so you need to do spare parts there. So, the fun fact is [00:23:00] that one of the most breaking parts for most of the boards is just the power supply, which is, you know,

Jonathan: That checks out. Yeah.

Jan: Yeah. The bad thing about breaking power supply is that it's not binary. So if it would just break and the board would be switched off, that would be nice. The thing is that you end up with random behavior on the board, like random resets, random kernel crashes. So the basic thing we always do is when we end up with random behavior from one day to the other, first thing we do, we check the power supply. So this was one of the 20-year fun facts of quality assurance. So this is maybe one of the

Bigger technical projects we are running.

Jonathan: We love technical geeky stuff, by the way.

Jan: What I need to mention as well is, so there's a lot of technical geeky stuff we do, right? But there's also quite a few legal geeky stuff we do as well, because this might be something [00:24:00] that didn't happen that much so far: we tried to extend the open source principle to as many topics as we could, because, I mean, we're a community trying to finance things together in the area of open source.

And it turned out that most of our members, most of the companies that gathered at OSADE, do have the same legal questions over and over again, because all of them are using open source in their products. So, most importantly, they need to understand license obligations, so what do they need to do when they copy and distribute, do they need to provide source code, yes or no, what else do they need to do.

Also, sometimes license obligations might collide even with regulations. Imagine, like, you have installation obligations with the GPL, but due to some regulations, you might need to implement a secure boot on your device. How do you bring that together? So, what we did is basically we established a community-based legal consultancy, [00:25:00] so we did a legal FAQ database. And it pretty much works in an open source sense, so when one of our members comes up with a legal question, That member could hire a lawyer, but in this case, that member would address that question to us, we hire the lawyer, the lawyer gets that question answered, and question and answer make it to the database and are accessible to all of the members.

So, that with a very low financial effort, our members get that, yeah, that community synergies, and that the cool thing is that it's not just these questions, so whenever you have a question, our members could log in and check what has been asked in sense of legal topics and open source before, and maybe that question was already answered in the past before.

So, this is a pretty nice example on how you could also do community-based work even on legal topics, because there's so much overlap for people using [00:26:00] open source in their products, so it completely made sense for us to share that efforts between different people. One of our really important assets, we even started open-source projects in the legal part.

So, we have one open-source project we are running is the open-source license checklists. So, the thing with open-source licensing is, the great stuff is, if something is officially open-source, you always know your freedoms, what you are allowed to do. So, this is great. So, the difference between open-source licenses is basically the obligations that you have when you copy and distribute, right?

So, we have permissive licenses that only require, provide copyright notices and license text. We have copyleft licenses that have licensing obligations as well, or source code disclosure. The problem is that we all know in the open source world, Since everyone needs to invent [00:27:00] his own open source license at least once in a lifetime,

Jonathan: I wish you were wrong.

Jan: there seems to be a rule about that. Yes, I would wish so, too. But that was the reason why we invented the license checklist, because you have this huge variety of different licenses. It's sometimes hard for companies to derive obligations for their product, because they would need to read all the licenses, and the licenses have been written at different times by different people, by engineers, by lawyers, so sometimes it's really hard to understand. And what we started to do is we started translating the most commonly used open source licenses into a canonical language.

So, it would basically read like, you must provide copyright notice, you must provide license text, you must provide source code, or you must either provide source code or provide a written offer, if we take the example of the GPL. So, all that data is Creative Commons [00:28:00] licensed,

Jonathan: Right.

Jan: so you can just download it from Mozilla and use it. So, I think it's quite widely used It's an open source checklist project. I think it's also a very good example on how you could look into legal topics together, right? So, people could send us checklists. If someone needs a checklist, we can do it, right? So, we tried to help out with that, and what we even included is that with the checklist, we even have a matrix that could tell you the compatibility between the licenses. So, can you take BSD2 and

and redistribute it under GPL2 or the other way around.

Jonathan: Right.

Jan: This is also important tooling. Just think about package maintainers and distributions. When they need to check, okay, these are the libraries I'm linking against, so are the libraries, is the licensing compatible? This is basically where you could use the compatibility matrix. So, it's [00:29:00] open source. You can just download it, several formats. It's JSON, and of course, we always highly appreciate the feedback on that.

So, just a few examples on what else we are doing at Dozal.

Jonathan: Yeah. I'm curious: with that tool, can you feed it a software bill of materials and get it to essentially analyze it and tell you if you've got problems and what the license needs to be at the end?

Jan: Yes, basically, yes. Yeah, basically, yes. So, we know even from some commercial tools, once again, that open source is supporting commercial tooling, that they have a bill of material, and they know the licenses, and maybe the use case behind, and then you could use the checklist to automatically kind of half-automated derive the possible obligations you would have in copy and distribute.

Exactly this is something you would be able to do with that. So, now, SBOM was a very good keyword, because there's, of course, more open [00:30:00] source projects we are financing. So, I think that the biggest one we are currently running is the Ocelot. So, and this brings us to the topic of bill of material. So, what was the idea with Ocelot is basically that when companies are copying and distributing open source, of course, they would scan the source code and identify the licenses and extract all the license-relevant information, right? So, the thinking with Ocelot is all companies, all people all over the world do this work over and over again.

For exactly the same software. I mean, that doesn't make any sense at all. So, we make it open source to share the technical effort. So, why not also sharing the licensing effort? So, what we started doing is providing an open source project. Where you could share ready-to-use license compliance material for commonly used open-source packages, like for Bash, or for glibc, for the Linux kernel, [00:31:00] for BusyBox.

So, right now, with a strong focus on embedded Linux, but not necessarily, so it's open-source, it's on GitHub. You can, if you want to provide data, you can just open a pull request. There's a wiki, wiki.osalot.org, so if you want to learn how to contribute, Everything is there. So, this is, yeah, when it comes to the topic of bill of materials.

Jonathan: Yeah, I have said for a long time that, so one of the things that we've seen that happens is a company wants to use an open source project, and they don't have their SBOM put together, and so the company will say, "Hey, we need you to write an SBOM for us." And, of course, most open source projects go, "We, that wasn't on our radar, and we don't have someone that's volunteered to do that." And I've said for the longest time, "No, no, no, here's the answer you need to give. Yes, we will be glad to do that for you. Here is our hourly fee."

Because the law is beginning to require some of these boxes get checked, there's [00:32:00] work that needs to be done inside the open source project, and there are companies that really, really want to be able to use these open source projects, and it's absolutely natural that there's some, to use a legal term, some consideration that flows back and forth to make that happen.

And it kind of sounds like that OSATL is sort of trying to make that flow happen. Is that part of what you're doing?

Jan: Yes, that's part of what we are doing. So, we're trying to make that flow happen, or maybe as a starting point to make that flow easier, right? Because exactly the situation you mentioned, I mean, there's some lawyer reviewing a delivery that contains open source, and he needs some information which is not present in the SBOM. So, the other party needs to prepare that material, put it together, and this is exactly the kind of work we want to reuse, right? I mean, in the ideal case, We [00:33:00] would like to be able to push that back to the open-source projects, right? So, they have that data ready, and what happens today is, of course, when you start reviewing such a project, of course, with, I mean, if you have projects like gLibc or the Linux kernel or whatever that have a long history, you will find some issues with improper licensing or something that is unclear, which is just in the nature.

So, an Ocelot contributor would just contact the maintainers and address that and clarify that question, so they could even fix it in the next release and make it clear, right? So, but yeah, this is pretty much what we wanted to address with the Ocelot. It's still growing, of course. It's also a huge effort, but I think we are at a very good starting point with that.

Jonathan: Yeah. The members of OSATL, are they primarily like the businesses that are using the open source project, or do you have projects themselves [00:34:00] as members?

Jan: Well, we have different membership levels. So, for regular membership, it's pretty much the, I would say, the uses of open source that need support on how to properly use open source, how to evaluate, how to, or even they, I mean, they want to be good open source citizens and with us help funding the open source community. But we also have partner memberships. We have partner organizations where we work together with other open source organizations. So, we give each other more visibility or support each other.

So, for example, we have, I mean, of course, Linux Foundation is one of our partners, Eclipse Foundation. One of our recent partners is the Erlang Ecosystem Foundation. So, we work together with other open source communities. We also have associate members that could be one-people [00:35:00] companies doing open source. They can also become a member, profit from our benefits, and it's also good for us so we can get in touch with our industrial members, and we could get them in touch with people doing open source and doing a bit of networking, right?

But basically, most of the regular members are mostly the users of open source that are interested in having the ecosystem in a good shape.

Jonathan: Yeah, absolutely, it makes sense. There's something that I've started seeing in some of the open source and industrial work that I do, it's this weird, and I know why people are doing it, but essentially people are trying to use AI as an escape hatch to get away from the GPL. And one of the first places that I saw this, there was a, it was satire, but it was one of those "haha, only serious" [00:36:00] sort of moments, so it was a website that was offering...

Copyright escaped as a service, and so they described this whole thing as like, we will have one AI agent read your code and generate a specification, and then we will have a second AI agent take that specification and re-implement the code, therefore breaking the copyright claim. And of course, you know, it was satire, so it was like, why should those open source engineers get paid for any of their work?

You should be able to take this for yourself. But at the same time, you know, it's like, That's seriously gonna be a thing, and we have seen people now start doing this: "Hey, I took your" - in our case, it's protobuffs - "I took your GPL protobuffs and fed it to the AI, and it gave me this not-GPL protobuff that is essentially the same thing, but the AI says that it's clean-roomed." It's like, I don't think this is how this works, guys, but there, you know, people are out there trying to do it. Is that sort of something that is on your radar? Have you guys seen that, maybe, class of problems?

Jan: [00:37:00] Of course, it is of on our radar, and of course, I don't like it. I mean, it became kind of a concern, right? Because the thing is that what I always teach people when we When I tell about open source licensing is that the open source ecosystem stays strong as long as we have enough projects with the copy left there, because it forces us to share stuff, right?

But it's easy to explain, because when people know how to use open source, they sooner or later learn that they get a lot of People benefit from that sharing, right? So, all the value from the ecosystem comes from the fact that we are all sharing work, right? Now, this movement pretty much endangers that a bit, that people go back and try to get rid of copyleft-based licenses.

I don't think that they will survive [00:38:00] long, but that's just my feeling, because at the end of the day, they are just destroying an ecosystem they are also relying on, right? Um, because at the end of the day today, I mean, it's almost impossible to. To come up with a complex product without using any open source at all, right?

So, if you come up with strategies that target the open source principle, and the principle of sharing stuff, I mean, at the end of the day, you're bombing your own business, right? So, that's my own opinion on that, but still, it concerns me that this is a topic which is coming up more and more frequently.

Jonathan: Mm-hmm.

Jan: I don't really have an estimation how long that will take, but still I have the personal feeling that they will fail, but that's just my feeling.

Jonathan: I've... Yeah, I've actually asked a few people, and I've not gotten a satisfactory answer yet, but I've asked people, like, is there a GPL4 [00:39:00] in the works that is going to address AI stuff? And so far, the answer is no, and I'm slightly terrified by that, because that definitely needs to be a thing. If you're listening to me out there, Free Software Foundation, get on it.

It's a thing we need. I'm honestly not sure though how that will get addressed, and one of the problems is that copyright law has not caught up to AI yet, and so we're all sort of operating together in this gray zone of like, what does it mean to train an AI on copyrighted works? What does it mean for an AI to generate something?

You know, I was told by one guy, I happened to sit next to a comic artist on a flight a few months ago, and I'm like, "Hey, do you guys use AI?" He goes, "No, because we can't copyright anything that comes out of the AI."

Jan: Exactly. Exactly. Yeah. So, this is one of the topics. I mean, [00:40:00] copyright law only protects what is created by a human, right? So, if it's not created by a human, it's not protectable under copyright law. So, this is one aspect. But I think the continuous gray zone for companies is basically, I mean, On one hand, you can claim what comes out of an AI code generator is not protectable by copyright law, but as you mentioned, it has been trained by something.

Do I have any guarantee that there's no significant portion of training material going into the generated code, right? I mean, that's kind of the gray zone. No one can give me an answer these days, and that's all the gray zone you have with AI.

Jonathan: Yeah, I remember one of the--and this has been several months, maybe over a year ago even--but Copilot was getting very popular, and people were basically manipulating Copilot to give out large blocks [00:41:00] of code that were completely unchanged. And, you know, that was pretty obviously a copyright problem. It was real hard to argue that it was a transformational work when, you know, you were getting entire source code files just coming out, byte for byte, unchanged.

Jan: Yeah, so, I mean, there's, like, with everything, now, finally, we're at the AI topic. So, the

Jonathan: Take

drink.

Jan: I mean, there's several sides of the coin. So, there's all the critical aspects. I mean, we end up with a simple copyright gray zone. So, I mean, this is something we most probably can resolve. The other aspects that became a burden, and this has been most probably discussed before many times, is the burden for open source communities that maintainers are drowning in AI slop.

But also, we see the, I mean, [00:42:00] the huge amount of vulnerabilities found by AI and also maintainers drowning in vulnerability reports. I mean, on one hand, it's good that we can find these vulnerabilities. On the other hand, it's, I mean, it's scary to see What can be done, right? So, it's, I mean, at the end of the day, it brings us, as always, back to an ethical topic, right?

I mean, it is a powerful tool, and I think all the society needs to learn how to use that tool, right? So, the most important thing is, I mean, at the end of the day, use it with your own intelligence, right? Just use it as support, and as I said, just use it as a tool, right? And then, I think there's also many good things you could get out of it, right?

Getting support with code reviews, or writing some tests, so there's many great stuff. So, we did also play around a bit with, I mean, we have so much [00:43:00] data, right? Like, even our legal FAQs and license stuff, so we started playing around with training AI models with that data, and see how accurate it could answer legal questions, right?

So, I think there's many interesting topics you could cover there. Unfortunately, all the negative aspects are right now in the media and there's a reason for that.

Jonathan: Certainly. I don't want to lose sight of that. You can do incredible things using the AI tooling that is available to people now. It's really, really impressive.

Jan: But, I mean, there's also some some positive aspects, right, so...

Jonathan: I'm not an AI doomer, but I do see some potential problems that need to be dealt with. I'll put it that way.

Jan: And even... Yeah, exactly. Same for me. I'm not an AI doomer. I see potential, but I'm just very critical with it.

Jonathan: Sure, sure, that makes sense. What are, and I don't, [00:44:00] I guess the list is public of the members in OSATL, but I'm curious, like, are there any really interesting members that you think you want to talk about for a bit? Is there somebody out there doing something really cool?

Jan: Yeah, it is public.

So, now it would be really unfair, because it's like more than 100 members, and all of those are very important to us, but maybe this brings us back to the principle of a cooperative, because the cooperative has given by law a strong principle of equality. So, we are forced by law actually to treat all of our members equal. This even comes back to our general assembly.

So, there's only a limited number of votes for the members, only regular members. So, if you really buy a share at Dozal, you are allowed to vote. So, the thing is basically that you can have, I mean, we do have [00:45:00] bronze, silver, and gold members. And the only difference is that you have one, two, or three votes at the general assembly.

And that's it. There's an upper limit, right? This brings us to this level of equality. And whatever we do, but basically we could do everything, but always having in mind that what we do needs to be in the interest of all of our members. There's a pretty, I would say, strong control system behind cooperatives that you need to prove that you follow that system, right?

So, we have a supervisory board, which is formed by representatives of our members. So, they need to grade if we do our work and if we operate in the interest of our members. So, this is quite interesting that this is even forced by law, that we have this principle of equality. We are a community that does useful things together, and we really need to prove to do that.

So, from that perspective, all of our members are really important [00:46:00] to us, right? Of course, we do have many interesting products, right, in the portfolio of our members. I mean, I already mentioned that welding lasers, so strong lasers that are used in car manufacturing, right, so we do have woodworking machines that it's not just simple sawing, right, I mean, it's basically put a tree in and get an IKEA kitchen out, right, really complicated, really complicated machines.

Jonathan: Right.

Jan: Of course, we do have automotive use cases, so we, I mean, it's pretty much everything. It's really cool to see what you can do with open source, right, so it's so many interesting products, and what happens to me always is sometimes we do visits for our members. So, what we do in the community, if someone is interested in, hey, I'm now part of the community, and my company wants to learn more about open source and being [00:47:00] a good open source citizen, could you visit us?

Of course, we would do that, right? And we spend the whole day talking about open source licensing and different aspects. So, my favorite part always is I ask for a guided tour to see what the company is really doing, right? So, I mean, to see what you can do with Linux, what you can do with Zephyr. And it's, I mean, that's always the fun part to see what really you could do.

And it brings me always back. So, you see these big machines, right? And all these companies can make profit with these machines, even though if they are sharing part of their know-how, but that's not the thing, right? Because, I mean, if you think about the woodworking machines, I mean, the people building a kitchen with that are maybe not interested in the operating system.

They are just interested that it just works, right?

Jonathan: Mm-hmm.

Jan: So for that company, it's no big deal to use open source as the operating [00:48:00] system because that know-how can easily be shared. And if they write a single driver, a simple driver, they can share that with the community. So that doesn't harm their business model at all, right? So it's pretty cool how open source can help building this foundation.

And still there's the profit between all these companies doing their products, right? So they can make their personal profit out of the product and they do the contribution to the open source community as well.

Jonathan: Yeah. Yeah, absolutely. There's this interesting observation. I think the shorthand way that people say it is that it's not a zero-sum game, but that's kind of the same idea as what you're getting at. You can give away the information, you can You can license the code with an open source license, and you're not inherently losing anything. There's plenty of work to go around, is the way that I've said that as shorthand for running [00:49:00] my businesses.

I don't lose work from the fact that there is another company doing the same thing. There's enough for each of us to work at. It kind of does bring a question to mind, though: is your membership primarily in Europe, or do you have folks in the US, is there companies in Asia that's part of it?

Jan: So, we have members all over the world. So historically, of course, we have many members in Europe, because we've been founded in southern Germany, and the ten founding members were just from Germany and Austria, basically. But nowadays, I mean, we are all over the world. So, we're all over Europe, we have members in the US, we have members in some Asian countries, so it started going all over the world.

And it's also, if you look at the company size, I mean, we have big corporates, and we have one engineer companies within our members.

Jonathan: Sure. Yeah. [00:50:00] One of the fun things that hopefully you guys get to do is to be able to connect those two sometimes. Like, here's this huge multinational company, and they need this one particular thing. Well, we happen to know the guy. We got a guy for that.

Jan: Yeah, exactly. Exactly. We do that. We do encourage that. So, of course, we do run webinars and everything, but what we do once a year is that we want to exactly do that, want to bring together that one-man show and the representatives of this big corporate and making them talk together and discuss ideas. So, we call this Networking Day.

Jonathan: Mm.

Jan: This is our annual members conference, where we call all of our members to the beautiful city of Heidelberg in Germany, and this is a pure in-person event. So, there's a reason why we do not make this online, or why we do not make this hybrid. So, you can download the presentation afterwards, right?

Jonathan: Mm.

Mm-hmm.

Jan: But we want to have some motivation that people come there, and these people talk together. [00:51:00] So, what we do is we do one day with presentations, so we get speakers from different open-source communities. We prepare interesting topics just to get the thing started, right? So, people have topics to discuss about in the breaks or during the evening.

So, one big topic in Europe these days is the Cyber Resilience Act, which is the new cybersecurity regulatory, which partly got now a few days ago in place.

Jonathan: Mm-hmm.

Jan: Now, you need to report. actively used vulnerabilities in your product.

Jonathan: Mm-hmm. All right, aren't we all thrilled about that?

Jan: It will be fully in place starting next year in September. So, this is one of the... I mean, it's a good movement, definitely, but...

Jonathan: It is. It's just, I wish they had talked more with real people in the industry before they wrote it. This is something that almost every big European tech law, it's like, "Thanks, now we all get cookie banners [00:52:00] everywhere. Thanks, guys."

Jan: Exactly, yeah. So, I mean, also there's pros and cons about everything. What I need to say on the positive side here is that the European Commission gave quite a few chances for submitting feedback. So, this is also a role. So, we collected the feedback from our members and submitted that to the European Commission because, I mean, if a single company submits feedback, it's a different story than an organization with 100 members submits feedback in the name of 100 companies.

Jonathan: Mm-hmm.

Jan: So, I think that this is to put on the positive side that there was some possibility. So, at least they were open. But this is a very good, I mean, you can get into deep discussions on that.

Jonathan: Right.

Jan: So, how come? So, I think that's a good question.

[00:53:00] Thank you. And just imagine that one man engineer doing dinner together with the representatives of the big corporates, so that was, I mean, like over a glass of wine, you do like the dessert or something, and this year...

Jonathan: I was going to make the joke that being in Germany, there had to be beer or alcohol involved.

Jan: Of course, there was the possibility to have some beers as well, some craft beers, of course. Sometimes makes discussions a bit easier, right?

Jonathan: Yes, that stereotype exists for a reason.

Jan: Yeah, there's a reason for that. And this year, we actually did an escape game together.

Jonathan: Oh, fun.

Jan: So, yeah, solving puzzles together. So, I mean, this is the kind of networking we try to do. But once again, it's like, yeah, it's a community. So, you want to have people together and exchange ideas. That's how open source works, right? So, we exchange [00:54:00] know-how and we discuss stuff.

Jonathan: Yeah, absolutely. What does the process look like if someone, let's say a company, but also an open-source project, if these two different people want to get involved with OSATL, what does that process look like?

Jan: It depends a bit on what you do together, right? I mean, let's start with the company, right? So, if a company wants to get involved and says, okay, we want to support that community, or we want to profit from that community, it's basically quite easy. You become a member, right? So, becoming a member basically means one time you buy a share. So, you become one of the owners of Asada, right? And based on the number of shares you're holding, you would pay annual service fee, That is pretty much how we finance our work, right?

How we put the budget together, that we spend together. So, [00:55:00] this is pretty much how it works for a company. So, you would apply for a membership, buy a share, and you support our work by an annual service fee, basically. For open source projects, for academics, for partner organizations, it's basically something cost-neutral, right? So, we want to support each other with the funding coming from the industry.

So, a typical collaboration with an open source project could be that we identify that our members are using a specific technology, like preempt RT. So, we say, okay, this is pretty important, so we find a way to fund that project, right? So, we try to become a sponsor, put some money together, and try to finance the maintainers.

The same for our Ocelot project. So, even though it was founded by us, we have an independent maintainer, so we are funding that maintainer. We are holding the trademarks, holding the domains, running the server [00:56:00] infrastructure to make maintainers' life easier. Sometimes, Projects independently to membership, we call that mixed funded projects. So, whenever we identify interesting technology, we ask our members, hey, do you find this of interest? And are there any features you want to have implemented?

And then we start collecting sponsors from all the industry. What we would do is do the project management and collect the budget, right? And then we would hire someone to get stuff implemented and push it mainline. So, the requirement whenever we hire someone doing something is always that it has to be released under an open source license.

So, this is like of the corporations we do with open source projects. Sometimes we participate in conferences, or for maintainers and key members of open source projects, we grant them free access to the assets that are usually only accessible to our members to give some support like licensing [00:57:00] or legal support. I mean, open source projects usually don't have budget for that. So, this is sometimes where we can jump in and help them with getting them access to the material we have.

Jonathan: Mm-hmm. Yeah. Interesting. When is the in-person meetup?

Jan: That's always in tune, so it's unfortunately already over for this year, so it's always in tune, so if there's anyone heavily interested, of course, we always invite some non-members to get in touch with our community, just get in touch with me, and so we're always glad to have people there to discuss about open source.

Jonathan: In June, okay.

Yeah, yeah, this is very interesting. So, is OSOTL also like a fiscal host for some of these projects? I think that's what you described, at least for OSOLOD.

Jan: Yes, so it is for Ocelot. [00:58:00] So, being a fiscal host is just happening for Ocelot. So, we are sponsors for a couple of more. I mean, we're a very small organization, right? So, I mean, there's some limits we do for what we can do. We try to operate as effective as possible, so we're the fiscal host for the Ocelot project. So, we've been supporting a project which is called Open 62541 for quite some time with significant funding. It's an OPC UA library open sourced. And, I mean, not surprisingly, we are historically for many years a premium

sponsor for the PreemptRT project. We are putting significant budget into the preempt RT development. So, for these projects, we are budget-wise involved, but we're not the fiscal hosts, right? So, we're just... But also, we are in the name of our members, we are sponsoring these projects, right? So, with all the member contributions, [00:59:00] we sponsor the key technologies that are of importance for our members.

Jonathan: Understood.

Sure. Yeah, no, absolutely. That Yeah,

absolutely. That makes a lot of sense. You see industrial automation being sort of the key place that you're going to continue working in?

Jan: It is one of the places we're going to continue working in. So, it's one of the traditional places, but, of course, we can see that there's way more industries coming to open source, and where we can definitely provide useful support. I mean, we even have, like, companies doing online platforms, which are far away from embedded technologies, but they want to have some legal support and some licensing support for their online platforms.

As I mentioned, we have automotive. We see a tendency more for medical devices being run with open source. They also have the topic with safety certifications, for example. So, these are the big upcoming topics.

Jonathan: Mm-hmm.

Jan: So, once again, traditionally, it's a lot of automation, but at the end of [01:00:00] the day, our community can grow into all directions, because we can provide to… Basically, if you are using open source in a product… I'm quite sure that you can be part of our community, and you would be beneficial of our community, because… Every single member is important for us. It helps us to do great things, right?

And I always tell our members: don't be shy asking questions, right? Because with everything we do, with every project we fund, with every question we answer, we get some useful knowledge for all of the other members.

Jonathan: Yeah, you mentioned medical devices, and it brought to mind a memory that the 6502 is still being produced. One of the reasons being is that it gets used, because it's so well-known, and it's so simple, it gets used in medical devices.

Jan: Yeah, yeah, yeah, yeah.

Jonathan: And so, like, if you get a pacemaker implanted, there is a reasonable chance that it is a 6502 that [01:01:00] makes that thing work.

Jan: Yep. Yes.

Jonathan: Crazy. Alright, as you sort of rub your crystal ball and think about the next five, say, five years of open source, what's on your radar? What are you—sorry to mix my metaphors there—but what do you foresee

Jan: Yeah, so, um, We already touched a bit of what the Chrysler ball might tell, actually, so my Chrysler ball tells that there will be a lot of movement towards the safety direction, there will be more efforts, and maybe some more ideas, and using not just Linux, just open source in safety critical areas. So, this is something, if we look five years in the future, I think the picture will be way clearer and maybe we see the first solutions coming up there.

I mean, even in the Linux side, quite some efforts. Look at the Zephyr project [01:02:00] that is strongly going there, so this is definitely maybe a pretty clear forecast. I think that there will be maybe more efforts, we could see more Linux in space, because this is also a very interesting use case for open source, so I would predict that. Obviously, we've seen Linux already in space before.

Jonathan: We've seen Linux on Mars!

Jan: Yeah, we've seen Linux on Mars, and my prediction is that we will see more of that in the future, so that's actually the geeky stuff I'm looking for, seeing Linux in space, seeing more open source in space.

Jonathan: Yeah, absolutely.

The...

Oh, absolutely.

Yeah, the best story that I've ever heard, and it's hilarious, is that apparently several years ago on the International Space Station they started running Linux on all the laptops because they couldn't keep them virus-free otherwise. They kept getting [01:03:00] malware on their laptops. Yeah, I love that one. It was hilarious.

Jan: I mean, this is maybe a place where you don't want to have a virus on your laptop, because you don't have much options in going home. There's only one option, so if that doesn't work correctly, you're in trouble.

Jonathan: Indeed. For an attacker, lateral movement is going to be really interesting from there, too. So, you have a note in the rundown here that there are some parallels between open source and cycling. And I'm very curious what you have in mind. It ties into your shirt: you must be a cycling enthusiast.

Jan: Yes, exactly. I am, I am. So, I think I'm with cycling as long as I'm with open source. So, I mean, the reason is, basically, my theory is, if you're interested, so if you're enthusiastic with something, which is your profession, you need something with the same passion in your spare time. So, I mean, it's somehow [01:04:00] equal. Yeah, there's actually quite interesting similarities you could basically see in people doing cycling or other endurance sports.

Maybe the clearest parallel is that the passion people bring into stuff, right? So, for all the people I see working in open source, they bring so much passion in it, right? Look at all the maintainers that are not properly funded and still working day and night to getting their project running. Doing endurance sports, you, I mean, you have somehow that passion, because, I mean, if you, like, do a long distance ride, you always have the option to stop, right?

It's just your will that keeps you running. So, I think that level of passion is pretty much the same. But also, what is interesting, what is maybe not obvious, when you're following cycling races, so if you're not into cycling, you most probably just see the individual cyclists doing their route, right? [01:05:00] At the end of the day, it's important to know that cycling, specifically with the big races, it's a team sport, right?

So, all the big leaders at Tour de France or Giro d'Italia, they could not win without all of their supporters, right? So, there's always a clear strategy. They have supporters that make their way, that go back to the team car, get them water and stuff to save some energy for the sprinters to get them into the right position with the correct timing.

Right? And so, it's also community work. So, that's a bit the parallel I see as well. So, even if you maybe have a few single persons that are in the public, there's so many people behind working on the whole strategy and making things good, and it's the same for open source. You have the leaders, you have the strategy, but you have all the contributors [01:06:00] doing that work, and together you reach the goal.

It's the team sports aspect that brings me thinking, comparing cycling and open source.

Jonathan: Mm-hmm.

Yeah, absolutely. I like it. It's a good metaphor. Is there anything that we didn't talk about? We basically hit the hour mark. Is there anything that we didn't get to that you wanted to let folks know about?

Jan: time flies when you talk about open source right i think we talked about love interesting things

Jonathan: Absolutely.

Jan: at least i we talked about the most important things i i wanted to cover today i wanted to bring to the to the audience i think what was important for me is also that there's so many ways that you could work together right not just the technical stuff there's even on legal topics you can work together in a community and you may can make things better together so as a community you're always stronger and this is pretty much what we like to do at osada and what we love to do and what we will continue in future

We're [01:07:00] trying to improve the ecosystem for all of us.

Jonathan: Yeah, absolutely. I do have some final questions that I ask everybody, and we've added a third recently. So, the two classic questions are: what's your favorite scripting language and text editor? Once you answer those, then I'll hit you with my third.

Jan: So, the favorite scripting language, so I am a very old-school bash programmer. I mostly do all of the stuff I need, just as a simple bash script.

Jonathan: Very cool. There you go, Dim and Bash. All right, now the third question, the new one:

Jan: The favorite editor is Vim.

Jonathan: if you're gonna, if you're gonna vibe code something, which AI agent do you reach for?

Jan: Whoa. Well, that's a tough one, but I would say I would go with Glute.

Jonathan: Yep, that seems [01:08:00] to be the answer right now. Things are still very in flux, though. We are very early, I feel, in this revolution still, so who knows where we'll end up here in another six months.

Jan: very early. So, if you play around, some model is doing very good in doing graphics, some are better in coding. So, let's see where that story takes us.

Jonathan: I've also sort of learned that it depends upon which language you're working in, like Gemini tends to be better doing Android apps. Surprise, surprise. But, you know, there's some of those things that, you know, it varies. It's based on the task. Jan, thanks so much for being here. It has been a blast to get to talk to you, talk about OSATL and all the things going on. Yeah, appreciate it. All right. I do want to let folks know we're taking a week off next week, because I'm going to be in Europe at the Things

Conference, and then we're going to come back in two weeks. We don't have a guest yet, so if you want to be on the show or you know somebody that should, shoot us an email, floss@hackaday.com, [01:09:00] and we'll get them scheduled up, but I'm sure we'll get the slots filled, and we've got next month opened up, and so let us know, and we'll get you scheduled. Other than that, I just want to say thank you to everybody that joins us, whether you watch us live or on the download, video or audio, we appreciate you being here, and we'll be back in two weeks on Floss Weekly.