PROJET AUTOBLOG


Free Software Foundation Europe

source: Free Software Foundation Europe

⇐ retour index

Open Hardware and Free Software: Teufel Mynd, a case study

lundi 29 juin 2026 à 01:00

Open Hardware and Free Software: Teufel Mynd, a case study

The FSFE's volunteer and open hardware passionate, Nicole Faeber read about the Teufel Mynd speaker announced as an "Open Source Project", so she decided to put it to the test. We, the FSFE, bought one and she dug in. Curious what she found? Read along with us!

Teufel Mynd Bluetooth speaker box

Open hardware and Free Software are about more than tinkering: they give users the freedom to inspect, modify, and truly understand the technology they rely on every day. Open hardware means the design of a device is publicly available: anyone can study how it's built, improve it, or manufacture it themselves. Free Software goes hand in hand with this: it guarantees that the code running on your devices can be use, study, share, and improve by anyone. Together, they ensure that whoever owns a device gets to decide what runs on it, free from manufacturer lock-in or hidden restrictions.

This article has not been sponsored by Teufel in any way. We bought the device to test from our own money and did all research on our own.

In May 2025 the German audio hardware maker company Teufel announced a new product, the Mynd Bluetooth speaker box. The speaker in itself is yet another Bluetooth speaker box, the remarkable feature of it is that it was announced as an "Open Source Project" with "high repairability and sustainability", with all mechanical and electronics design files as well as the firmware source code published as "open source". So they mean the Mynd to be a Free Software and open hardware product.

So we wanted to put this to a test!

TL;DR - A Quick Summary

The Teufel Mynd project is a pretty impressive example of an Open Source Hardware project. All the mechanical and electronics design files are made public under a permissive license granting the four freedoms - to study, to share, to modify and to distribute modified versions of it. The data is complete enough to recreate the whole hardware, the mechanical enclosure as well as the electronics PCBs.

There are only two caveats:

  1. The loudspeakers themselves are, at least very likely, Teufel proprietary and Teufel does not sell them as spare parts.
  2. The firmware for the Bluetooth module along with some DSP and USB type-C controller firmware are not Free Software. But at least the files are provided as binary blobs so one can build a complete firmware update file.

So the project fulfills the Open Source Hardware Definition.

Let's dive into the details!

Repairability

Many current consumer electronic devices these days are not repair friendly. Cost pressure and ease of mass production make the non-repairable options, like glue instead of screws, very appealing to manufacturers.

The Mynd is very different in this regard. The case is held together by screws, not glue. The parts are pieced together tightly with proper rubber seals, not glue strips. The screws are clearly visible and marked, not hidden away under some sticker label or warranty seal. The different screw sizes and types are documented on the bottom of device itself. Also the starting point to pry the casing parts apart after taking out the screws is marked on the case. So opening the device is really made as easy as possible, no guessing, the steps for dis- and reassembly are clear and pretty much self explanatory.

Mynd opened

There is just one caveat, availability of spare parts. So far Teufel only offers the battery pack and carrying belts as spare parts, not the Printed Circuit Boards (PCBs) or speaker chassis themselves. Maybe it is possible to convince the Teufel service center to buy these, but Teufel's general policy for spare parts says: "Please note: We do not ship circuit diagrams, toner, or electronic components such as circuit boards, capacitors, and resistors". For the average customer, this limits repairability.

Open Hardware

As promised in the product announcement, Teufel made all hardware design files publicly available on GitHub. All these files are, where applicable, licensed under the Creative Commons "Attribution-ShareAlike 4.0 International" license which allows the four freedoms: Use, study and modify, redistribute the original and modifications.

This is pretty remarkable!

3D CAD, the casing

All components of the case are split into separate 3D CAD files and are available in 3DM, STL and STP format. In total there are 11 different parts that make up the case / chassis. Here we have the main case STP file opened in FreeCAD:

Teufel Mynd speaker opened and dismantled

So yes, everything is there, the full case and all its parts! Can you remake it, like 3D print? Well, let's see, here is the front grill STL file opened in the Cura 3D printer slicer:

This is looking pretty good! Since the Mynd speaker box is quite big you of course need a large 3D print room, the front grill is 26cmx18cm. But the problem is in the details. The 3D CAD design has not been optimised for 3D printing but rather for injection mold production so this makes 3D printing difficult and we can see the issue when looking at the print plate from underneath:

