In its feedback regarding the review of the European Interoperability Framework, the FSFE is calling for Free Software and Open Standards to be the default when procuring and creating interoperable digital public services.

Digital public services are becoming an increasingly important component of our daily lives, with around 85% of services available digitally for both businesses and citizens according to data from the European Commission. Transparency and control over these processes have become more important than ever for citizens and public administrations alike. The European Interoperability Framework (EIF) has been setting the guidelines for providing digital services since its creation. Under the Interoperable Europe Act, the EIF’s role has been strengthened. It needs to be taken into account when introducing new digital public services, substantially updating existing ones, and when developing new regulations and guidance.

The status quo and next steps

For the EIF currently in force, the Free Software Foundation Europe's contributions helped establish a model of "active and fair consideration" of Free Software solutions and the recommendation to contribute changes upstream whenever possible, contributing to level the playing field for Free Software solutions. Nevertheless, shortcomings such as deeming so-called "fair, reasonable, and non-discriminatory" (F/RAND) terms an appropriate licensing model, negatively impact the creation and deployment of Free Software solutions.

Nine years later, a revision of the current EIF is underway. Members of the Interoperable Europe Board and respondents to the call for evidence have raised concerns regarding control over public administrations' services and data and gaps between guidance and concrete implementation.

“Today, public administrations are more concerned than ever about their digital autonomy – as we saw recently in the European Commission’s Tech Sovereignty Package. Free Software and Open Standards are prerequisites for technological sovereignty and need to be in the spotlight of the upcoming EIF. The involvement of civil society actors in the process and secure long-term funding for the Free Software ecosystem are key for the success of the Interoperable Europe Act and digital public services.” – explains Sofía Aritz, Policy Consultant.

In its position, the FSFE addresses these problems by calling for, among other measures:

• Shifting to a "Free Software by default" model: Free Software is a prerequisite for technological sovereignty due to the controllability and transparency that it provides, while also playing a fundamental role in reusability and cross-border collaboration. Free Software needs to become the default model for creating, implementing, and customising digital public services, in accordance with the principles of "Public Money? Public Code!"
• Requiring Open Standards in digital public services: Open Standards that are implementable in Free Software are crucial to the development of a thriving market for interoperable digital public services.
• Developing guidance for Free Software procurement: Creating and promoting guidelines and training tailored to procurement professionals on Free Software procurement and the detection of openwashing.

Free Software and the Interoperable Europe Act

The European Interoperability Framework provides recommendations for legal, organisational, semantic and technical interoperability, first created in 2004. Since the adoption of the Interoperable Europe Act, it is going to be developed by the Interoperable Europe Board. This new legislative framework and new digital challenges have raised the need of reviewing the current EIF, which was last updated in 2017.

The FSFE considers that the Interoperable Europe Board should seize this opportunity and use the EIF as a practical reference for the rest of Interoperable Europe instruments. The FSFE is calling for the inclusion of additional criteria to existing guidelines and the "Interoperable Europe solution" label. Such criteria needs to take into account whether proposed solutions are Free Software, make use of Open Standards, implement them adequately, and follow a collaboration-first model.

The FSFE has called for the development of legal and financial instruments that secure long-term funding for Free Software solutions while reducing fragmentation between existing Union funding programmes, European Digital Infrastructure Consortia (EDICs), and other cross-border initiatives.

The inclusion of civil society into the wider Interoperable Europe governance, especially the Interoperable Europe Board and the "Interoperable Europe solution" process, remains fundamental to the implementation of the Interoperable Europe Act and the fostering of a market of interoperability solutions. The FSFE will closely follow the next steps towards the new EIF, sharing upcoming developments with our community.

Support FSFE

8 July 2026 marks a significant milestone in the fight for interoperability and software freedom, for both developers and users: the Court of Justice of the European Union dismissed Apple’s challenge against its designation under the Digital Markets Act. This judgement confirms that Apple remains subject to the DMA.

Apple’s designation as a gatekeeper

