PROJET AUTOBLOG


Free Software Foundation Europe

source: Free Software Foundation Europe

⇐ retour index

SFP#53: FSFE is turning 25! Come and celebrate with us!

vendredi 10 juillet 2026 à 01:00

SFP#53: FSFE is turning 25! Come and celebrate with us!

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

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

Apple held accountable under the DMA - A victory for developers and computer users!

mercredi 8 juillet 2026 à 01:00

Apple held accountable under the DMA - A victory for developers and computer users!

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 acknowledges 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

YH4F 2026 wraps up, Android interoperability, and the Teufel Mynd speaker to test

mardi 7 juillet 2026 à 01:00

YH4F 2026 wraps up, Android interoperability, and the Teufel Mynd speaker to test

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 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.

Speaking of podcasts, we have two recommendations for you. We were invited onto a radio show hosted by our Slovenian volunteers to analyze the Open Source Strategy (the interview is in English, starting at 16:50). Our German-speaking audience might also enjoy this episode of the Engineering Kiosk podcast, where we were invited to talk about openwashing.

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

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