All the red parts are free floating, i.e. these do not touch the print surface and will create issues while printing. With some luck and a good printer these will still come out OK but they may also end up quite ugly. Another a bit problematic part are the "knobs" on the top side which hold the front grill tight in rubber gaskets of the speaker fixture:

These little knobs also have some overhangs which can create issues while printing.

So is the CAD design indeed "open hardware"? Yes! It is open licensed and you can use Free Software tools like FreeCAD or Cura slicer to tinker with it, even try to reproduce parts e.g. using 3D printing. The 3D printing limitations (overhangs etc.) are not a detriment to the open hardware nature, nothing requires open hardware to be easily reproducible.

Electronics, schematics and PCBs

Next let's have a look at the electronics design, also for this all relevant files are available in the same hardware GitHub repository under the same "Attribution-ShareAlike 4.0 International" license. Again the files are made available in three file formats: Altium Designer, KiCAD and PDF. The PDF files are PDF exports of the schematics and the printed circuit board (PCB) layout. The Altium Designer and KiCAD formats are the much more interesting ones since these contain the editable schematics and PCB layout! Since we only use Free Software we cannot use the Altium files, so we focus on the KiCAD version for now - I assume that the original design was made using Altium and was then exported to KiCAD.

Excursion: Electronics making

To design and finally make a piece of electronics, a number of pieces are needed. First you need to have some idea what you are going to make, of course. Based on this you need to start choosing components for your design - which chips to use, which power supply these need, how this needs to be designed with which parts etc. So from a very early stage the component selection is a critical first step, we'll also come back to this a little later.

Next you need to start to draft your electronics design, i.e. how all the components are connected to each other. This is done in the so called schematics. Every single connection of each of the components is made here. The schematics usually does not look similar to the final PCB, it is a rather abstracted view on the hardware and focuses on the parts choice and the connection between the parts.

Once the schematics is somewhat ready the next phase is a real time sink, creating a PCB layout from the schematics. Tools like Altium or KiCAD assist with it, they know the physical sizes and constraints of the components and visualize it for you. But in the end the engineer has to properly place them on the virtual PCB. Placing is not only a matter of just putting them somewhere but you also need to know electrical constraints and keep routing the connections in mind. Creating a PCB from known schematics can take days and weeks and needs a lot of experience. Adding to that there may be mechanical constraints as well, e.g. known maximum PCB sizes or shapes that need to be taken into account.

Once the schematics and PCB layout is done the PCB can be ordered from a PCB manufacturer and all electronic components can be ordered from the various distributors. In many cases you need to order from more than one distributor because not even the large ones carry all components - and fingers crossed everything is in stock!

Once PCBs arrive and all parts are at hand you can finally start to assemble the PCB and power it up for the first time: Good luck the "magic smoke" stays within the parts!

The main board

So let's have a look at the main PCB as an example:

The Teufel engineers created a full KiCAD project for each PCB that can be directly and completely opened in KiCAD with all parts - schematics, footprints, 3D components and the full PCB design. Here is one page of the main PCB schematics for the main microcontroller:

Schematics

The schematics only show a limited level of detail, some details necessary for actually making a device are not shown. For example the component with designator "C22C" right of the microcontroller unit (MCU), in the schematics you can only see that it is a capacitor with 100nF capacity. But the actual specification needed contains a lot more information, which is also contained in the KiCAD project:

Example component C2C

So here you can see that it is rated for maximum voltage of 50V, has a temperature coefficient of X7R, a tolerance of +/-10% and that the physical so called "footprint" is 0603, which means a surface mount device (SMD) 6mil long and 3mil wide - 'mil' is 100th of an inch, a common size in PCB design, so about 1.6mm in length and 0.8mm wide. A pretty small component. Each and every component needs to be specified this way.

For a capacitor one usually can find components with the same specification from different manufacturers which makes component sourcing a bit easier. Some distributors allow importing a Bill Of Material (BOM) into their shop system and will offer best matches. For some other components there can be a variety of choices with very similar specifications which can make picking the right one complicated. In this case an exact manufacturer part number comes to the rescue:

Example MCU

In this example there is the main PCBs microntroller unit, specified with its exact manufacturer and the manufacturer's part number, ready for ordering.

Speaking of ordering, it is also quite common, especially for commercial projects, to also specify an ordering source within the project, so that later on a BOM can be exported and handed over to e.g. a purchasing person or department for ordering all the components. In the KiCAD Mynd project there are no ordering sources.