As one of the largest technology companies in the world, Apple's power spans key aspects of software distribution, operating systems, and devices. This power distorts digital markets and negatively affects not only fair competition, but also software freedom and an open internet. For this reason, in September 2023 and under the Digital Markets Act (DMA), the European Commission designated Apple as a “gatekeeper”. In that decision, Apple was designated in relation to the App Store, its operating systems iOS and iPadOS, and its browser Safari.

The DMA imposes obligations that include rules on uninstalling apps and changing defaults, enabling alternative app stores and software distribution, and granting effective interoperability with key software and hardware features controlled by gatekeepers. Besides Apple, designated gatekeepers currently include Alphabet, Amazon, Booking, ByteDance, Meta, and Microsoft.

Apple’s answer to the DMA: an attack against interoperability

After being designated as a gatekeeper, Apple challenged the European Commission’s decision before the Court of Justice of the European Union (CJEU). One of Apple’s central arguments was that the interoperability obligations of the law were disproportionate under the EU Charter of Fundamental Rights and interfered with its "right to property".

Article 6(7) DMA requires gatekeepers to allow third-party hardware and software providers effective interoperability, free of charge, with the same hardware and software features available to the gatekeeper’s own services or products.

In November 2023, Apple brought an action against the European Commission. It asked the Court to declare Article 6(7) DMA inapplicable and to annul the decision to designate Apple as being subject to the interoperability obligation for iOS.

Several key parties intervened in the case brought by Apple against the Commission (T-1080/23) including the European Parliament, the Council of the European Union, France, and the industry representative Coalition for App Fairness. All of these parties threw their weight behind the Commission. The Free Software Foundation Europe (FSFE) was the only charitable organisation permitted to intervene and joined forces against Apple.

The goal of the FSFE was to hold Apple accountable under the DMA in a way that protects developer rights. In its intervention, the FSFE highlighted that Apple is being regulated in the public interest, asserting that the company should compete on trustworthiness. Both developers and users should have the option of using alternative services and products rather than being locked into those offered by Apple. The FSFE urged that the case be dismissed entirely.

In October 2025, the FSFE’s lawyer, Dr. Martin Husovec, stressed, at the hearings of the CJEU, that innovation does not exempt a company from regulation. Apple's products form an ecosystem in which value is created not only by the company itself, but also by independent external developers and consumers who own the devices. Therefore it is entirely legitimate and necessary to coerce selected gatekeepers’ products into interoperability.

The verdict: Apple’s obligations remain intact and procedural circumvention around interoperability not allowed

In July 2026, in its judgment, the CJEU dismissed Apple’s challenges against its designation under the Digital Markets Act (DMA) for the App Store and iOS. The Cupertino company remains subject to the DMA, and its attempt to use this case to attack the law’s interoperability framework was rejected. The Court ensured that Apple’s obligations as a designated gatekeeper remain fully intact.

In this case, however, the Court did not rule on the substance of Article 6(7). Instead, it clarified that Apple could not use a case concerning its gatekeeper status to challenge interoperability rules applicable only after designation. The Court held that Article 6(7) DMA "does not govern the conditions for designating an undertaking as a gatekeeper", but "merely defines the interoperability obligations" that apply once a company has been designated.

This is a matter that extends far beyond Apple. Whether a company meets the legal criteria to be considered a gatekeeper is not the issue here; the obligations that follow from that status are. For the DMA to work, gatekeepers must not be able to delay or weaken enforcement through procedural detours.

Device Neutrality applies to alternative app stores

The judgment also dealt with a central aspect of software distribution: how Apple’s App Stores are governed under the DMA. Apple argued that rather than as a single ecosystem, its App Stores should be treated as separate distribution entities depending on the type of device: one for smartphones, one for tablets, one for desktop computers, one for watches, and one for TVs. If this argument had succeeded, the scope of the App Store designation could have been narrowed.

The Court rejected this approach and stressed that a software application store "allows business users to offer software applications to end users". It also pointed out that Apple’s App Stores are used for the same basic purpose: distributing software applications between developers and users.