So, are the electronics design schematics open hardware? Yes! It is licensed under an open license providing the four freedoms. All necessary information to understand the schematics is included as well as all information to make a PCB from the schematics.

PCB layout

And now to the real fun part, the PCB layout. I won't go into the details here because there would be too much to cover. Just to give an idea here is the main PCB view in KiCAD's PCB editor:

Main PCB layout, KiCAD

This is a 4-layer PCB, i.e. it has four layers of copper traces, top, bottom and two in between. This PCB alone carries 561 components! Many of them small SMD components, the smallest being some 0402 resistors (4mil x 2mil = ~1mm x ~0.5mm). And to make things even worse, there are components placed on both sides of the PCB which makes soldering even more complicated. In KiCAD there is an awesome feature to create an interactive 3D view of the designed PCB, here is the Mynd Main PCB front and back:

KiCAD 3D Mynd PCB frontKiCAD 3D Mynd PCB back

In total there are nine (9) PCBs in the Mynd speaker box, the main and amplifier PCBs being the largest and most complex. In total there are 1047 components on these 9 PCBs, about 87 different types of components. Just managing the supply and stock of 87 different component types is, I can tell from experience, a major effort.

Is the PCB layout open hardware? Yes! You have the four freedoms and the hardware design details are complete enough to rebuild the whole thing! From parts specification to PCB specification (so called "stack up") everything is there. The only issue one might run into trouble with is finding ordering sources for all the components, but that's probably outside of the scope of open hardware anyway.

Make it yourself?

Well, I have not tried, but looking at the design files, mechanical and electronics, I think building the Mynd speaker hardware from scratch should be possible. I have not found any information missing, except maybe ordering sources for the components. Placing and soldering all over 1000 components on the nine PCBs will be a major effort and with components down to 0402 will be difficult to place by hand, some pick & place setup would be very helpful along with proper SMD reflow soldering equipment. But the important part here is that there is no information missing in the design files, it's all there.

3D printing the case could be possible as well, with some additional effort to accommodate for 3D printing instead of injection molding. The result will very likely look and feel differently, but it could work.

What will definitely become a problem are the Teufel specific custom parts, i.e. the speaker chassis themselves. Other parts like the rubber gaskets and rubber seals these are also in the 3D design files but will be hard to e.g. 3D print properly.

The firmware

And now to the final part, there is also some software involved! The main MCU, a STM32 microcontroller, runs some software as well as is the module used for the Bluetooth connectivity and sound generation. The source code and build scripts were also made available by Teufel. The parts created by Teufel, i.e. the application software running on that STM32 MCU, are licensed under the MIT license. But for building it, some more dependencies are needed, like some software development kit (SDK) bits from ST-Micro (Apache 2.0, BSD 3-clause, MIT, proprietary ST SLA), bits and pieces of FreeRTOS (MIT) and some more proprietary binary only parts for the Bluetooth module, the audio DSP and, last but not least, the USB type-C port controller - yes, also these things have their own firmware these days.

So apart from the blobs everything is Free Software, which is pretty cool! The blobs though are a bit of a bummer. But is this Teufel's fault? Or does this make the whole project less "open hardware"?

My personal take on such blobs is this: While I dislike proprietary blobs in general, because they limit our freedoms to use the hardware as we like, I can at least accept certain blobs, e.g. in the case where chip+blob form a kind of union so that I can basically view the two together as just a single piece of hardware. I still don't like it, because it is hidden software, but at least I can somewhat accept it. We have this kind of situation in many cases and are somewhat OK with it - the WiFi firmware in our WiFi cards, the firmware in the touchpad controller of our laptops etc. The list is long, very long. How to properly address and fix this is another story we need to come back to another time.

The firmware package can be built using the free GNU GCC cross compiler for ARM and build the firmware for the STM32 MCU. The firmware blobs for the DSP, Bluetooth module and the USB type-C controller do not get built and it is also not documented how to program these. But at least the binaries are there.

So is the firmware Free Software? Concerning the MCU firmware, yes, it is. All firmware? No, there are certain blobs.

Especially sad is that the Bluetooth part is completely binary only in the Bluetooth firmware blob, so all pairing, Bluetooth audio protocol (A2DP with SBC) etc. is hidden in that blob and can not be changed - I would have been curious if SBC-XQ (higher quality audio codec) or TWS (True Wireless Stereo) could be added to that Bluetooth firmware.

Final verdict

So, is it open hardware?

Mechanical design / parts: Yes! Everything is documented properly, some special components are not available off the shelf and need alternative sources, especially the speakers. It would be great if Teufel would also supply these through their spare parts shop.

Electronics design: Yes! The KiCAD files contain everything one needs to completely recreate and especially repair the electronics. Some components may be difficult to source though (like the Bluetooth module).

Firmware: The Teufel made parts are Free Software, some third party firmware parts are not (USB type-C controller, DSP, Bluetooth module).

With all that it also qualifies nicely for the Open Source Hardware Definition by the Open Source Hardware Association (OSHWA).

Overall I think the Teufel engineers did an extremely good job here! They definitely set the bar and have given a great example of how one can make open and sustainable consumer hardware. For some first hand insights there is a nice interview with the engineers published on the Prototype Fund website (in German).

Will the openness detriment their business? I am fairly sure it won't. Yes, maybe competitors can learn a bit about high quality engineering, but on the other hand this isn't rocket science either. Will they loose business because people will now rather build it themselves instead of buying a ready made device from Teufel? I doubt that. While I am quite convinced that one could build a complete Mynd device from the open specifications, it would take many many work hours - the logistics for the over 1000 electronic components, populating the PCBs, 3D printing or otherwise making the enclosure etc. - this is a serious undertaking and will take weeks along with dozens of person hours. A good hacking experience, for sure! But economically definitely not worth it, better go and support the company that made it with a purchase.

Outlook

Open Hardware not only means better repairability and with it better sustainability. It also means possible enhancements too! For example the Bluetooth module in the factory Mynd only supports the rather mediocre SBC audio codec. But since the electronics are made modular and the rest of the system is documented so well, why not think about replacing this limiting Bluetooth module by something else? By something more capable?

Why not replace it with an ESP32 based module plus high quality audio codec chip? Would not be the first ESP32 based audio device.

Why stop at an ESP32? There is a discussion going on in the GitHub Mynd hardware repository about replacing the proprietary Bluetooth module with a Raspberry Pi Zero 2 W based module! This would not only enable other Bluetooth audio codecs but then you would also get a complete Linux system into your Mynd, with its own media playback capabilities! Prototypes already seem to exist.

This is the brilliance of Free Software and open hardware, the limit is your imagination, it is in your hands.

Happy hacking!

Do you care about sustainability, repairability and Free Software? Did you do research about which products work best with Free Software? Have you ever tried to tinker with them? We would love to hear your experiences. Please, share your knowledge with us. We want to know which products work better when you want to be in control of your devices! Moreover, if you are a skilled Free Software enthusiasts who would like to volunteer to also analyse devices, please get in touch with us, so we can work together towards our goal that so we can work together towards our goal that everyone can install or remove any software on any of our devices.

Support FSFE

DMA: Protecting Device Neutrality in Android Devices

lundi 15 juin 2026 à 01:00

DMA: Protecting Device Neutrality in Android Devices

The FSFE has submitted its position to the European Commission’s Android interoperability consultation under the Digital Markets Act, calling for, among others, the right to fully uninstall AI-based features from Android devices, and access to interoperability functions for developers free from Google’s verification requirements.

The AI boom has reached not only us as users, but also our devices. For example, Android devices are silently installing large AI models without users noticing it. According to recent reports, these models cannot be uninstalled by end-users, and occupy several gigabytes of storage. The European Digital Markets Act (DMA) requires companies like Google to allow end-users to uninstall pre-loaded software on their devices. This issue is one of several that the Free Software Foundation Europe (FSFE) has formally raised in its contribution to the European Commission's public consultation on Android interoperability under the DMA.

As part of case DMA.100220 under Article 6(7) of the DMA, in which the Commission is developing binding interoperability measures for Google’s Android platform, the FSFE is calling for several improvements within the Android Open Source Project (AOSP). Among them we are asking:

“Interoperability must be decoupled from developer verification procedures. We need clear, precise, and inclusive rules to prevent circumvention by gatekeepers and to ensure that interoperability becomes a concrete reality in practice” states Lucas Lasota, FSFE Legal Programme Manager

Uninstallation of AI-based features