Finally, the Court supported a technology-neutral reading of the DMA. It held that the classification of a software application store does not depend "either on the device on which that store operates or on the operating system on which the software applications offered within that store run". The Court stated that the DMA’s core platform service definitions should be "technology neutral" and should not vary according to the "technological choices made by the gatekeeper". By establishing this, the Court also agreed with the arguments of the FSFE and the Commission that the DMA is device-agnostic and should not depend on the specific form factors dictated by a gatekeeper.

A step forward for Software Freedom

This judgement brings us one step closer to one of the key pillars of the FSFE's vision for 2048: Device Neutrality. Or in other words: everyone should have the right to install and uninstall any software on their own devices.

The DMA approaches Device Neutrality through several connected obligations:

• Article 6(4) opens the door to alternative app stores and software distribution.
• Article 6(3) gives users more control by requiring that gatekeepers allow them to uninstall apps and change default settings.
• Article 6(7) requires effective interoperability with key software and hardware features.

These rules, along with others, contribute to ensure that third-party software not only reach users, but also function effectively on gatekeeper controlled devices.

However, there is still a lot of work to be done. This particular case may be closed (Apple can still appeal), but it is not the only one. Apple has opened a second legal case against the European Commission’s interoperability specification decision.This decision includes measures aimed at improving transparency and access for developers. These measures include clearer procedures for interoperability requests, improved access to technical information and communication channels, and rules for software and hardware interoperability. The FSFE has also been permitted to intervene in this new case.

Moreover, a gap persists between the law on paper and the reality faced by developers. A recent report from the FSFE shows how Apple’s request-based approach has left developers without effective access to its mobile operating system functionalities. Despite the European Commission’s detailed procedures on software and hardware interoperability, developers still face uncertainty, delays, and refusals when seeking access to Apple-controlled features.

Developers: send your feedback

The participation of the FSFE in these two interventions shows that equal and fair access for developers should not depend solely on the discretionary control of gatekeepers. The Free Software tradition, built on open standards and community oversight, shows that interoperability can be governed as a digital commons, not only as a private platform privilege. Effective interoperability should serve users and developers, not only platform owners.

The FSFE invites developers who have requested access to either software or hardware features under Article 6(7) of the DMA, or who considered doing so but were discouraged by the process, to get in touch. Your experiences can help us document how interoperability works in practice. They can also support better DMA enforcement for Free Software developers and computer users.

Timeline of the case

• September 5, 2023: The Commission designates Apple as a gatekeeper for the App Store, iOS and Safari, and separately opens a market investigation into whether iMessage should also be designated.
• September 6, 2023: The designation decision is formally notified to Apple.
• November 2023: Apple files an appeal three separate actions before the General Court, against the decision opening the iMessage investigation, against parts of the designation decision.
• February 2024 - The FSFE requests to intervene.
• March 7, 2024: Apple's gatekeeper obligations for the App Store, iOS and Safari become legally binding, six months after notification.
• August 2024 - The CJEU allows the FSFE to intervene in the case.
• September 2024 - The FSFE submits its arguments to the CJEU.
• February 2025 - Court partially dismisses Apple's requests for confidential treatment.
• October 21, 2025: The General Court holds a hearing on Case T-1080/23.
• July 8, 2026: The General Court, sitting in its Eighth Chamber with five judges, delivers judgment dismissing all three of Apple's actions.

Support FSFE

Times goes by… Did you know the FSFE was founded in 2001, 25 years ago? Of course, we have planned something for our silver anniversary! We are dedicating a full episode of the Software Freedom Podcast to talk about the celebrations and to invite, all of you, our listeners, to celebrate with us. Find out more in our 53rd episode!

Ana Galán, who is the one in charge of the FSFE’s communication and one of the event organizers, took a moment out of her busy schedule to talk with Bonnie Mehring about the FSFE's 25th anniversary and upcoming celebrations. Take a moment to find out how and when the FSFE will be holding their summer meeting and marking this milestone.

For 25 year the FSFE works to safeguard Software Freedom. You can support our work by donating today!

Show notes