There is a broader pattern: gatekeepers increasingly determine which applications come pre-installed on devices, challenging the end-user capacity to fully remove those applications or their associated components. Uninstalling software should not be a temporary action that Google, and other gatekeepers, can quietly reverse. The FSFE called for clear safeguards ensuring that users can fully remove components (including AI-based features), can recover the storage space they occupied, and that companies cannot reinstall, reactivate, or update those components without the user’s prior and explicit consent.

This is not a new concern. In July 2025, the FSFE, together with other civil society organisations, filed a formal complaint to the European Commission on the lack of proper uninstallation of apps in Android devices. The current consultation represents an opportunity to reinforce and extend these protections to cover AI-based features specifically.

Decoupling interoperability from Android Developer Verification

In September 2026, Google will roll out the Android Developer Certification, forcing every Android app developer to register with Google before their software can be installed on any device. The program, criticized by Free Software developers and civil society, entails the signing of contracts and payment of account fees to Google and handing over the identity of developers. Such measures are particular problematic for Free Software developers who have deliberately chosen to operate outside Google's ecosystem, or for developers exposed to non-democratic activities in Europe and in other countries, where registering their identity with a private corporation could expose them to surveillance and retaliation risks.

The Commission's draft measures, if unchanged, would still allow Google to require developers to go through a verification process tied to the Google Play Store before accessing those features. Asking developers to register with Google or sign an agreement to access interoperability features under the DMA effectively forces them to give up the independence that makes them a real alternative. This is contrary to the text and spirit of the law.

Even where the draft measures say that access must be free of charge and technically workable, they do not prohibit Google from requiring a Google account or a developer programme agreement as a precondition. For alternative Android developers, signing such an agreement means accepting terms that can restrict what they build, how they distribute it, and what services they must pre-install. That is a real cost, even if no money changes hands.

The FSFE therefore calls on the Commission to close these gaps explicitly: no developer should need a Google account, a Play Store presence, or any agreement with Google to access Android's interoperability features.

Read the full statement here (EN).

Device Neutrality and the DMA

The Digital Markets Act is a European Union law designed to limit the power of large digital gatekeepers such as Google and Apple. One of its central goals is to make digital ecosystems more open and interoperable, so that users and developers are not entirely dependent on the conditions imposed by a handful of large tech companies. Article 6(7) of the DMA obliges gatekeepers to provide free-of-charge interoperability with the software and hardware features of their designated operating systems. For this obligation to translate into real-world openness, the measures the Commission adopts must be precise, inclusive, and enforceable.

The FSFE has been actively engaged in DMA drafting and enforcement from the outset, advocating for interoperability obligations, uninstallation rights, alternative app stores, and fair access for Free Software developers. The FSFE has also intervened directly in court proceedings concerning Apple’s DMA compliance. This contribution to the Android consultation is another step in that long-term commitment.

Support FSFE

SFP#52: Policy and EU: Insights from the T-DOSE conference and the Dutch community

vendredi 12 juin 2026 à 01:00

SFP#52: Policy and EU: Insights from the T-DOSE conference and the Dutch community

In our 52nd episode, we turn our attention to the European stages, this time going to the Netherlands. There, on 6 and 7 June, Dutch volunteers and Free Software enthusiasts came together for the 2026 T-DOSE conference, the heart and soul of the local community.

The FSFE’s Dutch team not only supports the FSFE, but is also involved in organising a local conference on Free Software. On this Software Freedom Podcast episode, Bonnie speaks to Nico Rikken, a long-standing FSFE volunteer and coordinator of the Dutch team. Through his voluntary work, Nico is a strong advocate for Free Software and is also part of the core team organising the T-DOSE conference: a Dutch nationwide annual conference dedicated to Free Software. Like many local conferences, T-DOSE has that special atmosphere, that sense of belonging and community. Join us to get to know the Dutch Free Software hackers!

In this episode, Nico and Bonnie discuss the Dutch Free Software community, with a particular focus on the T-DOSE conference. Together, they discuss the challenges facing local conferences and how the team behind T-DOSE plans to tackle them.

The FSFE's policy work is an important part of our aim to safeguard Software Freedom. You can support our work by donating today!

Show notes

We are happy to receive your feedback on the Software Freedom Podcast and especially on the transcript of the episode. Please, email us to: podcast@fsfe.org. If you liked this episode and want to support our continuous work for software freedom, please help us with a donation.

Support FSFE

Decades-long victory, bold Apple survey findings, legal workshop success & our 50th podcast episode

lundi 8 juin 2026 à 01:00

Digital Sovereignty needs Free Software

In the last weeks, we got the green light to intervene against Apple before the European Court of Justice for the second time (!) while the European Commission has included the “Public Money? Public Code!” principle in its Technological Sovereignty Package. And stay tuned! A new European consortium will be launching soon, and we are part of it!

This month is starting with good news: the European Commission included the Free Software Foundation Europe’s “Public Money? Public Code!” principle in the newly released Technological Sovereignty Package, which also contains the new "Open Source Strategy". If implemented, it could mark a paradigm shift towards making publicly financed software available as Free Software. But it is too early to lean back: Its success will depend on binding rules, long-term funding, and meaningful civil society involvement.

However, not all public administrations think the same: England’s National Health Service (NHS England) has made most of its public source code repositories private by default, based on concerns that public code repositories could be scanned by AI systems to identify vulnerabilities. At the FSFE we were clear about it: NHS England should not hide public code behind closed doors. De-publishing does not make code unseen, nor does it remove existing copies, and it is not an effective security measure. Instead, it removes a fundamental pillar for security: the ability of independent experts, researchers, and other public bodies to inspect, reuse, and improve the code, and to report on security issues.

We called on the Free Software community to push that decision back by signing an open letter to NHS England, calling on them to keep their code open. The community’s response was strong, with more than 500 additional signatures in the hours after our call. Shortly afterwards, the UK Government Digital Service issued new guidance making clear that public bodies should keep code public by default.

Digital sovereignty through Free Software was also the topic of our latest Software Freedom Podcast episode, in which Bonnie and Johannes talk with Petteri from X-Road about the current challenges for Free Software projects in public administrations. Listen to it!

You may already know that despite the need for digital sovereignty in Europe, funding for European projects such as the Next Generation Internet Zero (NGI0) programme was cut. We're glad to share some good news on this front: we recently announced a new European consortium for a resilient, home-grown technology European ecosystem: the Restack project. Operating under Horizon Europe, the FSFE is a partner of this cascade funding programme, designed to retain the strength of the NGI Zero approach. Our role will be to provide legal and licensing support for potentially over 200 Free Software projects and assist their growth into part of a wider European digital commons.

Defending interoperability in Europe

“With industry interests well represented by several interveners on the other side, the FSFE is there to ensure that civil society is equally heard — and that the court can decide with the full picture before it"

Dr. Martin Husovec, the lawyer representing FSFE in the case T-359/25 - Apple against the European Commission

In a landmark development for Software Freedom in Europe, the Free Software Foundation Europe has been granted permission to intervene at the Court of Justice of the European Union in the case T-359/25 - Apple against the European Commission. This intervention aims to defend interoperability and Software Freedom in Europe and it is the second time the FSFE is intervening in a litigation at the CJEU in regards to the DMA and Apple. The previous case (T-1080/23) concerns Apple’s broader challenge to its DMA obligations and its designation as gatekeeper, while this case (T-359/25) focuses specifically on interoperability under Article 6(7) DMA and the legality of the European Commission’s decision specifying how Apple must implement those obligations in practice.

Following our work on the Digital Markets Act, we participated in the SCiDA Conference in Düsseldorf, a leading academic event focused on competition in digital markets. There, the FSFE was invited to present its work on interoperability in Android during a plenary session, highlighting the relevance of our work within ongoing policy and academic discussions.

The conference brought together senior representatives from competition authorities across Europe as well as members of the European Commission's DMA enforcement team. The conference provided an excellent opportunity to strengthen connections with key stakeholders and to further raise awareness of the FSFE's policy work on digital markets and users' freedom to control their devices.

Up for learning more about the DMA? We were invited for episode 5 of the "DMA Vox Populi" podcast about the DMA review. There, Dario discusses what the European Commission got right, where it fell short, and what must come next for software freedom and interoperability in Europe.

Youth Hacking 4 Freedom 2026

The 2026 edition of Youth Hacking 4 Freedom is reaching its peak. The programming period wraps up at the end of this month, and while participants can finally catch their breath, the jury will be getting to work evaluating their projects. In October, we will meet the 6 winners of this edition at the Award Ceremony weekend in Brussels.

For the fifth edition of YH4F we had over 80 participants from 21 countries! 😮 We can't wait to see what they have developed. And we are already planning for the next edition, so stay tuned!