• Support our work for Free Software
• Stay up-to-date and join our Newsletter
• FSFE's current Activities
• FSFE Timeline - Working for Free Software since 2001
• The FSFE Team
• anaghz@fsfe.org

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

The Court of Justice of the European Union has rejected Apple's challenge to the interoperability obligations under the Digital Markets Act. The Court also confirmed the App Store as a core platform service. The FSFE hails this as a major win for computer users and developers.

Today, the Court of Justice of the European Union (CJEU) has ruled in the case Apple v. European Commission (T-1080/23), in which the Free Software Foundation Europe (FSFE) intervened to defend the rights of developers and users under the Digital Markets Act (DMA).

Apple had challenged the interoperability obligations applicable to its mobile operating systems, the designation of the App Store as a core platform service (CPS) and the original designation of its messaging service as a number-independent interpersonal communications service. The FSFE intervened to hold Apple accountable under the DMA in a developer-friendly way.

With this judgment developers and users will enjoy a less restrictive environment to access and be able to distribute their software in environments controlled by Apple. This includes unfettered software installation (sideloading) and effective and free-of-charge interoperability between their software and Apple’s software and hardware controlled by Apple’s operating system.

This ruling confirms what we have argued from the start: interoperability is not optional under the DMA, it is the law. Developers finally have legal certainty to build competitive alternatives to Apple's ecosystem, and we remain committed to monitoring enforcement of today’s decision,says Lucas Lasota, FSFE's Senior Programme Manager Legal

In its press release, the Court states that Apple’s challenge against “the provision of the DMA relating to the interoperability obligations imposed on undertakings which are designated as gatekeepers” was inadmissible. The Court also confirmed that the different versions of Apple’s App Store “constitute a single CPS”, because they share the same purpose: “to connect app developers with end users in order to facilitate the distribution of software applications.” For the FSFE, this confirms the central role of interoperability and software distribution in the DMA’s regulation of Apple’s ecosystem

The future of software interoperability

The FSFE will closely monitor of the implementation of today’s decision, starting with an in depth analysis of the ruling. It will be available in the upcoming days at fsfe.org.

Besides, Apple has initiated another litigation against the European Commission on questions concerning the technical and procedural aspects of interoperability (T-359/25). The FSFE is also intervening in this second case and we will again demonstrate to the court the importance of interoperability for fair digital markets.

Support FSFE

The past few weeks have been busy for YH4F 2026 participants: the programming period wrapped up on 30 June with project submissions for evaluation. We also submitted our position on the EC's Android interoperability consultation, and published an in-depth study by an FSFE volunteer examining whether the Teufel Mynd speaker truly qualifies as Free Software and Open Hardware.

Summer is properly here, and we cannot wait to see you in a few weeks in Kraków! Preparations for our 25th anniversary weekend celebrations are keeping us busy, but that's not all that's been going on.

A couple of days ago, Youth Hacking 4 Freedom 2026 wrapped up its programming phase. The participants are now taking a well-earned rest, while our jury gets to work choosing this year's winners. We cannot wait to discover what amazing projects the participants of this 5th edition have built, and to celebrate them at the YH4F awards ceremony. You can find all the details, and revisit past winners on yh4f.org. Registration for the next edition is already open.

Meanwhile, the rest of our work has not slowed down either: the FSFE has submitted its position to the European Commission's Android interoperability consultation under the Digital Markets Act. Among our key demands: the right to fully uninstall AI-based features from Android devices, and access to interoperability functions for developers, free from Google's verification requirements.

A study by Lucas Lasota and Jithendra Palepu on Apple, Free Software, and vertical interoperability under the Digital Markets Act has now been published on Humboldt-Universität zu Berlin's open access repository, edoc. The paper analyses Apple's compliance approach under Article 6(7) DMA and explains why effective interoperability is crucial for Free Software developers, user freedom, and fairer digital markets.

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

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. We want to know which products work better when you want to be in control of your devices! Please, share your knowledge with us.

The FSFE is also now one of the organisations part of the Cradle to Cradle Electronics Initiative, a platform for business, academia and civil society to put Cradle to Cradle electronics into practice. To achieve it, we believe that all our electronics should be under the open hardware and Free Software principles: giving users the freedom to inspect, modify, and truly understand the technology they rely on every day.

The FSFE's timeline

Our timeline is officially live! It maps 25 years of the FSFE's work promoting and defending software freedom across Europe, from our founding in 2001 to today. Along the way, the FSFE has helped shape the conversation around Free Software, built lasting communities of volunteers and supporters, and started initiatives about device neutrality, legal education, and public code. Take a look!

From the stages

While we wait for the weekend that some of us marked long time ago in our calendar, the celebration of our 25 years, we've had a busy few weeks!

Our volunteer and coordinator of the Dutch team attended the 2026 T-DOSE conference. You can listen to him talking about the conference in our Software Freedom podcast episode 52.

We headed to OpenSouthCode 2026 in Málaga with two talks and two Ada & Zangemann activities at their Kids Space. Speaking of Ada & Zangemann, we also hosted a reading of the book in Brussels, joining together at Bibliotheek Sans Souci in Ixelles.

We also travelled to Brno for DevConf.CZ, where we had a booth and gave two talks.

In Berlin, our local group has also been busy: with a booth at the Umwelt Festival, they explained not only sustainable computing with Free Software but also Upcycling Android, Public Money Public Code, and the Fediverse. Two of our volunteers also gave talks at the Bits und Bäume Community Summit.

Join us at DWeb Camp from 8 to 12 July in Alte Hölle! DWeb Camp is coming to Europe and the FSFE is attending it. We will be present with an Ada & Zangemann reading and several talks about this illustrated book, how to fight for interoperability under the DMA, and Device Neutrality.

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

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!

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.

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:

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:

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:

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:

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:

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.

Update 2026-07-01: The analysis is now also published on the Cradle to Cradle Electronics Initiative media library.

Support FSFE

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:

• Uninstallation of AI-based features: users must be able to fully remove pre-loaded AI components, with companies prohibited from silently reinstalling or reactivating them.
• Decoupling interoperability rights from Android Developer Verification: access to Android’s interoperability features must not be contingent on registration, authorisation, or contractual relationships with Google.

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

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

• Support our work for Free Software
• Stay up-to-date and join our Newsletter
• T-Dose, official webpage
• T-Dose on Mastodon
• Nico Rikken, Mastodon
• Nico Rikken at FSFE
• hpr4641 :: Technical Dutch Open Source Event (T-DOSE)
• T-DOSE @ peertube
• We promote and talk about 'open', but are we actually -doing- it enough?
• Linux voor een beginner (Dutch only)
• FSFE @ T-DOSE, 2014
• T-Dose Live Stream
• SFP#50: Policy and EU: How NGI wants to save the Internet and what's next?
• FOSDEM conference
• Angry Nerds Podcast at T-DOSE 2026 deel 1

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

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"

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

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.

UPDATED ON 15 JUNE 2026

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, loopholes might be exploited and the non-binding Strategy 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 IT spending from proprietary lock-in to Free Software would boost European tech sovereignty”,

“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”,

Key elements of the Tech Sovereignty Package

• To counter the structural disadvantages faced by European SMEs, and Free Software companies in particular, under frameworks historically tailored to proprietary vendors, CADA introduces a Free Software first requirement, supported by new tendering guidelines to eliminate vendor lock-in, but mainly for public cloud and AI contracts.
• The package prioritises critical technology areas for Free Software development, including semiconductors such as RISC-V, cloud stacks, AI frameworks, and Free Software mobile operating systems.
• The EU aims to mobilise €2 billion over seven years "for all measures under the open source strategy", including a maintenance instrument to provide sustained financial support for critical dependencies – still a small fraction of the €264 billion spent yearly on proprietary software and services.
• In partnership with Member States and European Digital Infrastructure Consortia (EDICs), the EU aims to reach at least 30 million active users for Free Software collaboration tools and secure messaging by 2030.
• The Commission addresses the lack of independent digital education and tools in the education sector by announcing support for a Free Software suite for schools and universities, as well as vendor-agnostic training.

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