From the stages: Ada, Digital Sovereignty, PIWO and more!

May has been a busy month! Our Polish local group took part in P.I.W.O. (the Poznań Free Software Event), where volunteers ran a booth promoting Free Software. And while the name might make us think of free "piwo" (that's beer in Polish), what participants got was free pizza.

In Berlin our group organized a Linux presentation day in which people could try Linux laptops and get all their questions answered about them.

Moreover, besides attending SCIDA, we participated in a panel about the DMA in Brussels. During the CPDP conference, we sat in the panel entitled "It takes two to tango: Public and private enforcement of the Digital Markets Act" at the CPDP conference, where we presented our work on the DMA enforcement, including our litigation against Apple at the European Union Court of Justice.

Digital sovereignty was also the topic in a lecture series in Regensburg, where, after watching the animated movie “Ada & Zangemann”, we took part in a discussion about this topic.

The FSFE is turning 25! And we want to celebrate it with you!Join us on 18 and 19 July in Cracow for a weekend full of Free Software with talks, networking, and of course, a cake! Wanna know more? Write us: contact@fsfe.org

Ada was also present at several events: we had a movie screening and a kids' workshop at the Tübingen Digital Freedom Days, where we also ran a booth. In Utrecht, at the NLUUG conference, our booth had a focus on Ada & Zangemann too. But the highlight this month was in Italy: our Italian community celebrated three years with Ada at an event in Pesaro with more than 50 primary school kids… and ice cream for everyone!

One last recommendation if you are a German speaker (also good for practising your German skills 😉): listen to the latest episode of the Engineering Kiosk podcast, featuring Ada & Zangemann! There Matthias talks with Andy and Wolfgang about a lot if interesting background details of this illustrated story.

Your support helps us move our work forward

We may be behind the wheel, but you’re the ones keeping us moving forward. You can also support us, contribute to our work, and join our community. Are you using social media? If so, do not forget to follow us there! You can also follow the FSFE news in your RSS Reader.

Your editor, Ana

Support FSFE

EU Tech Sovereignty: A milestone for Public Code? Now implementation is key

mercredi 3 juin 2026 à 01:00

EU Tech Sovereignty: A milestone for Public Code? Now implementation is key

The European Commission published its Technological Sovereignty Package on 3 June 2026, containing the new "Open Source Strategy". If implemented, it could mark a paradigm shift by adopting the Free Software Foundation Europe’s “Public Money? Public Code!” principle. Its success will depend on binding rules, long-term funding, and meaningful civil society involvement.

The European Union currently spends an estimated €264 billion per year, predominantly on proprietary IT products and services, cementing systemic dependencies and vendor lock-in. To counter this, the European Commission’s new strategy positions Free Software, also known as Open Source, as a strategic enabler for European competitiveness, explicitly recognising the freedoms to use, study, share, and improve software. The upcoming Cloud and AI Development Act (CADA) introduces a Free Software first principle for “public cloud and AI software procurement”, requiring public administrations to make software purchased with public funds available for reuse. However, the document is non-binding and now needs strong backing by the Commission to achieve technological sovereignty through Free Software.

“The European Commission’s explicit recognition of ‘Public Money? Public Code!’ in this strategy, nine years after the FSFE launched the initiative, could become a major step forward for software freedom in Europe. However, the Commission still falls short on concrete goals, milestones, and secure funding for Free Software. The procurement reform will be a test: ‘Public Money? Public Code!’ must become a mandatory requirement for public tendering. Redirecting even half of Europe’s €264 billion in public IT spending from proprietary lock-in to Free Software would boost European tech sovereignty”,

says Johannes Näder, FSFE Senior Policy Project Manager.

“We welcome the Commission’s commitment to invest across the entire software stack, including Free Software operating systems for mobile devices, which is essential for device neutrality and user choice. It also creates opportunities for individuals, public administrations, and companies to develop and maintain technology under their own control. What matters now is implementation. These commitments need secured, long-term funding, meaningful involvement of independent experts and civil society, and effective enforcement of the Digital Markets Act to ensure Free Software can thrive in a fair market”,

says Lucas Lasota, FSFE Legal Programme Manager.

Key elements of the Tech Sovereignty Package

The FSFE will actively engage with the European Parliament, Member States, and civil society partners to transform these strategic goals into concrete, legally binding projects.

Support FSFE